Raimund Krämer

Technical empathy is one of those concepts that seemed so obvious once I was aware of them, and yet it was quite a revelation when I first heard of it from Michael Feathers a few years ago.

“The ability to see the system from the point of view of the caller of your code, not just the point of view of your code.” This is something that I had already been doing for a long time, but was only kind of half aware of it. Enough that I “felt” that I am doing it, bot not aware enough to explain it, especially to newer developers. Often there was a situation where I would try to explain a concept to another developer, and I could explain why it feels correct to design something in a certain way and evaluate pros and cons of the solution, and the other developer would understand the reasoning, but I couldn’t quite explain how I thought of that solution in the first place. This was frustrating, because it seemed obvious to me, but at the same time I knew that it wouldn’t have been obvious to myself a few years earlier.

The concept of technical empathy makes it much easier for me to explain how to think towards a possible solution. Explaining to a junior developer that this way of thinking has a name, and having this metaphor of putting yourself into the perspective of a certain part of a technical system, also makes it easier for them to understand. “Imagine you’re the caller and then look at your API again. Zoom in. Zoom out. Look from the outside inwards. Look from the inside out. Now switch to the perspective of the caller’s caller. What do you know? What do you not want to know about? Who are you right now?”

I find this especially helpful during test-driven development, as well as for software design in general, for example to create strong types instead of accepting strings and primitives by default.

If we look at the picture above, on the left is the higher-level perspective of the caller, which is closer to the problem domain. On the right we have a more technical perspective, the how of the solution, closer to the solution domain. We switch between the perspectives at the appropriate times to design APIs that are easy to use and test. Developers might often be prone to fixate too much on the technical perspective without being aware of it.