Engineer pain vs user pain

A lot of software engineering teams talk about “pain” on a regular basis.

Usually this refers to difficulties around technical debt, design decisions, refactoring and so on. It rarely seems to refer to issues that affect users or the rest of the business.

For example, moving to microservices is often touted as a way to “reduce pain”. Perhaps we can reduce pain by putting HTTP calls in between different parts of the system, but it’s rare that this improves things for users in any way.

Maybe it’s actually HTTP that’s the cause of the pain in that example, so we should use RPC instead to reduce pain. Notice that this is even further removed from the reality that users exist in, yet it is the sort of thing that engineering teams seem to gravitate towards when discussing pain.

The idea of “eating your own dog food” gets at this idea, because it gives some anchoring in the world that users live in. Without that kind of anchor, it’s easy to float further and further away from improving things for users and the business.

What pain do our users experience? How can we reduce it?

The inversion of that is becoming the Bastard Operator from Hell, who actively works to increase user pain.