Paired programming is great...except of course for when it's not. On those tough days it is a developer's own annoying trip through hell and back with a deadline. I've had it both ways. I have had my most and least favorite days in software while paired up with another developer. I wish I could end this paragraph now with some sagely formula for always having a positive pairing experience, but we are dealing with people and it's not that easy.
As a consolation prize I do have a recent experience to share which you may find useful, or at least familiar. As it turns out I spent about 11 months in 2013 on a team in the middle of a really interesting C++ project. Prior to joining that team I had not worked in C++ for well over a decade. As a result I went from SME to FNG overnight. This also meant that I had to learn how to be effective as the inexperienced half of a development pair, which I don't do nearly enough. (Note to self)
Trying to learn the domain, learn the language, and not impede delivery is tough. Being confused can be a little demoralizing at times. And constantly asking questions makes me feel way more vulnerable and annoying than I would prefer.
That's the job though, so my advice to myself was to suck it up, get coding, and try not to ask the same question more than once. That realization, as simple as it reads, seems to get lost most of the time. From what I can ascertain most new team members get paired up and actually have little or no idea what their responsibility is as the new pair partner. I suspect most just assume they are along for the ride and someone will tell them what they are supposed to do.
Of course, I have a differing opinion on this matter. Your job as a new team member and pair partner is to become a contributing member as quickly as possible, which can be as little as a few hours. Everything you do during your first days and weeks on a team should map back to that goal. This means questions, lots of them. It also means reading every applicable thing you can get your hands on, trying to pair with and get to know as many team members as you can, understanding team norms and cadences, and keeping your teammates aware of where you are strong and where you need help.
On the most successful teams I have seen new team members are pushing code in their first few days. When these same women and men are asked weeks later about their experience of joining a high performing development team they always say the same things - "On most new jobs you sit around and wait for a machine to be delivered and read documentation." , "Getting to contribute working code in my first week on the team was great."
So...the formula's easy right. The most obvious business value of a new developer on a team is in his or her code...so be coding. Coding will tell you what you don't know and what else you need to be doing.
No comments:
Post a Comment