2024 Public Training Schedule
November 18 – 21, 2024 – Agile Analysis and Design Patterns
Half-Day Sessions
December 9 – 12, 2024 – Agile Analysis and Design Patterns
Half-Day Sessions
Follow me on Twitter:
Blog Post Categories
- Announcements {19}
- Articles {2}
- Bits and Pieces {74}
- Blogosphere {1}
- Bonuses {2}
- Build in Small Batches {27}
- Collaborate {38}
- Create CLEAN Code {34}
- Implement the Design Last {11}
- Integrate Continuously {30}
- Off-Topic but Interesting {3}
- Rants {82}
- Refactor Legacy Code {24}
- Say What, Why, and for Whom Before How {22}
- Seven Strategies {38}
- Specify Behaviors with Tests {17}
- Write the Test First {27}
Archives
Privacy Policy
(c) 2024 To Be Agile
- July 17, 2019
- Collaborate
While I am a big believer in pair programming I don’t believe that we should do it all the time.
Pairing is exhausting!
After a pair programming session, I am usually wiped out because I am working hard the whole time. I have someone looking over my shoulder analyzing everything that I do. That’s great for learning new habits because if I slip up there someone there to remind me to do the right thing but it takes a lot of energy to be in that mode with someone.
When we work alone we can let our mind wander at times. We can check Twitter and the local news or whatever. But when we’re working with a pair partner we are focused and we stay focused the whole time we are working together. We’re also less likely to be interrupted by someone else when they see that we’re engaged in a conversation. The end result is that we spend much more focused attention on our work and we get a lot more done which, by the way, is why managers should support their developers in doing pair programming as much as they want.
It’s good to start slow and pair for maybe an hour or two at a time. I find that pairing for more than about four hours a day can be just too much when you’re first starting out. Don’t expect to put in a full day of pairing on an ongoing basis because I think that’s unrealistic, even for experienced developers. If you can do one to four hours of pairing in a day then I think that’s pretty good.
You’d be surprised at how much work you can get done in sessions like these. I always find that I get a lot of work done when I pair with another developer. I also learned an enormous amount about how they approach problems and build software.
I’ve worked with literally thousands of software developers as a consultant and as a trainer. I find that there are many valid ways of approaching software development but there are some eternal principles and practices that make the software we write more resilient to change in the future.
Not only do I find that I learned an enormous amount when I pair program from my pair partner but I also learned a tremendous amount from the process of putting my thoughts into words so that I can describe what I’m thinking to them. In the process of putting my thoughts into words, I tend to think through my ideas that come up and I find better solutions.
I can’t help but laugh to myself when managers tell me that pair programming is inefficient. It just tells me that they don’t understand where the real bottlenecks of software development are.
It turns out that two people working together can often produce higher quality code with fewer defects and these things significantly improve overall productivity. Coupled with the enormous benefit of propagating best practices throughout the team and giving team members the opportunity to discover best practices together, pair programming can be a hugely valuable practice for improving overall team productivity and consistency of results.
Note: This blog post is based on a section in my book, Beyond Legacy Code: Nine Practices to Extend the Life (and Value) of Your Software called Seven Strategies for Seven Strategies for Agile Infrastructure.
Previous Post: « Swap Roles Frequently
Next Post: Try All Configurations »