Compassionate web development

This week I saw my co-worker Sarah practice her talk for WordCamp Asheville, “DIY User Testing“. Although it’s a practical talk – she told me she hopes people walk out thinking, “I can do that, I can do that right now,” – what I loved about it is that at the core of it is why you should “do that”.

It’s all about compassion for the end user, something that all three of us on our dev team have in common, and it’s one of the things that ties us together as a group.

We don’t always agree about technical matters. Things get contentious sometimes. We might occasionally complain about other groups in IT that we have dealings with. Behind closed doors, of course. But we each, in our own way, always bear in mind the people who will be using our end product, imagine ourselves in their shoes, and stand up for them any time we are concerned that a decision is being made that will make things difficult for them.

I am not sure that most web developers think this way. While I have heard of compassionate design, it seems rare that compassion sneaks into conversation about development.

I was recently loaned out to a project that uses an Angular front end. Now this project is kind of in dire straits so I don’t want to kick it while it’s down, but the accessibility for screen readers on this thing is pretty poor. I could see it as soon as I looked at it. The front end is actually a project provided by another company and clearly a lot of thought was put into how it was put together, so the developers who worked on it were certainly thinking…  just not about anyone who needs to have a direct conversation with some kind of rationally-put-together DOM, as screen readers do.

Accessibility, and baking it into every project, is just one very obvious example of a way that developers need to be compassionate in their work, but the entire stack behind a site contributes to the experience of the end user. In fact, I would argue that even development methodology and the site’s supporting infrastructure impacts the user experience – continuous deployment, for example, fosters a continuous feedback loop with end users, and can help to rapidly unearth and repair problems they’re having.

There’s a feature that we’ve had for years on our intranet home page, written by another co-worker of mine. It’s bookmarks that follow you anywhere you log into the intranet. If there’s a page with a crazy URL that you’ll need for a meeting – no problem, put it in your intranet bookmarks, log into the computer in your conference room and there it is. Many people make elaborately organized lists of these bookmarks and use it as a personal repository of knowledge and reference.

It had a bug for many years that would cause all of a user’s bookmarks to be erased. This happened about once a year and it was impossible to reproduce. Even though it affected only a tiny, tiny number of people over the years, my co-worker sweated it every time it happened. He would always talk with sympathy about “that guy who spent a lot of time getting his bookmarks just right,” whenever someone said the bug was no big deal. I think he actually finally fixed it, driven purely by his compassion for the users of the tool he’d written. It wasn’t a UI problem or a classic usability issue. It was something deep in the back end that only a developer could resolve. A less compassionate developer would have never bothered with it.

If we ever interview another developer for our team, I plan to work in questions designed to draw out how compassionate a developer is (and how confident they feel in standing up for the user, even if they think others in the room don’t support them). We can pretty much tell if someone has the programming chops to be of value to our team. We don’t need someone who can write out how to do recursion on the white board because we basically never need to do stuff like that, or we can learn. I can’t train someone to be a compassionate human being.