June 22, 2016

The most important skill you can learn as a software developer...

A few years ago, I missed a flight (and the first night of a conference) because well...computers are terrible.

I had gotten to the airport about 1.5 hours early: Not a huge amount of time to spare, but more than enough for a small, not-so-busy airport.

I had already checked in online the night before, and all I needed to do was use one of those self-service kiosks to print out my boarding pass.

I went to do that, and was happy to see there was no one using the machines. A few seconds later, I found out why: the system was offline and couldn't look up or print out passes. A sad "See attendant" message showed up, and so I got in line with everyone else to go to the check-in desk.

The line moved slowly, but not so slow as to have me worried. The security checkpoint line wasn't very busy, and my gate was so close by that I could actually see it.

But when I finally got to the check-in desk, I was told that they couldn't print me a pass, and that I'd have to be on standby for another flight, many hours later. I tried to explain that I had plenty of time to get to my gate, but they wouldn't budge. They insisted that there was a strict cutoff at 45 minutes, and that they couldn't do anything to help.

Eventually, the attendant explained to me that it was just how their system was built. There was no way, at least from the computers they were using, to print out a pass after the cutoff point had passed. It didn't matter that there were 43 minutes left, there was no way to override the software.

Now, who knows if that was actually true. But my own career as a software developer tells me there is no reason why it couldn't be. Someone told a programmer to disable printouts at 45 minutes before a flight, the programmer implemented it, the code was shipped. A ticket in some sort of enterprisey hellscape of an issue tracker was probably closed.

Maybe the airline bought this software from a third party vendor and couldn't fix the issue if they wanted to. Maybe they built it themselves and just didn't think things through. Or maybe they actually wanted to enforce the rules consistently with no exceptions. No matter what, the end result is a system that's pretty hostile to humans. It makes it so that the service agents have to treat customers poorly, even if they want to help them.

Far too many software systems are like this.

So what is the most essential skill for software developers? To practice empathy, and not just locally, but on a global, system-wide manner. It's hard, because it involves visualizing the entire value chain that exists between you and the people who end up feeling the effects of your software.

With this in mind, I wrote an article on Empathy for the O'Reilly Ideas blog. It has a totally different backstory from this email, and I think you'll enjoy it.

I'd love to hear stories about how empathy plays a role in your own work (for better or worse), and I'd be very thankful if you shared a link to the article and/or forwarded this email to others who might benefit from it.

Looking forward to hearing from you!