Why write good code (in a simple way)

Recently I saw a trend on Hacker News (like this article and this one) that people start to question why write good code, and whether we should let all the principles for "good code" prevent us from being productive. I would like to try answer that question in a simple way.

First thing first, forget about all the coding principles that people (through the Internet) try to shove into your head - SOLID, DRY, Code smells, Design Patterns, etc. You can write good code without them. One principle is enough: have sympathy towards other developers in the team (including yourself after 6 months). Good code is code that is easy to work with, namely:

• Easy for other developers to read the code and understand the business logic
• Easy for the other developer to locate and change the code when they need to change/enhance the business logic

All other principles can be helpful guidance (sometimes), but these two are what really matters. (I explained why in this post.)

Now, with the definition of good code set, let's answer why we should try write good code rather than code that just works, or in a more appealing term, focuses on delivering business value.

Sympathy (or indifference) is contagious.

Yes, it might be a valid strategy to write just-works code to get things started and fix them later. However that's only valid when you are in a solo project in which you have complete control. You will lost that control quickly if it's a team effort. We all know the broken window theory. In my career I've seen very few software engineering theories more true than it. If you don't make a sincere effort to avoid giving your team members some hard times, chances are they won't either. It won't take very long for the code base to become nothing but nightmares - and never ever underestimate the capability of human producing worse and worse nightmares. On the other hand, if you show them good examples of code that are easier to work with, they will follow, very quickly. It's proven to me again and again.

Writing good code isn't that intimidating.

If you were scared by the numerous coding principles, don't be, just forget about them. The two criterion of good code mentioned above are also the two most common tasks you do everyday, so it shouldn't be hard for you to assess your own code based on them. Just think as if you were another developer, that is, be considerate. It's not intimidating, it's rather basic.
What about all those other principles? Are they just BS? Of course not, it's just that you don't need to remember them. In most cases, if you follow the two easy-to-work-with criterion, your code will naturally comply with them. For example, if you want your code to be easy to find and change given the logic (criteria #2), you would avoid writing duplicated code(or logic) - you know how hard to change business logic implemented with duplication - and that's the DRY principle.

Writing good code makes it fun

It adds a new layer of challenges. Again, back to the point 2, it's not that many more challenges - remembering and following dozens of code principles might be, but thinking as if you were another team member isn't. The right amount of challenges is necessary for me to have fun at work, if you do too, that is another good reason to write good code.

Join the discussion on the Hacker News.