The Compassionate Programmer

Software is quite miraculous if you think about it. It starts as a random, incoherent set of ideas, and after some pondering, often too little, text is written down on a computer. The text has a particular structure and rules, but it’s just text. Anything from a dozen to millions of lines depending on what the program is supposed to do.

Then the magic happens.

The program is run, executed, launched, double-clicked, and things start to happen. Physical things. Monsters are drawn on screens, robots move and build things, movies appear on a TV, and rockets are launched and land again. Almost anything could happen.

By simply writing text, a programmer can create machines that change the physical world.

That is astonishing and one of the reasons why some people are so passionately obsessed with Programming. They can build anything they can think of quickly, easily, cheaply, and without any demands for physical materials.

Programs can be beautiful in the same sense that mathematics is beautiful. There is science and art in software. And there lies the joy and pain of being a programmer. When done well, the sense of achievement and joy is enormous. Failure, manifested as bugs and a million other ways programs fail is painful and keenly felt by the programmer who cares.

Success and failure are very, very, personal to programmers.

Unfortunately, there are very often a great many constraints placed on the professional programmer in the course of a commercial project. Very many of those constraints are arbitrary and imposed by those who don’t know better and should not have any influence over the technical details of software production. Typical constraints include programming language, poor development machines, databases, messaging systems, libraries, architecture, design, test infrastructure, and so on.

These constraints often reduce the options available to programmers and reduce the quality of their work, leading to stress and frustration, and always slow delivery and bugs.

Given all this, it surprises me how vicious programmers can be about each other’s work. There is only one reasonable way programmers can work without fear and stress: compassionately, kindly, and respectfully.

Aside: I should say here that I have been guilty of not following the advice I am about to give and I deeply regret it. I was stupid. If I ever treated you badly, I apologise.

Compassion for yourself

Programmers can be as harsh on themselves as they are on their colleagues. They are confronted by their human failings constantly, as machines are very hard task masters. Software is either right or wrong, it is never approximately right or roughly correct. Machines have endless energy for reminding programmers of those facts.

It is true that sometimes software is indeed approximately right from a user point of view, a bug might be trivial and does not need fixing immediately. But to the programmer, a bug is a bug. The software is wrong. Their software is wrong.

They have failed.

So the programmer must accept their human frailty.

The only defence against a continuous reminder of one’s limitations is to embrace it. Use processes, tools, and techniques to minimise the errors, control their scope and resolve them. When errors occur the only thing we can do is to learn from them, improving the tools and process, and move on.

Above all do not judge yourself too harshly. You did your best, and now you’ve learnt something.

Compassion for other programmers

Programmers are doing the best they can in a context you may not understand. With rare exception, they are not stupid or malicious. They are you. They will work differently from you, and perhaps you won’t agree with their ways. But they are their ways and perhaps that works better for them than they might for you.

Respect them as you would wish them to respect you.

One of the most difficult things to do is to take on an existing codebase. It’s also quite stressful to hand over a codebase to a new team because we know all the things that are wrong, bad, need fixing, or could be better. We fear how we might be seen as the code is the residue of all our thinking and work.

So when taking on a codebase, be mindful that there will be unpleasant parts but that should not be seen as a reflection on the original programmers, whose constraints and situation we cannot fully appreciate.

Compassion for the wider team

This is possibly the hardest of all. It takes more than programmers to produce working software and most non-technical people have very little idea what programmers do, how they do it, the effects of limitations placed on them, and the damage done when asking programmers to compromise. It is hard to appreciate what you cannot see and software is largely invisible.

Perceived complexity is inversely proportional to the distance from the observer. We all trivialise what we don’t understand, most of the time, and we are usually wrong about that.

And so programmers also need to remember that as complex as their work may be, it is a mistake to believe that it’s all that matters or that others are not struggling in their own worlds with complexities we may trivialise.

Compassion for Users

Users can be as harsh as the machines that run our programs. They are trying to get work done (or enjoy themselves) and impediments as a result of bugs or poor UX/UI design are frustrating.

Bugs are something programmers can appreciate as being frustrating. But comments about poor design feel personal because it’s telling us our careful thinking was wrong, and our hard work is unappreciated.

As programmers we can fight or embrace this feedback; embracing it is always the better option.

Not only will you learn and improve, but you will also gain the respect of your users who will, almost always, become more appreciative as you include them in your design process.

Programmers are also users, we would do well to remember that the software we use is also written by others who should be treated with kindness.

What goes around comes around.

Imposters

On a final note, it’s worth mentioning Imposter Syndrome. There are very few programmers I’ve met that don’t suffer from it to some degree, and much of it is rooted in the fear of failure because failure is taken to mean, “I don’t know what I’m doing”.

I’ve worked in teams in which there was no fear because the entire team knew we were all learning, we all make mistakes, and we would all support each other when things went wrong. Imposter Syndrome was largely removed because we knew we would not be judged for not knowing something, or failing in some way. It was removed by compassion for each other.