Keep your kitchen clean
Your code base is a kitchen and you and your colleagues are chefs. You might be outputting the best and delicious dishes and your clients have nothing but kind words about your work but if you don’t clean your kitchen, at some point in time you’ll have a cluttered and filthy workplace that will stop you from releasing those delicious dishes — Matt Wynne
Those might not be the exact words that Matt used when I attended one of his BDD workshops but the analogy is the same.
People don’t normally see the backstage of a web app and that may undermine some concerns that are a requirement when building something as tangible as a brand, a logo or the design of an app.
Imagine the work of a web designer without some kind of style guide and consistency when building your app. Your homepage uses blue as the main colour, your contacts uses red and sometimes on some other pages its yellow with a different logo. Not quite the work you’d be looking for right? One might say, not professional.
Well as a developer and a master chef you are also a designer. So, given your current code style and consistency throughout your code; if your client could see your kitchen would he eat a dish cooked by you?
Your client probably can’t see it but your developer colleagues can and if you plan on releasing your work onto the open source world wilderness, you’ll probably have millions of chefs looking at your kitchen.
Whether or not you want to be professional or look like it is totally up to you One would do well not be constrained by what others think of him.
but
One would do better to be considerate of others when working with them.
You might not want to clean your kitchen but other chefs are working in it too, be mindful of that. Don’t be that screw-this-I’ll-do-it-my-way-guy, you should be coding for them not for you and remember they are not the only ones that will struggle with your code, in the long run your future self will be a stranger to your code too.
Not following some kind of code style guide and not being consistent with it will lead to a messy kitchen. If you decide to quit and go work in another restaurant, chances are an old colleague of yours will have to clean your mess because he wants to continue to prepare good dishes.
Care for your readers, calling things a different name (“event” => “evt”, “ev” or “index” =>“idx”, “i”) doesn’t not help at all; not to mention the lack of consistency that will occur if everyone decides to invent new cryptic and prone to conflict names.
Defining URL routes for your API that you think are way easier to understand than REST is once again not helping. Other people don’t see the world the same way you do, don’t expect them to magically understand you.
Writing convoluted and super hyper DRY code does not make you a super developer rock star.
Not caring if people struggle to understand you, does not benefit you in anyway.
Choose a style guide with your team and stick with known and widely spread standards/conventions. If you or someone else are having problems with certain rules, talk about it together to achieve some kind of commitment.
Must of us do not have the capacity to look at our own code from a stranger’s perspective but ultimately our code is bound to be read/used by others, therefore it is our job and no-one else’s to help them doing so.
Code for others not for you.
