You've probably seen a classic presentation on code quality. Do it like this, not like that. I'll admit that I was one of those overzealous young engineers that thought I'd stumbled upon the secrets to beautiful code and wanted to share them with the world in a tech talk. I'm happy that I did that, and that others continue to do so as well - it means people are passionate about our craft and want to teach. The problem is that - in my experience - people very rarely change their syntactical coding habits based on a slide at a presentation.
The reason is that all of those talks skip over the most important part of them. Those talks never discuss why readable code is so important.
Do Engineers Need Empathy?
Uber has grown a lot in the time that I've been here, which means that I've had the polarising experience of interviewing something like 150 to 200 engineering candidates. In almost all of them, I ask people to tell me what they think good code actually is. Generally (and I wish I kept empirical data on this) most of the candidates tend to reply with a similar list; fast, readable, maintainable, modular, simple, etc.
I then like to ask people, given that those are their traits of good code, "what are the most important skills or traits of a good programmer?". This one usually garners a little more thought, but almost always ends up with a selection from smart, creative, logical, inquisitive, careful and more. However, one thing is always missing; empathy.
If readability is your goal, then empathy should be in your list of traits. In fact, I'd argue that from a higher level, empathy is one of the most important traits of a programmer.
To understand why empathy is so important, we have to take a look back at everything that programming has unlocked for the world in the last 50 years. The internet, instantaneous communication, accessible transport (preach!), revolutions in agriculture, genomics, the list is endless. In one way or another, programming has helped to revolutionise so many parts of our daily lives and will continue to do so for a long time into the future.
So why does this mean empathy is important? Well, Ray Kurzweil's law of accelerating returns states that not only are we growing, but that our rate of growth is also growing. Code is unlocking the ability for us to advance to the future at a faster rate. It stands to reason that the faster and better that we can teach people to code, the faster we'll reach that future.
I'd argue that our most important job as programmers isn't to make money or to ship features. Our most important job is to teach the next generation of programmers - the other stuff is simply a means to an end.
We have to get better at teaching, and that starts with writing better code ourselves. Writing code is not just for you, it's for everyone. We're all teaching the people who come after us, just as we stood on the shoulders of giants when we learnt ourselves. If we want them to learn well and learn quickly, we have to write code with empathy and we have develop for humans.
Self, Team, Community
It's a real shame that so many engineers lack empathy when writing code. Fortunately, there is a natural path for improvement which I've personally been able to guide a few mentees through when they landed their first engineering job at Uber.
Many people get into programming because they want to build something interesting and they just happened to learn to program along the way. They didn't care about the quality of the code, only about the outcome - and that's perfectly fine. The only thing that matters at this point was that it works. Those people - just like I was when I started - are in for a serious shock when they first join a team of professional software engineers. It often takes much too long for people to realise that they aren't writing code for themselves anymore - they're writing it for the team. It sounds simple, but if you work in a team of engineers, the team owns the code you write. You'd be amazed at how many people don't understand this principle.
We all spend a lot of time with new/junior engineers working through code structure, variable naming, documentation, etc because they have never been taught that they should care about these things. They've never written code with other people in mind. The reality is that this is so important when writing code that goes beyond your team. The philosopher Ludwig Wittgenstein once said:
If a lion could speak, we could not understand it.
The point is that we have such a different frame of reference from a lion - such a different context through which we communicate our intent, that even if we shared a common language, we wouldn't be able to understand each other.
When you write code that goes beyond your team (e.g. open source), you're effectively broadcasting your communication. You have no idea who the people are who are going to be trying to understand it; maybe it's someone from a completely different culture who, like the lion, will struggle to understand it. They might not even share your spoken language or maybe they'll approach the same problem in a totally different way.
You might not think that this matters, but not considering the frame of reference for your consumers can be a costly mistake. One of the most famous of these has to be when NASA lost the $125M Mars Climate Orbiter when one team used imperial measurements and one used the metric system. They didn't consider the context of their consumers and suffered a catastrophic loss because of it.
We can see that when sharing code broadly, empathetic development is even more important because the consumers always lose so much context. People will be taking, adapting, copying and learning from your code and sharing it with others. The original context you had when writing it will be lost to time. We owe it to the future generations of engineers to at least try our best to explain ourselves. We should always try to keep these people in mind when we write our code, and I honestly believe that we all produce better code when we do.
In the next part of this article, I've laid out my own set of principles which guide how I try to write code with empathy.
Read Part 2 - The Empathetic Engineer: Developing for Humans