Pair programming! As polarizing a topic as the Editor Wars. People love or hate pairing, and for good reason! It’s a tough skill with benefits that aren’t always immediately clear. It can be frustrating, feel slow, and even be a source of uncomfortable interpersonal conflict.
You’ve experienced the FOG before. A project blows through the estimated timebox but the executive team wasn’t informed of this Fact in a useful manner. We built a feature thinking the end user wanted to reach this objective but really, they wanted that objective, which after being interpretted through our personal lens; resulted in a feature that doesn’t get used enough to justify the expense.
Pairing (and to a larger extent, mob programing), is the best way to illuminate a path through the FOG. The closer we work with someone else, the more we actively expose our decision making, and more frequently we create opportunities for others to re-align our understanding of the facts, operations, and goals of our work; the greater the probability we avoid falling off a (metaphorical, hopefully!) cliff.
Now, being tossed into a room, told “Go pair! It’ll make you more efficient” and then left to your own devices isn’t exactly the ideal learning experience. The benefits of pair programming are directly related to both how skilled people areas well as how conducive the environment they are in is to pairing.
If you’re an engineering manager within the continental United States who wants to bootstrap your team’s pairing techniques, consider backing us at the $7,000 level. This gives you a 30% discount on our 1-day pair-programming workshop we do in collaboration with Marlena Compton.
And as always, if you want a more involved pair programming education experience, you can always reach out about 1 on 1 coaching or training for your team.
