I’ve been with metr for a year now working as a software engineer, focusing on backend and infrastructure. Among the many things new and surprising about the industry itself, the tech stack and the team, one that really stuck out and has been living in my head ever since is pair-programming. I realized a few months in, after the onboarding started to settle and my comfort with the code and the processes was growing, that this was a very unknown territory for me, one that I vastly underestimated.
Before metr, I was only ever part of a few random and hasty pair-programming sessions. Both of those times happened because something urgent needed to be solved: tests were failing, setup of a new tool involved knowledge that span across more departments, etc. This wasn’t more than 2 people sitting at one computer, involved in working their way through a solution.
What I learned in the past year is that pair-programming can be more than incidental and that its taking place is shaped by a core need of wanting to do things meaningfully. On a personal level it involves calibrating attention span and careful management of emotions and executive functions. We, at metr, pair every day. We usually decide during planning who pairs on what task. Pairing for us is always about communication, we enter the process by talking about how to take decisions together, investigation approaches, plans to follow.
But it’s never only about the code. Pairing requires sharing of mental space and thought operations with another human being, it’s a space where one inevitably becomes vulnerable, both as a human and an engineer, on many levels. There is a particular form of world building that takes place in our sessions, as I see it. One that exposes and enhances both aspects: I confront my limitations as a a software engineer, learning to show all the things I don’t know I’m willing to learn while drawing meaning from interacting with my fellows. Sometimes a technical decision on the truthfulness of a new field in a table will have us spiraling in and out of a discussion about the philosophy of it all: life, software, you name it.
For me personally, pairing works also as a knowledge transfer method, as the mere utterance of new insights and the producing of new understanding are both an occasion to help and learn in sync.
Making communication our primary tool gives our pairing sessions the time needed for the most suited implementation of a solution. We take our time to look at the bigger picture and we use TDD to help answer questions. We allow our code to ferment™.
And that’s where our culture continues to live and evolve. Not only are these practices shaping our team identity, but they’re also creating positive cultural experiences that make us enthusiastic of working here, together. One recurrent mention in our retros is one or the other’s amazement at how the chemistry that we allowed between us is shaping the quality of our code, decisions and ultimately, products.
