growing up in an open source world18 Feb 2015
A recent twitter conversation led me to a very different place than I expected. It all started with this tweet
DID YOU KNOW: The two healthiest engineering organizations I’ve worked for rejected code style guides entirely?— C J Silverio (@ceejbot) February 18, 2015
First, a history lesson. My software career began in enterprise, the kind of place where your first week or so includes poring over style guides and best practices for the code base which you will be expected to follow. This is the world where failure to follow said guides means that your code is not high enough “quality” (that’s in quotes because it’s bullshit) to be pulled into the trunk.
Since leaving that world, I’ve spent time researching the Dreyfus model of skill acquisition which taught me that the novice needs rules to be productive while the expert works more on intuition where rules will impede productivity. With that in mind, it makes sense to have some kind of style guide for the junior developers.
I’ve been living a lie
I’ve been working with junior developers for many years in both the enterprise world and at Modulus and part of working with them is helping them become “great” engineers. In the past, that meant that they learn about coding style, patterns, and architecting solutions to problems, but there was always this strange emphasis on style that I picked up in enterprise.
The conversation from today made me realize that what I’m actually doing is limiting both their creativity and their flexibility.
So what does this have to do with open source?
It's true. I've run into it myself with "damn, this project uses 4 space tabs, gross" which is an incredibly detrimental (and shitty in general) attitude to have. Why would anybody ever want to pass that on to others?
Let's focus on growing as engineers and shipping software by creating healthy engineering environments. "Burn the style guide" so to speak and let people be people and learn what works best for them in what situations. Teach flexibility and how to be a good open source contributor.
P.S. I'm writing this down so that I stick to it and thanks CJ et al. for helping me get here.