On the people front, we do our best to only hire experienced devs that will like the culture and fit in. We're a boutique shop, so we can be very picky about who we hire. Candidates have to pair with us onsite for at least a week before the team decides whether to hire. We've hired qualified interns, but don't hire apprentice or junior-level folks. Occasionally we do extended pairing matchups with client developers in our office, but they have to fit in culturally for it to work.
I think pairing all the time is one of our most important competitive advantages. My teams produce some of the highest-quality code I've ever seen in 15 years in the biz. We are able to effectively leverage XP-style client acceptance in our process because our code is so defect-free.
I'm proud of what we've created at Hashrocket, but usually try to stress the importance of context and talent in making it work. Pairing all the time is one of those things where I have to advise Agile idealists that it probably won't work for them. :(
Thank god somebody finally makes a rational case for XP practices.
So much of the XP adherents amounts to hand-waving and foot-stomping. It's good to see somebody say "this is making us more competitive"
I've yet to see a similar argument made about TDD. It may be that TDD makes more sense as an add-on to pair programming (with ping-ponging) than as a stand-alone practice.
How do those people get the time to do the week with you? Do you only hire folks who are currently unemployed? (Full time for a week means that they're not interviewing elsewhere.) Do folks use vacation (or unpaid) time to see if you'll take them on?
Yes, which also serves as near-concrete proof that a candidate _really_ wants to work with us.
In this environment, pair programmed got us both past the logjam we were both experiencing on this codebase and we were able to get things into the sort of shape that working alone became not only palatable but enjoyable again.
We also did some API work together, and I think if you're writing interfaces and the like, working on that with someone who will be using it can be helpful in getting a good initial API out there.
There are also other sorts of programming tasks where I don't feel pair programming was very productive (for me/us anyway).
And really, 90 percent of programming is more "typing" than programming because the work is straightforward.
90 percent of programming is more "typing" than programming because the work is straightforward.
This may be exaggerated, but it has more than a grain of truth. If you take it to mean 90% of programming as actually practiced, as opposed to 90% intrinsically, it's not even that much of an exaggeration.
Working on harder problems in higher-level languages than I used to, I felt less productive for a very long time. In some ways I still do. I eventually figured out that this was because I was spending much more time thinking and much less time typing. Typing feels like good-old-fashioned-work in a way that thinking doesn't. That's why people feel satisfied after cranking out thousands of lines of code, when in reality they may well have made an unmaintainable mess (and thus destroyed value rather than created it).
To this day, two years later, our search still sucks, but the basis of that user account management has meant that we haven't had to touch that code in almost two years.
For our most recent development cycle (which started about 10 months ago), we finally bit the bullet and split the product team into cross-functional sub-teams we call "pods" consisting of (roughly) 5 developers, 3 QA, and 1 product manager. Having the product manager sit literally next to the developers, instead of 15 or 20 feet away, has made a huge difference in the interaction there and our ability to quickly iterate on features. Instead of just making assumptions when the product requirements are unclear or don't seem to make sense, we have much more of an ongoing dialog all day about how things should work, meaning we waste a lot less time building the wrong thing.
It is so great when the other person is very good/smart at programming. You sense that your work is way more than the sum of the individual parts. It is like an explosion of creativity because you don't stop when you have a block and the other has not, or he has a block and you have not.
It is not great when the other person is not good/smart. You make all the work, the other can only spot the obvious, and makes the sum way less than individual parts. Feels like an endless drain that won't finish ever.
In world war they experimented with airplanes pilots: creating groups with the best ones, letting other groups with the not so good. It was fantastic for the elite groups, but bad for the mediocre ones.
They mixed groups with good and mediocre people and it made the mediocre turn good, but the good didn't became elite.
So I think this has pros and cons, and is not for everyone.
I agree with the statement about how programming is creative work, and I disagree with the 'only way to work' statement. Pair programming is a great tool, but it doesn't have to be always used. When you adopt a methodology or process like XP or Scrum, we don't always have to adopt it wholesale - just pick the pieces that work. Pair programming, in my experience is excellent at solving difficult issues under deadline and/or implementing brand new features. For everything else, it may be overkill. Plus, with pairing, it's hard to get your mental breaks in while you simmer a problem in your mind (e.g. check out News.YC).
It's kind of like the concept of scrum rooms. We had a critical iteration and flew everyone in for a conference room-based intense week-long session. We got a lot done - much more than we could have done over WebEx. However, at the end, I wanted to kill the guy with the noisy trackball. Close quarters can become trying over time (extended family meetings anyone?)
Hashrocket may be a notable exception to the norm of programmers working in isolation/cubes (especially
in larger companies)
Could've softened that up a bit, sure. I completely agree that not every problem is a nail for the hammer of pair programming. We've developed a very popular and productive pairing environment at Hashrocket.
We have found pairing to be helpful in solving difficult issues. And we have used it to enhance the design of software being written from scratch.
As for the mental breaks, some of us use the pomodoro to coordinate their break times. Others prefer to agree to breakpoints as they come.
We know pairing is not a fit for everyone, everywhere, all the time. However, if you are interested, this is how we do it, it works for us and, we hope our experience helps you.
If you don't care about how the code ends up in terms of structure other for the logical errors, you're doing it wrong (well, according to me anyway, so it's not that big of a deal :P)
Sometimes we'll be so engrossed in the engineering, that neither of us will remember that restaurants close at 9pm and we have to stop to eat.
What I'm saying is, lets say you want to find a way to update a web page with live data(http push?). Then you do a brainstorming session with others and get some ideas(comet, bosh, xmpp, etc). If you want to see which technology fits your product most, then it would be a good idea that each person is spending time on different ideas.
"brainstorming" is completely different from "coding together", specially coding a hack.