Experience

When I was a child, looking at letters I couldn’t read, what was I thinking? I don’t remember. How did I see the world? When I see letters today, my brain has already read them before I can think. I cannot not read. I can’t imagine what it would be like to not be able to read any of this here. I can try to make an analogy and stare at a script I actually can’t read, Armenian maybe. Ես մտածում եմ քո մասին, պապիկ. But that doesn’t answer the question. Today, I know too much about writing, its role, that you can read it, maybe from left to right. I knew none of this as a child. Today, being able to read seems obvious to me, normal. I don’t stand in front of the mirror each morning thinking to myself, “I can read, wow”. I am no longer aware of this skill. I can no longer see the world without it. Learning to read has changed me. I can’t tell myself and what I have learned apart.

We are simply unable to think about logic proofs and […] text passages at a different competency level than the one we currently possess. Once you become an expert, recreating the novice state of mind turns out to be very hard, if not impossible. […] Instead of simply projecting our past selves back to our students, we should take on board the fact that our training has deeply changed us." (You can’t unlearn, and that’s a challenge for teachers, Alexander Jeuk, Valentina Petrolini)

Learning a skill changes us in such a way that we can no longer imagine how someone sees the world without it. What are the implications of this for software development? Software is a field that prides itself on constant learning. Many approaches promise a solution to a problem and developing software means practicing them. Constant trial-and-error, learning-by-doing, followed by solutions that seem self-evident in retrospect. That includes error cases, obvious in hindsight. These skills we learn can be useful or misleading. Foundational or arbitrary. Generally applicable, or specific to a project or team. Learning also means refining an existing skill. Today, I’m reading a text differently than ten years ago. Is any kind of learning subject to a similar pattern as learning how to read?

When you know something it is almost impossible to imagine what it is like not to know that thing. This is the curse of knowledge, and it is the root of countless misunderstandings and inefficiencies. Smart people who are comfortable with complexity can be especially prone to it! If you don’t guard against the curse of knowledge it has the potential to obfuscate all forms of communication, including code. The more specialised your work, the greater the risk that you will communicate in ways that are incomprehensible to the uninitiated. (What I’ve learned in 45 years in the software industry, Joel Goldberg)

What happens when we meet someone who is not able to do something that is truly obvious to us? We might be surprised, perhaps speechless for a moment. We tend to assume that others perceive the world as we do. That they take the same things for granted. We like to associate skill with status, and some of us react with pity, a frown, or dismissively. We can completely lose it when someone repeatedly fails to do what seems natural to us. We say it’s incomprehensible. It happens that interviewers ask a question the answer to which they themselves have only come across in the past few months. They might not be aware of this. What they have learned is still fresh in their memory, but already seems obvious enough. Now, a similar signal is expected from the candidate.

Another example. After one or two years, a team of software developers can no longer assess how complicated its codebase is. Step by step, its members have become used to new levels of complexity over the course of their shared history. Developing a software product is a constant learning experience for everyone involved. It begins with the first problem and its solution we must search for. This takes time. We try, practise and learn to apply different approaches and how to work with each other. When we finally do have a solution, the new skills it involved – however simple – soon fade into the background. They seem obvious now, and we no longer consciously think about them and their number. We don’t even mention them explicitly to each other. We have internalised the skills the solution required. Everything seems normal again. But normal is not good enough, and so we turn to the next challenge, be it assigned, or self-imposed. This cycle keeps repeating and moves the goalposts of what passes for acceptably complicated ever so slightly. The problem of such incremental complexity is that after some time we don’t have a neat collection of solved puzzles in front of us, but a single codebase which implicitly embodies all that we’ve learned on the way. It’s only when someone new is joining that we remember what skills are required to understand all of this – or to consider it normal. Ah, right! Oh no. That is, if we take their reading experience seriously. If we empathize with them. We can’t keep our code comprehensible by just imagining other people, who don’t know what we know.

As soon as you have explored a layer [or skill, PJ] you mechanize it, it becomes automated and people are no longer conscious of what they’re doing they just do it. They don’t pay attention anymore. (The Ghost in the Machine, Joscha Bach)

Once we’ve learned a skill it becomes obvious to us. We can no longer imagine how someone sees our work without it. Until we meet that someone and they surprise us, maybe annoy us. We notice a difference and remember. Reading. Then again, our memory of how we got there is anecdotal and idealises quite a bit. We remain unaware of large numbers of skills and how they interact. Experience is what we call that sum of skills. We’re blind to it. I can’t tell myself and my experience apart. My experience is not a score I’m aware of. It’s only when interacting with others that I get a hint at who I am and where I can apparently switch to autopilot and rely on my experience. The question is then whether I should do that. What I know is obvious. What is obvious is normal. What is normal is correct. This chain reaction comes like a reflex. Unfortunately, none of it is true. The reflex is not a sign of how right we are, but how thoroughly we are shaped by our own history. Experience is not a collection of gold coins that one accumulates, but a challenge. Empathy is the process of meeting that challenge. Taking someone seriously who doesn’t see our work the way we do. This can be exhausting. We like to tell ourselves that empathy is easy, intuitive, instinctive. This is an illusion, it’s difficult to challenge what is obvious to us. In our work, we should keep other perspectives present as actual people who embody them. They have to stand beside us and be, well, challenging. To make tiring what seemed easy before. They should tell us their side of things, and we should listen instead of fooling ourselves into thinking we could imagine their perspective. It’s a good sign when empathy is exhausting. It’s a good sign if it slows you down.

It’s okay to be tired of all that. I am sometimes, too. We’ve heard it all before. We can see it from a mile. Of course you can rely on your autopilot. But you do begin to drift away from the world if you give in to that too much. Why empathy in software engineering? We’re not aware of what we’re doing without it.

December, 2022