Pair (more than) Programming
To kickstart this publication, I would like to share with you a story of an activity that was totally unexpected to me as a CTO and also truly amazing. I couldn’t come up with a good name for it, so let’s just call it pair leading.
The Loneliness of the Long Distance Runner
So this is my story, it’s not an uncommon one, let me know if it sounds familiar: You start as a developer with some particular talent to understand people, systems and/or problems. You are part of a team and you enjoy it. Later on, after several projects, your passion and hard work get you to lead a team. You’re still part of that team (just in a different position) and you still have colleagues at your level (you’re most likely not the only team leader in the company). If you keep going through that path (as I did… twice in my life already) you eventually find yourself in a more managerial position (I was the Software Architect once, I’m the CTO now) and then… you are alone.
When I was just a developer, I enjoyed pair programming. I have to admit I never did that on a day-to-day basis as XP recommends, but I did have really long pair-programming sessions that lasted longer than a single 8-hour day more than once.
I don’t want to repeat all the benefits of pair programming here, they are extensively listed and discussed online, together with its downsides. I will just say that the key benefit for me was always focus. Pair Programming was super-helpful in times when I (and my peer) needed to really get our heads into the subject at hand and avoid distractions.
My Current Situation
As I said, I’m InakaESI’s CTO now, but I’m lucky enough to have more than one current role at Erlang Solutions (our parent company): Besides my role as CTO, I’m an Erlang Trainer and, more relevant to this article, I’m one of the company Tech Leads. That means I’m not actually alone: I do have others in my position within the company. As a matter of fact, there is one of us for each office.
We work independently, but every two or three weeks, we have an online meeting where we share our experiences and we make company-wide technical decisions and plans. Those meetings are great (I’ll talk about them much more in an upcoming post), but we usually end up feeling that they’re still not enough. There are many things that we don’t have the time or the capacity to properly discuss on those calls and after each meeting, every one of us goes back to their role as a Tech Lead in their office. We do keep in touch through Hipchat and Skype (if needed) but it’s in no way similar to actually work together.
The Experience
So, two weeks ago I had the chance to go to another one of our offices, located in Kraków (Poland) and meet Michal Slaski there. He’s Kraków’s Tech Lead.
An amazing thing happened: right at that moment, we had a huge proposal to write. A proposal that required some components to be built at Kraków office and some at my office (Buenos Aires, Argentina).
It was not the first time we were faced with a task like that one. In similar situations, Michal and his people would’ve worked on their part while I would’ve worked with my people on ours. Eventually, somebody would’ve combined both pieces. Both Michal and I (and others) would’ve reviewed the final result, suggested editions, applied the proper patches, reviewed everything again, etc… It would’ve probably took us around a week to get it done. And don’t even get me started on timezones and all that jazz.
This time I was there, in Kraków, with Michal. We had a day (8 hours) to work together on this. And so… we decided to pair-do-this-thing! (I really need a name for this). It was a really intense day. It was a really productive day. As you might have guessed by now, of course we wrote the whole thing that day. And of course we didn’t do it just by ourselves. Both our teams and several other people were involved in the process, but we wrote the core of that document ourselves and it was a big thing.
The Benefits of Pair-Leading
The key benefit of this technique is the same one as pair programming: focus. We spend that whole day completely focused on the task at hand. We did almost nothing else. Working on the same project the whole day may seem reasonable for a developer, but for a Tech Lead… I can’t even remember the last time that happened to me.
The usual benefits are there as well: Collective ownership and Fewer interruptions were particularly noticeable. But let me say a word about Better output (“better code”, if you follow the link): When you write a proposal that involves components not built by your team, you end up assuming stuff about them just to keep writing. More often than not, you end up finding your assumptions were wrong when the other Tech Lead reviews your part. Fixing your estimates after-the-fact is much harder and error-prone than just validating your assumptions beforehand. That’s something you can easily do if you’re sitting next to your fellow Tech Lead, where instead of assuming you can just ask.
Also Mentoring: Learning to be a good Tech Lead is not an easy thing and it is particularly harder when you’re alone. While I was a developer I used to suck knowledge out of every single colleague I happened to work with. As a CTO/Tech Lead, I usually find myself without anyone to suck knowledge from. This pair-leading experience was a great opportunity to learn from Michal and trust me: I learnt a lot!
Conclusion
So, if you’re not the only Tech Lead in your company and you have the possibility, don’t miss the chance to do some pair leading with your colleagues. It will be as rewarding as pair programming is for developers.
And if you can think of a better name for this technique, please share it on the comments below!!
