The best code is no code.

Writing software solutions is a very exhaustive process and can get complicated when not thoroughly thought out.

Many of us (developers, software engineers, whatever you call yourself) tend to jump straight into building solutions before understanding “the why”, especially when we are very early in our careers.

E.g: Person A has problem X. We jump on and just decide that we can solve this problem by using tool Y. After the time spent writting some code we eventually solve the problem ?? , but Person A reports back that it was not even the problem they were attempting to solve!

TL;DR

After several discussions with a teammate, we both concluded that the best code is no code.

If there is a need for code, then it should be as simple as possible at first.

I know it may be asking yourself: how is it that the best code can be no code at all ??? Let me explain what we mean by showing a few points:

The problem doesn’t need a software solution; it needs a behavioral change.

Before adding a new feature or building something new we need to ask ourselves the reason: why? – Without understanding the true reason we shouldn’t be writing any code at all. Sometimes (especially) when you build an entirely new product you will need to try to understand the core of that request.

During my university days, we studied Human-Computer Interface, and there I understood that we are building solutions for humans and humans will use these products, thus before changing the position of a button you will try to understand if there is a true need to make those changes.

Your code is not always needed.

This point talks back to the first one, imagine a scenario where you spend close to 2 hours trying and figure out how to solve a given problem that you think your code would solve, and then your code is never checked into production.

“Wasn’t my code good enough?” you may ask — but the reality can be that your code was never needed in the first place. The solution to the problem you were trying to solve had more to do with the way users were interacting with your solution. Thus we need to understand that when we are writing a piece of code, sometimes it will be deleted and forgotten like it never existed.

You might be tricked by your product manager.

Product managers or product owners (in some cases) are responsible for researching and understanding how users are interacting with a product, for this they conduct researches to understand the user needs and then write up the next set of features that should be built.

Your job as developers is to build those features, yet, we still need to try understanding further what is it that these features will be solving for. 

I’ve been in situations where a new feature request seemed to be a great idea ??, but after jumping into the code and connecting the dots I noticed that the code I was writing didn’t really solve the problem as it was instead potentially creating more problems for the final users. 

The product manager can come up with a valid reason why they do need feature x to be built and we get paid to build it, but it is also apart of our job to access every single request before doing them. 

Have always the product in mind, your code is there to simplify its users’ life. Seek to deeply understand what your are solving for. 

You still have to code

To sum up, the lesser you write code and the more you understand the why of things the better your solutions will end up being. But, when you code something ensure that you write your code in the simplest way possible avoiding overcomplicating your implementation.

Keeping things simple and understanding them will allow us to test faster and get to know if our solution actually will solve the problem for the final user.

The best code is no code and the best solutions are the ones where your code is simplified and easy to extend.

Happy hacking!