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

71 lines
3.9 KiB
Markdown
Raw Permalink Normal View History

2017-10-21 06:16:54 +00:00
> 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][cat-programming] 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,<sup>[[1]][pairprog-hannay-ist09]</sup> and that most people enjoy
it.<sup>[[2]][XPSardinia]</sup> 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][flow].
* Tools and technology are diluted to the lowest common denominator:
* I have invested countless hours learning, [configuring][dotfiles], and
mastering powerful tools like [Neovim], [zsh], and [my operating
system][arch-linux], which I'd like to be able to use.
* 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][15-minute-rule]. 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][aemeredith-pair-effectively] 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.
[cat-programming]: https://medium.com/@patrickabrown/the-only-person-ill-pair-program-with-is-my-cat-86da6fb4da3d
[pairprog-hannay-ist09]: http://www.idi.ntnu.no/grupper/su/publ/ebse/R11-pairprog-hannay-ist09.pdf
[XPSardinia]: https://collaboration.csc.ncsu.edu/laurie/Papers/XPSardinia.PDF
[aemeredith-pair-effectively]: https://speakerdeck.com/aemeredith/two-heads-are-better-than-one
[flow]: https://en.wikipedia.org/wiki/Flow_(psychology)
[Neovim]: https://neovim.io/
[zsh]: http://www.zsh.org/
[arch-linux]: https://www.archlinux.org/
[dotfiles]: https://github.com/wezm/dotfiles
[15-minute-rule]: https://blog.intercom.com/15-minute-rule/