The code you take away as important as the code you write

“Sometimes what you don’t do is just as important as what you do.” ― Greg McKeown

The code you take away, helps as much as the code you add. Good developers remove code and improving the quality and maintainability of the code base but no one tells you that when you start your journey as a software engineer.

Code only what is necessary

Once code is released to production, you can’t take it back. Other code becomes dependent on it with components built on top of it. Taking away non-essential code becomes more difficult once it’s in production. Changes will go through the whole life cycle from Dev to Production with testing inbetween.

The more code you write, the more bugs you potentially add. Readability is reduced with more lines of code because it adds more noise to the signal. Most people don’t write simpler code with fewer lines of code because they don’t have time or the will to do it.

Any time we write code, we can create bugs. We can create bugs as easily as useful code. All code brings the promise of new functionality and the threat of bugs.

Create as little code as possible and keep it simple. The first phase of coding a solution is to get it to work, the second phase is to subtract what is not needed and improving the naming of the code. Better named code doesn’t need comments — Code should be the one version of the truth, don’t add comments

The noble art of creating customisations and delivering solutions, the creation of code is quick, compared to time maintaining the code. The more code written, the more resources and time needed to maintain that code. Experienced developers understand the wisdom of creating as little code as possible, which reduces the overhead of the code created.

This reminded me of Robert Greene’s 4th law of 48 Laws of Power Law 04: Always Say Less than Necessary

“When you are trying to impress people with words, the more you say, the more common you appear, and the less in control. Even if you are saying something banal, it will seem original if you make it vague, open-ended, and sphinx like. Powerful people impress and intimidate by saying less. The more you say, the more likely you are to say something foolish.” — Robert Greene

Eliminate non essential

Great coders eliminate all non-essential code and create code that is as simple as possible but no simpler. Don’t accept the first draft of code, improve the naming and reduce the code to the essential. You can refactor the code when it has unit tests you can see if your change has broken the code.

The good developers keep code quality high by reducing the technical debt in the system. An effective way is to control technical debt is to not put it in. Getting code to work and is the initial goal, the second stage is taking the initial code and reducing the non-essential and achieving the same outcome.

It’s a case of looking at the code and asking yourself, is this line necessary or can I do this with fewer lines? Be mindful the goal is not the least amount of lines but removing the non essential you are improving the maintainability.

Complexity

Don’t tackle complex requirements with a complex code that is is hard to read, understand and difficult to maintain. Extra code contributes to the complexity and adds to the noise.

Complexity leads to stress and increases the difficulty of managing the code. Signs of complexity are large classes and methods. Debugging which can take days because it’s spaghetti code with little separation of dependencies.

Complex requirements must be broken down into multiple focused solutions, which are used to create a great whole solution. You don’t tackle a complex solution with complex code; you break it down into smaller components.

Design patterns

Design patterns are examples of taking a complex problem and crafting a simple solution with separate dependencies.

Design patterns are clearly named, well design and simple. There is a beauty to the code of a design pattern, no line of code is wasted and every line has a purpose.

The naming of design patterns makes it obvious

  • Factory
  • Repositry
  • Singleton

The patterns and code are not the first draft but the refactored and final draft. The code has been renamed and reduced to leave only the necessary code.

Conclusion

The focus of developers is on the creation of code but the quality of code is how well developer reduce the code to only what is necessary.

Every line of code has to be maintained.

More lines of code adds to the technical debt and complexity of the whole code set.

The picture is from here