|
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.
View post:
Engineer pain vs user pain
|