Software Development with Empathy

I’m hoping this will be the first in a series of posts about some recent trends in the way software is developed, going beyond the raw technologies involved.

Around nine months ago I was fortunate enough to be working with a team at Pivotal Labs – a consultancy (although I suspect they might baulk at the term) specialising in Extreme Programming which works with clients to train engineers in pair programming and test-driven development.

One of the core principles by which Pivotal operate is “Always be kind”, which might easily be dismissed as comparable to Google’s famous “Don’t be evil” mantra. At its root is the concept that a team functions best when there is a sense of empathy. As one team member phrased it to me: “egos are left at the door”.

It’s worth defining what this actually means, as it’s very easy for companies to get lost in a series of platitudes in an effort to change its culture. Empathy means taking the time to listen to everyone an seeking to come to a solution to a problem as a team, and seeking to understand colleagues. Adopting empathy as a core principle for a team involves recognising that no team member is capable of doing all of the work – and if they are there is something fundamentally wrong with the team structure.

Crucially, empathy does not just mean giving way to the loudest voice or ignoring bad work. I’m currently reading the excellent book Radical Candor by Kim Scott which describes “ruinous empathy” – the idea of skirting around an issue so it isn’t addressed. Building a team founded on empathy involves caring about people, and caring about how they do their work and how they learn.

It’s a very difficult balance to achieve, but an important one. Empathy might seem like an obvious requirement, but historically it’s been discarded in favour of “rockstar developers” – a fantasy that a genius-level programmer can sit at a terminal and build brilliant software provided they are left undisturbed. The balance seems to be tipping the other way, which is good news for all engineers.

XKCD: What happens when coders want to read a comic

If you keep up with XKCD (described by its creator, Randall Munroe, as “A webcomic of romance, sarcasm, math, and language”), you might have seen the comic posted on Monday entitled Time. It initially showed a pair of people sitting on the beach, but half-an-hour later had changed slightly. Thirty minutes later, it had changed again, with one of the characters lying down. As the day progressed, so did the comic – by yesterday evening the characters had built a sandcastle.

At this point several (myself included) might have assumed the comic was over, but the picture then zoomed out over the next few hours to reveal a second sandcastle being built. At the time of writing this post, the comic is still changing and is on its 178th version).

Although the concept is interesting, it’s also worth keeping an eye on the way those reading XKCD have reacted to the comic. One reader developed a system for recording each change and scrolling through them, while others found methods to compile them into a single animated .gif image.

It does show that often when those with a technical ability want something done, they may well find a way to do it themselves, to the benefit of anyone else interested. Something as simple as a changing webcomic has resulted in a few different tools for viewing it in just a few days.