Pair programming: just do it!
As I wrote yesterday in my first post on pair programming, we had a great discussion in our team about pros and cons of pair programming, how to do it and when not to do it, what is holding us back and what we can do about it. Everyone seemed to recognize the value of pairing in terms of increased code quality, readability and maintainability, fewer defects, knowledge transfer, immediate code reviews, faster problem solving, better designs, improved focus, communication, learning, trust and overall morale (!) within the team. But we also identified some reservations: Will it slow us down? How about cost efficiency? What if I just want to work on my own, control my work and schedule independent of others?
Being pragmatic, as we are, we just decided to go for it and give it a try. We gave a special tag and color to all tasks on our sprint backlog that we deemed suitable for pair programming, and today after the stand-up we divided into two pairs. B. and I picked up a task of building a new part of our application's object explorer relating to our new real-time modeling workflow. At first I had difficulty catching up with B.'s speed of thinking. He is a very bright guy and thinks several steps ahead :) So I was asking many questions, and learned a lot! In the meantime, we shared shortcuts, tools and approaches we use, discussed naming, designs and implementation alternatives, as we switched behind the keyboard.
Some time into our pair programming session, I suddenly heard a low buzz of M. and A. working together on a defect behind a standing desk. We paired for about 3 hours in total, time flew and it was time to go home. Tomorrow we'll write some more unit tests and submit the code for review to our fellow team members.
Overall, I am very positive about how things went today. Before starting pairing, I spent a couple of early morning hours investigating how to calculate a certain geometrical shape. Typically, this kind of tasks are not done in pairs, because they do not result in any production code, but are rather spikes to try out a few approaches. After the 3 hours of pair programming that followed, I feel energized and inspired, I learned a lot in all kinds of ways. There are definitely things to improve, like more regular switching, and not trying to be driver and navigator at the same time. I am looking forward to discuss tomorrow morning how the team felt about this new undertaking of ours!