wezm.net/content/technical/2017/10/pair-programming.md

3.9 KiB
Raw Blame History

Pair Programming

All code to be sent into production is created by two people working together at a single computer.

http://www.extremeprogramming.org/rules/pair.html

Recently I read The Only Person Ill Pair Program with is my Cat by Patrick A. Brown and it stirred up some thoughts that got too long for a tweeted response. So I'm capturing my own feelings on the practice here.

I don't enjoy the practice of pair programming as it is defined above. It's taken me a long time to be able to admit that because there is evidence that pair programming is faster and produces higher quality results,[1] and that most people enjoy it.[2] Going against this evidence makes me feel like I'm a bad programmer, or that I'm not doing my job well.

For me (full-time) pairing takes the fun out of my job. It may be argued that I'm not employed to have fun but you can be damn sure that if spending half my waking hours a day in your employ I'm going to want it to be enjoyable. I'm not some resource that solely exists to extract maximum efficiency out of in order to further other people's goals. I'm a person with my own goals that is expending a great deal of my life in other people's employ so that I may live, and have a fun and fulfilling life.

When pairing full time, or most of the time:

  • I get tired and drained:
    • As a bit of an introvert, I find extended periods of pairing extremely draining. I don't think introversion is really factored in when the XP crew advocate for full-time pair programming.
  • I lose any chance of achieving a flow state.
  • Tools and technology are diluted to the lowest common denominator:
  • I miss the satisfaction of working on and solving a problem myself.
  • I am generally less satisfied and enthusiastic about work.

To be clear I'm not advocating for never working with a fellow developer or a complete lack of collaboration within your team. I'm stating that I don't like the practice of requiring or pressuring people to work as a pair for all or the bulk of their time. Also, pairing is the practice when two people of similar skill level work together. If there is a disparity in skill level then it's mentoring, which is a totally different thing.

To me, "working together at a single computer", is a tool in your tool belt like any other that you use when it makes sense. Trying to solve a particularly complex problem? Work with someone on it. Been stuck for a little while, enlist some help. When the time is right for collaborating on a problem it is a skill like any other that can be improved and honed. Ellie Meredith gave a great talk at the Melbourne Ruby meetup in August on some tips that contribute to effective pairing. These tips can help improve your effectiveness, and enjoyment when it's the right tool for the job.

If you love pairing full time, great, but keep in mind that not everyone feels the same way. If you don't really enjoy paring full-time, rest assured you're not alone. Look after yourself, hone your skills and pair when it makes sense.