This is a cross post from my blog mokacoding.com.

Shortly after starting my career as a software developer a much more experienced person -unfortunately I don't recall his name- told me something that stuck with me over the years. "The best developers I've ever met spend more time removing code than adding it". The more I work in the industry the more I appreciate the value of writing less code.

Photo by Markus Spiske on Unsplash

I love writing code. You can make things happen with code, it's like being a wizard. I love the actual act of typing too. The clickety sound of the keys, the feeling on my fingers -even on a 2016 TouchBar MacBook Pro. Give me a computer and an hot beverage to keep me company and I could type my day away.

As software developers it's easy to lose ourselves in the pleasurable experience of writing code. It's what we're good at, what we're comfortable with. This is the problem, too often we get sucked into the act of writing without questioning it, and end up with too much code.

Code is a liability. The more code we have the harder it is to maintain it. More moving parts means more chances that something will break. The bigger the codebase the more challenging it is to understand it, you get crushed by the mental overhead.

From an efficiency point of view, if we can get the same result with less code we're probably better off for it. Hardware, compiler, languages, they'll keep getting better at a pace our brains can't match. There is value in optimizing for understandability.

If we want to call ourselves software engineers instead of code monkeys we need to make a shift. We need to move from the mechanical act of writing code to make things happen, to the thoughtful building of systems that are small, efficient, and easy to work with. That's what we're paid for, to solve problems, not to write code.

To be spending more time removing code than adding it is not just a matter of refactoring. Yes, refactoring is the best way to keep the complexity and size of your codebase in check, always adapting it to be easy to work with. There is more to it though, writing less code is about resisting the urge to start typing, and thinking through things first.

Ask yourself if there's a way to achieve the same result with less moving parts. Instead of copy pasting for the third time it could it be possible to extract some of the functionality in a dedicated component? Can you write a function encapsulating that sequence of operations so that readers can understand what it does without drilling into each of the steps?

We can take this a step further. As technologists we love to build tech to solve problems, but sometimes tech is not the right answer. Question each new feature request, each addition to your product. Do you really need it? Is it going to make things better for your users and customers? You'll be surprised to find how many problems you can solve by subtracting rather than adding.

This approach is an antidote to boredom, a recipe for continuous improvement. It doesn't matter how experienced you are with a given framework, language, programming style, you can always challenge yourself to find better ways to work. Even if you're so incredibly good that you've reached the technological and physical limits of how little code can be written (which you most likely haven't, sorry to break it to you), you can always move up a level and apply these filters to the product design space.

Develop an intolerance for long code. Whenever you find yourself writing more than and handful of lines to get something done stop and ask yourself whether you might be building something too complex. Can it be simplified? Can you write less code?

👉📬If you liked reading this subscribe here to receive new posts like this one in your inbox.