Skip to content

IvePairProgrammedFor30kHours

Jump to bottom
Ben Christel edited this page Nov 13, 2021 · 3 revisions

This page summarizes the following video by Joe Moore, titled "I've Pair Programmed for 30,000 Hours: Ask Me Anything!"

https://www.youtube.com/watch?v=RCDfBioUgts

  • 2:55: what is pair programming?
    • a software development discipline/technique by which two programmers work on the same problem at the same time using the same computer. Remote pairing is doing the same thing via remote collaboration tools like screen sharing and video chat.
  • 4:50: benefits of pair programming
    • continuous code review / no asynchronous code reviews needed
    • cross-training
    • building empathy
    • well-factored code / more maintainable code
    • fewer bugs / more accurate implementation of business requirements
    • lower lottery-count / BusNumber
    • fast onboarding
    • less rework / done might really mean done
    • more focus / fewer distractions
    • enables rotation among teams
    • old dogs learn new tricks
    • new dogs learn old tricks
    • everyone knows your strengths
  • 5:00: challenges of pair programming
    • exhausting
    • continuous social interaction / lack of personal time
    • sharing code / lack of ownership
    • social awkwardness
    • personality conflicts
    • domineering pairs / keyboard hogs
    • less alone time
    • intense
    • passive pairs
    • everyone knows your flaws
    • differing communication styles
    • body odor
    • I just don't wanna do it!
    • thinking out loud
    • pair crushes
    • shyness
    • arguments
    • tight working conditions
    • editor wars
    • distributed team
    • multiple timezones
  • 6:26: when do you go to the bathroom?
    • whenever you need to!
    • it is always okay to say "let's take a break"
    • some people set a timer to remind them to take regular breaks.
  • 8:25: how do you get started pairing for the very first time ever?
    • be open about the fact that you've never paired before
    • if you're pairing with a first-timer, adhere to "pairing etiquette": e.g. ask before grabbing the keyboard. Demo good practices.
    • consider using a structured pairing style like ping-pong pairing (test-driven development where one person writes the test and the other person makes it pass. Then you switch roles for the next test)
  • 12:40: when do you switch pairs? how do you deal with context-switching?
    • many teams have a soft "rule" that you should switch pairing partners every day. Pairing arrangements for the day happen at standup.
    • for some hard problems, that doesn't work well. You barely have time to load all the context into your brain before you have to switch to something else.
    • to compensate for this, we bend the rule: it's always okay to say at standup "I'd really like to stick on what I'm working on."
    • however, if a story starts taking way longer than it was predicted to, it's a good idea to switch pairs and get a fresh perspective on the problem.
  • 20:20: how do you convince management to let a team pair program regularly?
    • there are some short-term gains (see list of benefits above)
    • use your metrics! you should see faster cycle time (from the time work arrives in the team's inbox to when it's deployed, validated and done) as a result of having fewer bugs and less rework.
    • note that programming is a pretty small part of the overall development process. Spending 2x the money on programming may be worth it if it lets you spend less in other parts of the process (code review, QA, fixing production issues, onboarding new engineers, documentation, meetings).
    • say "trust us, this works. I promise you'll see these benefits."
  • 32:50: do you try to get to know your pair personally?
    • Being empathetic, open, and kind is vital. You don't have to become best friends with your pair though.
    • There's a balance. We all know people who overshare at work, or who seem overly distant. Aim for a happy medium.
    • Breaks are an opportunity to build camaraderie with your pair.
  • 36:25: is it pairing if you split up the work along architectural lines (e.g. backend/frontend)?
    • We [Pivotal] want people to be generalists and continually learning from each other.
    • if you split up, you're not really sharing knowledge
    • There may be cases where it's valuable to split up. But if you want to do it, question why. You can always make up reasons to not pair, when the real reason is "I just don't want to pair". Get a second opinion; if another pair thinks splitting up makes sense, go for it.
  • 41:00: how does distributed/remote pairing work?
    • Joe does it full time! It can work really well if you invest in getting video/audio/screen-sharing set up right.
    • Timezones are hard, though. There is no way to fix timezones.
  • 45:00: do you [Pivotal] test for empathy during your hiring process?
    • Yes! The onsite interview is basically "join this team for a day and pair program with them".
    • It's not just so we can get a sense of the candidate. They're also interviewing us. They may discover during the interview that pair programming really isn't for them.
    • Forcing people to pair is no good.
  • 49:20: how is performance assessed if programmers pair all the time?
    • We are assessed by our pairs.
    • Managers are always seeking timely, actionable, specific, kind (TASK) feedback for their reports, from people they have paired with.
    • If the manager is concerned about a specific area of someone's performance, they'll ask for feedback about that area specifically.
  • 52:46: how do you ramp new people up on the codebase and the specific techniques the team is using?
    • you might want to stick pairs for a while—basically give the person an onboarding buddy who can keep track of what they know and what they still need to learn.
    • the best way to ramp someone up on this kind of codebase is actually through pairing! If you just sent someone off on their own to learn all this stuff, they'd be in trouble.
    • maybe have a workshop/meeting/training to discuss the core practices/patterns in use.
  • 58:35: how do you motivate teams to pair when they currently don't?
    • sometimes it's just a matter of giving them explicit permission to pair.
  • 1:04:00: what do you think about pluses and deltas?
    • pluses and deltas are a feedback practice that some pairs do. At the end of the day they'll reserve a few minutes to chat about what went well (pluses) and what they'd want to do differently next time (deltas).
    • it depends on the culture of openness and whether people are willing to get the feedback.
    • it can help to establish it as "this is a thing we're going to try on this team" to make it less awkward.
Clone this wiki locally