From an engineering perspective we judge code by its complexity, test coverage, etc. These are all empirical measurements that give us an indication of the qualities that the code base possesses.

We say things like: "we have 90% code coverage and 2764 unit tests".

We may give ourselves targets such as:

• No class longer than 100 lines of code;
• 100% code coverage for new tests;
• Treat all compiler warnings as errors;
• and so on...

These are all mechanical, empirical, engineering type things and there is nothing wrong with that.

I think there may be another aspect to the way we think about software; a more human-centric way - Compassionate Coding.

All human beings are the same. We all want happiness and do not want suffering.

Compassionate Coding has two aspects: compassion for the end-user and compassion for the next developer who has to understand our code.

Compassion for the End-User

We have all been frustrated while using bad software. Whether it be a poor user interface, a lack of features or just error-prone software in general. Think of how using bad makes you feel. You may feel the apprehension before you even load the software as you know it's going to be a painful experience.

As humans we tend to try to avoid pain. No one likes to feel frustrated, angry or sad. Unfortunately bad software can invoke these and other highly negative, painful emotions.

Just as I get angry using bad software, so does the End-User

End-Users are probably not developers, probably have no idea of the complexities involved in writing software, but like me they are human beings who have thoughts and feelings. In this regard I am no different from them. Just as I get angry using bad software, so does the End-User. Just as I love using great software, so does the End-User. We are the same.

By complimenting our engineering viewpoint with compassion, we may feel closer to our end-users and give us more determination to build great software. This can only end up benefiting us both.

Compassion for our Fellow Developers

Anyone that's ever worked with poorly written, legacy software knows the feeling of opening a file to be assaulted with thousands of line of spaghetti code. If this has happened to you, how did it make you feel? For me my heart usually sinks, I know that I am in for a struggle to understand what is going on even before I get to changing something.

There are a lot of negative emotions that can come into play, part of being a software professional is to get past the initial wave of nausea and get on with the job. And we do.

This kind of experience is a form of pain.

Usually we say something like: "I'm going to refactor X to make it testable and cleanup Y to remove commented-out code". How often do we say: "I'm going to refactor X and cleanup Y so the next developer who has to work with it doesn't suffer"?

By reducing frustration and pain at work we can increase happiness. Who doesn't want to be more happy at work? Happiness is also a factor in productivity, so again we all win in the long run: companies, developers, managers and end-users.

SHARE: