Two developers shared one keyboard, solving problems together.
The senior developer watched them debate each line of code.
“Which of you is writing the code?” she asked.
“Both of us,” they replied.
“Then which of you is learning?”
Sitting with the Koan
At first glance, this koan seems to have an obvious answer: both developers are learning. But the senior developer’s question invites us to look deeper. When we say “both,” are we really paying attention to the nature of learning itself, or are we giving a reflexive answer that lets us move on?
The developers confidently claim joint ownership of the code they’re writing. They understand the collaborative nature of their work at the keyboard. But the senior developer shifts the focus from the visible output to the invisible process. Learning, unlike code, can’t be committed to a repository. It can’t be seen in a diff or measured in lines changed. So when two people share the same experience, are they really having the same experience at all?
Consider what happens in pair programming: one developer might be learning a new API while the other is learning to articulate their thinking more clearly. One might be discovering edge cases while the other is learning patience. One might be absorbing technical knowledge while the other is learning to let go of their attachment to a particular solution. The question “which of you is learning?” reveals that learning is not a shared resource split between two people, but rather unique transformations happening within each individual.
The deeper teaching here is about awareness. When we work together, do we notice what we’re actually learning, or do we focus only on what we’re producing? When we say “we’re both learning,” are we speaking from genuine observation, or from assumption? The senior developer’s question is an invitation to pause and ask: What am I learning right now? What is my pair learning? Are we even aware that learning is happening, or have we become so focused on solving the problem that we’ve forgotten to be present to our own growth?
Pair programming, like all collaborative practices, offers us a mirror. In watching how our pair approaches problems, we see our own habits reflected back. In explaining our thinking, we discover gaps in our understanding. In disagreeing, we learn where our certainties come from. The code we write together is temporary, but the learning – if we’re awake to it – changes us permanently. The question isn’t really which developer is learning. The question is: are we paying attention?