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
The How
For Ramping Up New Team Members (effective)
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.
For Upskilling Juniors (pretty common)
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.
For Firefighting (it’s a must)
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
To unblock yourself or your colleagues (do it)
It is what pair programming is for. Do it often. Do it whenever you need help. Do it regardless.
Troubleshoot Defects (can be helpful)
Sometimes, an extra pair of eyes help you find more clues about what you’re looking for.
Avoid Bugs (okay but costly)
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.
🔴 Red Flags
- Paring can be exhausting.
- Pairing doesn’t work for everyone
- 100% pair programming can harm productivity and responsibility. Don’t do that.
📜 Tips
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.
https://jamiewen00.gitbook.io/tech-lead-handbook/tech-leadership/pair-programming
