Code is not art, it’s engineering

In architecture, construction, law, and other industries, when you are given a problem, you always end up with only two kinds of solutions for it: the “valid” one (the best one you can find for this particular case), and all the other ones (the “wrong” ones).

Why are we constantly fooling ourselves it should be different in the software engineering? It shouldn’t be.

There should be only one true way to do a thing. If there’s a case in which another way is better, then okay, it can be chosen over the former way, but there should be a clear guideline, when should you go with which one of them.

There should never be a case in which the answer is “do what you like”. Your personal taste shouldn’t matter while coding. All codebase should be unified and done perfectly with your team’s and project’s guidelines. And your team’s and project’s decisions should be based on whatever is best for the future of your product.

You don’t get to choose to write you front-end in React or Angular, just because “you like it”. Instead, you should choose it only if it makes logical sense in your particular case. Example reasons:

  • most of your team is already familiar with the given framework;
  • it will be easy to recruit new developers willing to work in this given framework in the future,
  • it will let the project to be easily scalable (the number of features or developers won’t overcomplicate the project nor decrease its’ performance),
  • it has a big community support (which decreases the chance you’ll end up with unsolvable problems in the future; and also makes you assured, that you’re not the only person in the universe that decided it‘s the “best way” for them).

Thus, whenever you ask 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 your personal taste, at least not solely on it. It should be based on what your whole team decides what is the best for the product you’re working on.

When discussing what to choose, stop saying that the given fragment of code or a framework is “nice” or “ugly”. Instead, say: this is “unreadable”; this is “good, but deprecated, there is another preferred way to do it now”; this is “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 to choose it on his own. And setup a code formatter, for Science’s sake.

In all the other cases, your team’s decision should be based on clear, logical arguments. You shouldn’t choose a language, framework or a way how to write components in your app, just because you like it how it looks like.

What if a next developer joins your company in a month, and his taste will be a bit different? Will you switch frameworks then, because your taste has suddenly changed? Will you force him to change his own personal taste? Will you let him write in his own taste, making your codebase look confusing and different in various places?

Whatever you decide about changing/keeping your personal tastes, eventually you’ll hate each other anyways.

But if you leave your personal taste aside and focus on your project’s greater good and its’ guidelines instead, you will forget what the “personal taste” really is.

Only then your codebase will be clear to read and easy to extend. The less “WTF?” or “How should I write it?” moments you have while browsing or creating your codebase, the better it will be.

Coding is not like painting, where every picture is a bit different. Do you really want each of your code files to look completely different? ;)

I agree that basing 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 thing you focus on 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 your mind whenever you’re coding anything. Only then, you can call yourself a software engineer. Without it, you’re just a self-proclaimed artist.

Please, don’t confuse art with engineering. The reasons, why art and engineering exist, are completely different.

Like what you read? Give Jack Tomaszewski a round of applause.

From a quick cheer to a standing ovation, clap to show how much you enjoyed this story.