Pair Programming
Why pair programming? What should we use it for, and when should we not?
Last updated
Why pair programming? What should we use it for, and when should we not?
Last updated
What is pairing programming really for?
Pair programming to exchange knowledge among people
The main goal of pair programming is knowledge sharing - an activity through which knowledge is exchanged among people.
Pair programming to the rescue
Check out Eric Elliott's post about pair programming here
It is not uncommon to pair an existing team member with a brand new team member. Information like domain knowledge, internal tooling, and existing ways of working can be passed along to the new team member.
Kind of like knowledge sharing, but focusing on upskilling juniors. I'd say pairing isn't the most productive way to upskill juniors. There are other alternatives like code review, training, knowledge sharing sessions, etc.
The production environment is on fire and needs to be fixed as soon as possible. How you apply the hotfixes is an anti-pattern and in a rush. e.g.,
ClickOps
Deploy the latest working image on your dev machine
Run SQL scripts to fix broken tables
Run shell scripts to fix a broken node
It is what pair programming is for. Do it often. Do it whenever you need help. Do it regardless.
Sometimes, an extra pair of eyes help you find more clues about what you're looking for.
It shouldnβt be the goal, instead, it is the happy outcome we got by accident. Bugs should be captured via code review, unit test, integration test, end-to-end test, and monitoring and alerting system.
Paring can be exhausting.
Pairing doesn't work for everyone
100% pair programming can harm productivity and responsibility. Don't do that.
Shared responsibility is no oneβs responsibility
Pair programming is excellent and we should definitely use it when appropriate, but don't go too far on that track as its drawbacks are clear.