Best code is the one you didn’t write
One of the best quotes I ever heard from a Senior Staff engineer goes something like this:
The best code is the one that you didn’t write.
Makes sense, doesn’t? It has no bugs, all tests pass because it needs none, and it doesn’t have breaking changes!
As engineers, we tend to be very proud of every creation we make, and code is a significant one. However, we often see people jumping straight into the editor, writing code, and opening pull requests when we should instead be focused on understanding the underlying problem. Every line of code needs tests, usually defines an interface it operates within, and has other functions or systems that rely on it. We become responsible for maintaining, upgrading, and refactoring these lines of code as soon as they hit production and people rely on it.
One great example I like about this topic is one from Michael Nygard - everything we build has a future cost, in which he compares a software project as a road project. He mentions, what if we notice that this road is not longer needed or its cost to maintain its bigger than the value it delivers, the problem is that this road has many connections to it, people and business rely in this road. So shutting down this road require new roads to be build, manage all the neighborhoods that were connected to this road, and after all still need to remove all the asphalt and infrastructure.
Our code and systems are just like that, specially talking about big companies and systems. Usually refactors or sunsetting systems we cannot just shut it of as we could in a personal project. So its good to only write what you need to write.
We must maintain what we build, and that requires expense.
- Michael Nygard
Problem with new code
Every new code, obviously, hasn’t been used, largely adopted, or learnt upon. This way, it’s always something new that can go wrong, and more surface you need to monitor and evaluate for value delivery. We should never forget—or fail to respect—all the code that is currently running and its history. So before shipping a new endpoint that can quickly become a dependency of multiple systems and teams, think about its purpose and how it expands your area of work.
This uncertainty and risk associated with new code is what makes code a liability for your company. This makes even more sense when we call old code that we need to maintain and might even be suboptimal: technical “debt”.
Real underlying problem
Although it can be a problem in the future, code is inevitable, so we need to make the best we can for the software we write. This starts in the principles, understanding the problem behind the problem we want to solve. So working it code should be a mindful action and if not under pressure from external factors like a crash, hard deadlines; be thoughtfully designed and defined.
Code sometimes should be treated as a last resort when no other options exist. Each addition to a system carries weight and adds complexity over time. Code must be weighed carefully against other paths that minimize risk and future costs. For example, consider a screen that we need to make more performant, maybe changing the animation of a loading button can do the trick without needing to go byte deep into performance.
Conclusion
The best engineers understand that their value is not measured by lines of code written, or how much they ship into production, but by the thoughtful decisions they make to keep their systems simple, reliable, and efficient. So before taking a “code loan” to deliver a project keep in mind that this code might need lots of babysitting in the future.