I recently gained new insights from pairing with developers of varying skill levels. While I’ve always been a big believer in finding good mentors and working with the best people I can find, I now have a greater appreciation of the benefits of pairing with someone of the same skill level as me.
When I pair with a developer who is better than me, sure, it stretches me and I learn a lot from the experience. I’ve paired a ton with Yi and it’s helped me become a better developer much faster than I could have hoped to be otherwise. But great developers can take shortcuts that us mortals can’t. Having gone through the steps A-B-C-D-E thousands of times, they can recognize the same situation and jump from A to E with a solid base of reasoning. The pattern is both ingrained and alive. And sometimes I haven’t gone through A-B-C-D-E enough to do the same. So sometimes I catch a glimpse of it (a fleeting one, out of the corner of my eye) and take a shortcut that turns out to be correct, but my reasoning isn’t solid -I just got lucky. And other times, I might start to go through all or some of the steps only to have my pair show me the shortcut. A good bit of discussion later, I usually acquire the reasoning I need, but sometimes there is just no substitute for direct experience.
This is one of the reasons I often spike little projects by myself -more repetitions of A-B-C-D-E. To that end, I find that working by myself is crucial to my continued development. Sometimes you just have to be free to experiment or to mess up.
When I pair with someone who is the same level as me, we frequently take a longer route. Our discussions are shorter because we’re at a similar place in our thinking. Sometimes if I take a shortcut my pair doesn’t understand, I’ll break it down to show a sort of time-lapse version of the evolution from the long route to the shortcut. This both solidifies my reasoning and helps my pair gain a better understanding of what we’re doing. Talking through a design choice often leads to the needed clarity, but I find that I am more of a visual learner, and actually doing the refactoring step-by-step to get from A to E gives us both a deeper understanding of what we’re doing and why.
Actually, this movement to clarity doesn’t just drive our code when pairing, it drives our development process as a whole, but that’s a story for another time.