Detach yourself from the code

Customer value trumps code

A colleague of mine once said:

All code is just one massive string; if you get one character out of order, the whole thing breaks.

I have yet to encounter a more accurate description of code. This laconic statement sums up my relationship with code perfectly. I have never seen code as some form of modern-day poetry or artistic masterpiece — a beauty at which to marvel. I see it as a brittle string of characters and a means to an end. If we put the characters in the correct order, we might get software that provides users with value. If we misplace characters, we find ourselves on a call in the early morning hours to put the code back in the correct order.

While this might come across as some churlish diatribe against code, I draw significant value from this perspective. The apathy I have for code is often liberating. It allows me to detach myself from what I have produced, making me far more receptive — and resilient — to criticism. Chidings are no longer personal. This lack of adulation for the code I have written means I have no qualms with rewriting my software or trying out new ideas. Everything was eradicable. This is just as well; I wager most of the code I have written in my career no longer exists.

So it strikes me as curious when I meet an engineer with a close relationship with their code. It's been common throughout my career to encounter an engineer defending a piece of software they have authored, as though they had projected their very personality onto the characters on the screen. Heaven forbid they refer to software as "my baby". The problem with this mindset is it makes it nigh impossible to critique such an engineer's work without them immediately going on defence. Whilst we must convey deference as those offering the feedback, we still need to give criticism.

But why do I have such a nonchalant relationship with code? I can lay most of the blame at the feet of my former leaders and mentors. Having predominantly worked in start-ups with relatively low head counts, these teachers of mine were typically senior people in the company. Lead engineers, CTOs, CEOs, founders, directors, you name it. And whilst these folks were indeed more on the maverick end of the spectrum, love them or hate them, such free thinkers are often one thing: they are brutally honest. These guys were trying to create a company; they didn't have time for delicacy. I discovered this early on in my career. I would demonstrate a new, seemingly inconsequential feature, to say a founder, only to have it mercilessly ripped apart in front of me. When such encounters are almost daily, you'll be amazed at how quickly you learn to detach yourself from the work you produce.

Detachment becomes a necessity for an engineer to take on criticism of their work. When someone else judges your software, if you've detached, you migrate from author to observer. You, too, become a judge of the work, which is one way you grow as an engineer. An engineer who can take criticism has a superpower: humility. You can accept that you are flawed and need to improve. But in getting better, you are not solely becoming a more capable engineer: you are also shipping software that provides the maximum value to your customers.

So is code important? Of course, it is. But let's do our best to detach our emotions from the string of characters on the screen and instead channel those emotions towards making valuable products that solve problems. In that mission, we can take pride.