Day: 1 Session Time/Number: 10:00am Session Space: A
What is it?
– ping-pong – one person writes tests, one person writes code
– chess clock – people take turns typing
A pair programming station might look like: 1 screen, 2 keyboards and mice.
– Driver: person typing
– Navigator: not typing
– Typing’s the easy part. I like to walk around and draw when I’m thinking about stuff.
– I write better code if I have to explain it to someone before typing it.
– It can be really exhausting sometimes, because you have to be “on” all day, you can’t think about something and research.
When do you use it?
– Focus is stronger. You are less likely to get distracted.
– Sometimes one is afraid to be wrong, or speak until they know the right answer – so pair programming can nudge people into moving forward.
– We have a daily standup where we pick our pairs for the day
“When I pair with people, I get away with fewer shortcuts. You are accountable in the moment.”
How to be amazing!
How to sell it to your boss / client
– Benefit: Better code w/ collaboration
– Benefit: Improves the culture by making it collaborative.
– It’s like a built-in code review
– Just start doing it – start demonstrating the benefits.
How to keep both people involved
– sometimes people go silent – and you don’t know what they’re thinking. You have to say “what are you thinking”?
– Sometimes the other person won’t give up the keyboard
– When you are evaluated as a team, there’s less threat and competition between people.
– Some people make better pairs than others.
– Ask leading questions
– Pair programming revolves around trust and mutual respect. It’s not for everyone.
How to use pair programming to train people
– it’s hard for the more advanced person to give up control to the less advanced person. Sometimes the less experienced person resists driving.
– It’s really useful to use pair programming to train someone on a new codebase, or when they are being on-boarded.
charging twice as much? How do you justify it to clients?
– it feels like a waste of resources sometimes.
– if you’re doing this for a time-senstive project
– sometimes people feel threatened
– We have a github account for that pair, and we commit together.
– We use gchat, ScreenHero
– Comment very little – the code should be easy to read. We comment when we’re trying a different approach, or experimental stuff.