I remember my first time encountering a curly brace on a new line. The world seemed to stop spinning for a second. “This must be a mistake” I thought to myself as I moved the curly brace back to where it belonged, on the same line as the function declaration. I committed this change along with my other work and in good spirits awaited my PR review. To my chagrin, the only issue that was noted in my PR was the fact that I had not put my curly braces on a new line. I had officially had my first experience with formatting standards. Because this was my first job and I deeply respected my peers I quickly applied the fix and ensured that all of my curly braces were on a new line from then on.
From that moment forward I became a standards chameleon, adapting to whatever environment I found myself in. I would put curly braces wherever people wanted them, I would delete semi-colons if I needed to. If the environment I was stepping into had pre-defined ways of doing things, I would adapt to those ways. I should mention that I am specifically talking about formatting standards right now. I didn’t hesitate to suggest changes to more fundamental strategies if I thought it could make an impact.
This was not my last experience with clashing standards. I view most of these interactions now as a bystander. It’s not uncommon to see some of the most talented developers at a company getting in heated debates over the eslint file. I’ve even seen developers build entire separate micro services just so they didn’t have to adhere to the standards of the original codebase (yes that was the real reason). These developers, despite their talent, are missing the most important part of software development: the end product.
My point here is not to say that standards should not exist. It is just that they should not take up a meaningful amount of time and effort. There are tools to make adopting standards easier, such as Standard for JavaScript and Standard for Ruby. Both of these can help avoid painstaking maintenance and fruitless discussions around standards
This idea of adapting to coding standards may seem like a minor revelation, and it is, however, it was the spark that started the shift in my view of software. In the beginning of my career, I cared almost solely about the means of building a product. I was more concerned with using cutting edge technologies and standards than I was with what those technologies and standards amounted to as a product. I believe that as builders we should not lose sight of our primary goal - building great products. Any time wasted arguing about the means is time that could be better spent focusing on the end - ensuring quality and success of the end product. For new developers, dropping your attachment to standards is the first step towards this shift in thinking.
Thanks for reading! If you enjoyed this you may also enjoy my newsletter: https://nicholaswarwick.substack.com
Top comments (0)