The Harsh Reality of Good Code

If I have to sum up my coding skills after 15 years of software development I’d probably go with something like “average on a good day”. This might sound harsh, but the fact is that many devs feel the same regardless of their years of experience.

Writing good software is hard, but, before going into the details, let’s acknowledge the harsh reality of building software products, the only absolute truth we all end up accepting sooner or later.

Chapter 1 - Nobody cares

When it comes to software, “beauty is in the eye of the beholder”.

In other words, nobody besides your team really cares about your clean code, your domain-driven design or the layers of abstractions you preemptively added in your codebase. I’m not saying this is right or fair. I’m just stating a fact. Outside the dev team, people are way more pragmatic. Product cares about the customer, Sales cares about releasing new features, Management wants you working faster, better, and preferably cheaper and QA simply wants you dead. Nobody knows what HR cares about, but it’s probably safe to assume it’s not your code.

With this in mind, knowing you are fighting an already lost battle, let’s see why good software still matters, and how to enforce it in a world filled with deadlines, conflicting priorities, remote work, and affordable streaming services.

Chapter 2 - What is good software

There is a big distinction between working software and good software. On the surface, it seems like good software makes developers happy while working software makes everybody else happy. Here is the kicker though… Bad software that works will eventually stop working.

There is a mismatch in priorities. As long as the software works, nobody outside the dev team will prioritize fixing it. It’s human nature to focus on immediate gains, take the profits, and kick the can down the road.

However, in the long run, software must be well-written so that it can evolve seamlessly and meet the ongoing needs of your organization. So the bad news is that even though nobody else cares about it, writing “good” software is still your main responsibility. On the upside, writing good software is easy, at least on paper.

On one hand, your code has to be clean, concise, and well thought out so that you and your team can easily maintain and extend it in the future. On the other hand, it needs to be secure and efficient so that your product doesn’t require an entire powerplant and a VIP AWS account to run in production.

There are enough objective metrics to immediately evaluate your code when it comes to performance. If Bezos calls personally to thank you for your contribution to his most recent nautic acquisition you are probably doing something wrong. Creepy!

Clean, well-thought-out code is much harder to assess though. After all, there is a reason you have “one thousand pages” books on the simple concept of writing code.

Despite being a complex difficult topic, there are a few basic principles you can follow to ensure that the code you are writing is on the right path.

Chapter 3 - How to write good software (or at least try)

There is a fine line between writing good software and writing overcomplicated, useless code. Experienced developers will tell you that you should always assume unexpected changes when writing code. Well… this is kind of dumb. If I’m expecting unexpected changes, those changes are expected, right? Of course, this is an oversimplification. The idea is that products are in constant change, and your code has to easily adapt to new requirements.

Abstraction is the main tool you’ll use to make your code more flexible but this can easily become a slippery slope. Planning too much for what might come will lead to premature optimizations which, as we all know, are the root of all evil. David Wheeler sums this up pretty well: “All problems in computer science can be solved by another level of indirection, except for the problem of too many layers of indirection”.

The problem of over-abstraction can be easily solved with something devs rarely excel at - talking with other people. Software development should not happen in a vacuum. You should talk with domain experts to deeply understand the business logic, and ask questions as often as possible, preferably before you make any software design decisions.

With a good understanding of the requirements, the next thing you should focus on is the form of your code. Uncle Bob’s Clean Code has some great tips and tricks to make your code more readable and easily maintainable. If you are not a fan of reading, static code analyzers like SonarQube will enforce most of those patterns in a CI / CD process.

One big mistake we often make when writing new software is that we take the opportunity of new projects to follow the most recent dev trends and test new tech stacks. There is a time and a place to acquire new skills. Most of the time this is not during the development of software meant for production. The best tool for the job is the tool you know best, and if you want to fight me on this please take it to the WordPress devs - they still run like half of all known websites after all.

The final piece of advice is most likely the one toughest to accept. When in doubt, trust your old self and avoid refactoring code just for the sake of refactoring. Going back to the beginning of the video, nobody is happy with the code they wrote 6 months ago. I would argue that one of the best skills experienced developers have is the ability to jump into a codebase, fight the urge to rewrite everything, and perform the necessary updates in a simple manner.

Chapter 4 - Conclusions

The bottom line is that, sadly, knowing all this theory will not make you a better developer. Good software is the result of previous poor design decisions, thousands of lines of spaghetti code, technical debt, and a lot of other lessons learned from past projects. You are not failing, you just found 10000 ways that won’t work. And if you are happy with the code you are writing today, don’t get your hopes up, it’ll suck when you’ll have to debug it 6 months from now.

If you enjoyed this article, you should watch some of my youtube videos or subscribe to the newsletter.

Until next time, thank you for reading!