Code Isn’t Art—It’s Engineering
When it comes to developing software, it’s not just a matter of taste.
In architecture, construction, law, and other industries, when you’re given a problem, there are only two kinds of solutions: the valid one (the best one you can find for this particular case), and the wrong ones.
Why are we constantly fooling ourselves that it should be different in software engineering? It shouldn’t be.
There should be only one way to do a thing. There may be different cases in which another way is better and should be chosen instead, but there should be a clear guideline.
There should never be a case in which the choice is “do what you like.” Your personal taste shouldn’t matter while coding. Your codebase should be unified and perfectly within your team and project guidelines. And your team’s decisions should be based on whatever is best for the future of your product.
- Most of your team is already familiar with the given framework.
- Using this framework makes it easier to recruit future developers.
- It allows the project to be easily scalable (the number of features or developers won’t overcomplicate the project or decrease its performance).
- It has a big support community, which decreases the chance you’ll end up with unsolvable problems in the future—and also gives you the reassurance that you’re not the only person in the universe that’s decided it’s the better way.
Whenever you’re asking yourself questions like:
- “What framework should we use?”
- “What library should we use?”
- “Should we use this library or implement it ourselves?”
- “How should we define this function and its arguments?”
- “Should this be a directive or a component?”
Your decision shouldn’t be based on personal taste, at least not solely. It should be based on what your whole team decides is best for the product.
Stop saying that the given fragment of code or a framework is “nice” or “ugly.” Instead, say it’s “unreadable;” or, “it’s good, but deprecated, there is another preferred way to do it now;” or maybe, “it’s good, but will have worse performance in the long run.”
When it comes to situations in which you have multiple and equally good ways to do something (tabs vs spaces? camelCase vs snake_case?), I don’t care which one you choose. Just choose something and stick to it. Don’t let each of the developers choose their own. And set up a code formatter, for Science’s sake.
In all other cases, your team’s decisions should be based on clear, logical arguments. You shouldn’t choose a language, framework, or way of writing components in your app just because you like how it looks.
What if a new developer joins your company whose tastes are a bit different? Will you switch frameworks to accommodate them? Will you force them to change their own personal taste? Will you let them write in whatever they prefer, making your codebase confusing and scrambled?
Whatever you decide about changing or keeping your personal tastes, you’ll eventually hate each other anyway.
But, if you leave your personal taste aside, and focus on your project’s guidelines and greater good instead, you’ll forget your past preferences.
Only then will your codebase will be clear to read and easy to extend. The fewer “WTF?” moments you have while browsing or creating your codebase, the better it will be.
Coding is not like painting, where every picture is unique. Do you really want each of your code files to look completely different?
I agree that basing decisions on personal taste is good while brainstorming and prototyping. But even then, while sketching up the interface or the algorithm of your code, the main focus should be:
- How easy will it be to modify and/or reuse it in the future?
- How readable will it be for other developers?
- Is it performant enough? If it’s not, is there an easy way to improve it or work around it in the future?
Those are examples of logical questions you should have in mind whenever you’re coding anything. Only then can you call yourself a software engineer. Without it, you’re just a self-proclaimed artist.