This post is part of a series:
- Introduction
- The Good
- Individuality And Creativity
- Code Quality
- Odds & Ends
At this point in the series, I'm going to start to illuminate some of the issues I've had with pairing. This post deals with the loss of individuality and potential loss of creativity that can result from working with others.
Developers are steadfast creatures, at least in my experience. They spend a large amount of time getting intimately familiar with the tools and techniques they use on a daily basis. I mean - it's evident from even a light reading of Hacker News that developers are a passionate bunch to the point of religious warfare in defense of their choices. Pairing takes away a lot of that.
Just think about. When you get a brand new development machine, is there a specific set of apps you install and configure immediately? The ones you can't live without. I've seen enough scripts on GitHub to know many people have to gone through the effort of automating this setup - it's THAT important to them. We save our dotfiles and settings so we can quickly set up a new machine. We know how we work best individually.
When pairing, all that goes out the window. Now agreement has to be reached with every new tool, every new color scheme, every new setting you want to switch. With agreement comes sacrifice and with sacrifice you have MULTIPLE developers who now aren't using their optimal setup.
Let me use myself as an example (but make no mistake - just because I'm singling myself out here does not mean others don't have their own preferences). Over years of developing C#, I've become partial to vim, ReSharper (using the IDEA keyboard scheme), the Solarized color scheme and I like using one monitor rather than two. I prefer full screening apps to having multiple windows - it's easier for me to focus on one thing at a time. In fact, I may be in a very small minority who, given the choice, would take a laptop with a 15" screen over a beefy desktop machine with even a single, gigantic monitor.
In the past year, I've paired with people who have:
- Complained that vim is "just an IDE within an IDE" (when used in Visual Studio) and not useful,
- Had 4 windows open at once at all times, one in each of the four quadrants of the screen,
- Preferred light backgrounds with dark text to the opposite,
- Found ReSharper too bulky. They preferred to just download a bunch of smaller extensions to perform the few tasks ReSharper added that they found useful,
- Preferred ReSharper's Visual Studio keyboard scheme or even just Visual Studio's native key commands and features
And guess what? Not a single one of those opinions is unfounded or wrong. What is wrong is forcing every developer to work in a setup that is non-optimal for them. This can have an unintended consequence of making development less fun. I can speak for myself in saying that I don't code in my free time nearly as much as I used to. I've found myself struggling with what was previously my optimal setup because I don't use it every day anymore. And since my home is set with what used to be optimal for me, I got frustrated with it and just decided not to write code at home anymore.
But this uniformity doesn't just affect tooling decisions. It affects everything. Since another person is relying on you, there needs to be working agreements around things like when you start in the morning and finish in the evening. And this taps into an even bigger problem - the loss of creativity.
I think this article from Zac Holman sums up my thoughts perfectly. Particularly this line:
Code is a creative endeavor.
It shouldn't be expected that every person is creative within the same chunks of time or under the same constraints as others.
Along those same lines, this article from Lifehacker claims that creativity thrives in solitude. I don't necessarily know that I agree with that, but I do feel that every individual has a set of conditions under which they can be more or less creative or productive. For some, that may be working in a group and getting concensus. In others, it might be working alone with no distractions or pressure.
I've always preferred working with headphones on and music blaring. I'd always thought it was part of my personality. I'm a diehard music fan who thinks that music enhances everything. But now that I've been pairing for the past year, I see there was more to it. It was also a way for me to drown out distraction. It is my way to get "in the zone". I still listen to music when I pair but it doesn't fulfill the same goal. It's more just for the enjoyment because pairing in and of itself means I can't, or shouldn't, tune out others. And to that point. I've paired with developers who prefer dead silence so that they can think. So we're back to having to go to a concensus where one person, at least, will be in a less-than-ideal situation.
To conclude, the point I'm trying to make here is that most developers I've known are very particular about the way they work. Pairing seems to ignore that and in doing so, alienates BOTH sides of the pair by forcing concensus into a watered down working environment.
To be sure, I'm not saying code should be written in isolation. The dangers of that are well-documented in the old "hit by a bus" story. One developer in isolation can certainly make a mess of things. However, pairing is not the only way to make sure code has a second set of eyes on it. Code reviews are great in this regard. A developer can be creative in whatever way best suits him or her but they still need concensus of the group before code gets merged into the baseline.
I think I have one post left. It will be about the oft-touted benefits to code quality brought about by pair programming versus what I've witnessed.