In the last post I talked about deliberate brevity – taking time to think through a problem and finding a solution through concise coding. But writing as little code as possible is most certainly not my goal these days. In fact, as a goal unto itself it sets you onto a very dangerous path.

Estimating roughly, I spend 10% of my time writing code and 40% of my time debugging it (including code written by others before me). Let me repeat that again. I spend 4x as much time reading and tweaking existing code than writing new code. I’m not that interested in writing tersely. I’m much more interested in writing clearly, for the benefit of everybody that is going to be looking at that code down the line – future me included.

At times we are faced with complex problems. It’s only natural to come up with complex solutions. Complex solutions create an illusion of being a master of your domain, impressing your peers and beefing up that pitch to bump you up to being the “senior engineer, level 5C” for the next promo cycle. “Nobody knows that module better than Bob. In fact, Bob is the only one who understands it at all.” I’ve seen enough code written by Bobs. To be honest, I don’t like where the Bobs of our world are taking us.

It takes time and patience to distill a solution to its most vigorous form. And it takes skill and humility to remove complexity from the solution. To practice the craft of writing clear code. Code that is clear to read, clear to maintain and clear to evolve. Finding clear solutions to complex problems is the ultimate mark of our craft. It’s time to stop admiring complexity and start appreciating clarity.