# Paired Programming *Based on a talk in Tech Time on 1st August - thanks to all contributors and attendees!* ## What is paired programming? Pair programming essentially means that two people write code together on one machine. ## The benefits There are plenty of benefits: - **Knowledge sharing**: helps the team spread knowledge on technology and domain on a daily basis and prevents silos of knowledge. - Better **problem solving**: When two minds understand and discuss a problem, we improve the chances of finding a good solution. Different experiences and perspectives will lead to the consideration of more alternatives. - **Reflection**: forces us to discuss approaches and solutions: speaking out loud ensure right understanding, and gain that instant feedback on them - Keeping **focus**: less distractions and less rabbit holes - **Code review** on the go: more errors get caught on the way. Easier to refactor as can discuss approaches - **Two modes of thinking** combined: tactical and strategic view - **Collective Code ownership**: makes anyone on the team feel more comfortable changing the code (esp if junior or new joiner). More consistent as well - **Work in progress limit low** so can focus on the important tasks - **Fast onboarding** ![benefits of paired programming](https://martinfowler.com/articles/on-pair-programming/benefits_overview.jpg) Read in detail the benefits [here](https://martinfowler.com/articles/on-pair-programming.html#Benefits) --- ## Classic set up - One person who is the **Driver** (person at the keyboard). Focussed on completing the tiny goal and talk through what she is doing while doing it. - More tactical thinking about the details - Other person is the **Navigator** in the observer position. Review code on-the-go, give directions and share thoughts. - Thinking more stategically with the big picture in mind ### Approach 1. Start with understanding the reasonably well-defined task 3. Agree on one tiny goal at a time. 4. Switch keyboard/screens and roles regularly. ## Ping pong technique Alternative to the classic setup, this technique is good for clearly defined tasks that can be implemented using TDD (Test Driven Development) - **Ping**: Dev A writes a failing test - **Pong**: Dev B writes the implementation to make it pass - Dev B starts the next Ping - Each Pong can also be followed by refactoring code together before continuing --- ## General paired programming tips - Ask for any preferences on pairing - E.g. whether they prefer ping pong, how often they'd like to have breaks. Regularly ask to check if preferences have changed. - When starting to pair: review the story - Can help to create clearly broken down tasks, and collaborate on the order - Discuss and agree an approach if there are multiple ways to approach the story - Plan the day - Start with a calendar check, communicate availability and pairing times with each other before hand - Agree to divide and conquer when needed if research crops up - Things to avoid: - Distractions: keep your eyes on the prize. Try and avoid reading emails/checking phone whilst pairing - Micro managing: leave room for the other person to think - Being impatient - use the '5 seconds rule' - When the navigator sees the driver do something "wrong" and wants to comment, wait at least 5 seconds before you say something - the driver might already have it in mind, then you are needlessly interrupting their flow. - Swap between driving and navigating regularly - Take regular breaks! Combat zoom fatigue! - [Pomodoro](https://www.toptal.com/project-managers/tomato-timer) is a good technique to remind you to take a break. - If you've been going a while - ask your partner if we can go on a break - it'll be beneficial for both! - If you get stuck: - Walk away - take a break and return with fresh eyes - Treat partner as [rubber duck](https://en.wikipedia.org/wiki/Rubber_duck_debugging) - Just explaining the problem out loud can help with finding the solution. - Agree how long to keep going before seeking out others - Some tools can help with pairing (e.g. Zoom annotate, code sharing tools) - Timebox explorations - if you find something interesting to look into, timebox and if it turns into a [rabbit hole](https://medium.com/@create_self/brb-im-going-down-a-rabbit-hole-how-i-learned-how-to-read-code-documentation-a664c94e91d7) then think about putting it in the backlog and circling back if you have the time. - Get feedback post pairing on how it went - a 'de-brief' - Challenge and be open to be challenged ## Pairing with someone who might be more disengaged - Try to enforce regular pair swapping - Before starting a ticket, work out all the different tasks to do and ask which they’re most interested in driving - When planning the day: can suggest at what points can aim to swap - If you've been driving for a while, suggest swapping at the next logical point (after the next break/lunch/meeting etc) - Also can try a different technique: follow ping pong mode of pairing, where coder is switched more often - Speak out loud a lot to keep them on board - perhaps they just got lost along the way - Try and engage them - Ask them questions (even if you know the answer) or ask for suggestions even if it might seem straightforward — spark discussions - - Get pair to play the problem back, to ensure we're on the same page - If they're really unresponsive - ask for a break, perhaps they're really burnt out - Engage with them after coming back and starting - Get Feedback on how sessions have gone/their pairing preferences ## Pairing with someone who might be more junior - Be selective of which stories to pick up together - Align on what pairing is - get people on the same page about the benefits of pairing and why - Help them see a bigger picture or value of why we are doing the task in hand - sharing of context while pairing - Get them comfortable - Build a safe space where they feel its okay to make mistakes and learn things anew. There are no stupid questions - in fact questions are encouraged. - Emphasis they're not holding anyone back: in teams interest to get them up to speed - Proactively checking if they have any questions or doubts - Sometimes splitting and letting them explore on their own (setting clear goals first and when to regroup) - going slower and taking time to explain things - Remember the 5 second rule - Not assuming anything about knoweldge levels, avoiding sounding patronizing - Try and get them to drive more - Best way to learn - Go more into the mentoring mode - let them drive more to build confidence if they are willing - First demonstrating how to drive the task and asking them to review the code and encourage giving feedback and then helping them getting comfortable driving the task - Celebrate accomplishment of tasks, however small - Can help energize and build confidence ### There is not "THE" right way - It depends on your styles, personalities, experience, the situation, the task and many other factors. - In the end, the most important question is: Do you get the promised benefits out of it? If this is not the case, try out something else, reflect, get feedback and adjust. --- ## Recommended reading - [Martin Fowler Blog post on Paired Programming](https://martinfowler.com/articles/on-pair-programming.html) - [Thoughtworks slides on paired programming](https://docs.google.com/presentation/d/14mN8c8v9c-Tl75XWs6uUusEAWnIltKxJOgICjwWyiYU/edit#slide=id.g35e10f078d_0_19) - [Thoughtworks sensible defaults section](https://central.thoughtworks.net/home/sensible-default-practices/software-dev-sdp#pd)