Writing beautiful code

Disclaimer: the author of this post is a biased, opinionated backend developer. There are a lot of articles/books about best practices, coding guidelines, which I’m sure the majority of us have read and followed. The following is not about that.

There’s always a battle between frontend (FE) and backend (BE) developers about the latter writing ugly code, because no one will be able to read it, much less understand it but them (and let’s be honest, sometimes, after a few months the ones who wrote the code will want to refactor it, but that’s life).

I cannot stress enough how strongly I disagree with this opinion. If you break down what FE/UI devs need from their BE counterparts, is actually a payload. Yes, it all boils down to an object (no matter the language) which they take, they restructure it according to the feature’s needs and then, voilà, they deliver it beautifully (if they’re lucky with the help of a good UX designer and CSS) on the screen.

However, I’ve seen ugly and equally beautiful code in the BE realm. But what is beautiful code?

Is it having the knowledge and the ability to use the latest coolest features of language “A”? Is it implementing the best design patterns fitting problem ‘X’? Is it (re)structuring the codebase in components/modules according to architecture ‘Z’? Is it adding comments? Is it writing (unit) tests for your functions (methods) in order for your peers (and your future self) to understand what the heck you’ve done? Is it writing readable code, often to the expense of not using cool programming tricks that may reduce lines in your code? Or is it about efficient code? And what about a legacy codebase? How can you write beautiful code, being technologically handicapped and unable to use the latest frameworks and new language features?

There isn’t only one answer. On the contrary, the answer is all of the above. And of course, it depends on one’s experience, comfort zone or even understanding their peers’ way of coding.

Although I believe efficiency is a very important aspect that drive us devs to write beautiful code, there is no way you implement one feature, writing what you think is beautiful code, if your peers cannot understand it. When someone first looks at your code, they want to see something self explanatory (from the method/class/package name), then delve into the backbone of the logic and understand it quickly, intuitively first and then in depth. It’s like reading a good book, page by page, in order, without turning them back and forth. The same with the code. Going from point A to point B to point Z, this has to have a meaning, a natural flow. If there are some unit tests, even better. Not only do they help strengthening your code in terms of bugs, but they also explain the logic behind the implementation of the feature and guiding you how to read the code, how to test it, how to debug it, etc.

Knowing the latest trends and cool features of the language helps, in terms of efficiency, clean code, but it’s not a panacea. Most of the times, the new way of doing things is the best way to go, but as with all new things, you have to really know how to use them and what purpose they really serve.

To recap, beautiful code is not about pretty code. It’s about understanding the purpose each and every bit your codebase serves. Finally, as with UX designers who care about user experience, I really believe that backend developers should care about developer experience, by being thoughtful to their peers and writing code that they themselves can understand and improve it or let others do that, when there’s a need.