Here at thoughtbot a big part of our culture is pair programming pretty much on a daily basis. There are many reasons to work in a pairing session, including:
- to solve bugs,
- to act upon incidents,
- to help a teammate who is stuck on something,
- or vice versa, to get help,
- or to work on features.
The first ones on the list seem to be the most common scenarios when folks think about pairing, but I really enjoy developing something new in a pair programming session.
Why I Like Pairing
I like pairing when:
- I don’t know the answer to something
- either because it is broken,
- or not working as intended,
- or because the feature has to be designed and the code has yet to be written.
We have some nice guidelines with a few suggestions on how to get the most out of a pairing session, but I also realize it takes time and exercise to accomplish a fulfilling and productive meeting.
Starting with a plan, both practical (length of the session, who drives, etc.) and what we aim to accomplish by the end is crucial.
If I already know how to do something I technically don’t need to pair, except, I can still write better code, or refactor it, or have a stronger Pull Request as a result.
And if I already know how to do something, I can still take the opportunity to pair with another developer who maybe has less experience. They can be exposed to something new, like a language they don’t use daily or a different part of the application we’re working on. Besides, it is also a great exercise in refining my mentoring skills. (And this does NOT mean lecturing!)
I like, and I want to be on both sides.
My Ideal Pairing Session
In my ideal pairing session there should be many questions and fewer statements. We are figuring things out.
In my ideal pairing session we don’t take anything for granted about anyone’s knowledge, or about aspects of the code: sometimes the solution was in something we thought about but didn’t consider out loud.
In my ideal pairing session we explain things to each other, because we want to share our thought process, and because it helps clarify and solidify why we chose to do things in a certain way. And we can ask the other about something they’re doing and we are not familiar with.
In my ideal pairing session we take nice breaks. In high school I used to study together with classmates, mostly in pairs, doing our homework, taking little snack breaks with a slice at the local pizza shop. That was pairing before programming.
Earlier I mentioned how it may take some time to get comfortable with pair programming. It may turn out we encountered and developed similar skills already, but we may need to make a connection to a previous experience or memory.
One last thing: let’s not forget the Co-authored-by line at the end of our commit message
to let the contribution shine for both!
Like so:
Co-authored-by: NAME <NAME@EXAMPLE.COM>
