Maybe Two is Better Than One
August 15, 2014
Pair Programming. The idea is two developers work on the same machine. Both have keyboard and mouse. At any given time one is driver and the other navigator. The roles switch either every hour, or whenever really. The driver codes, the navigator is reading, checking, spell-checking and sanity testing the code, while thinking through problems and where to go next. If the driver hits a problem, there are two people to find a solution, and one of the two usually has a good idea. Other advantages include skill transferring, and ad-hoc training. Chances are the code is better than one developer working alone. In fact, it's almost a guarantee that when your code is reviewed by another human being - whether that person is sitting right next to you, or thousands of miles away - you will produce better code.
I'm still intrigued by the idea of pair programming, but I have to admit that when I first discovered that it was required at Dev Bootcamp, I was wary of the idea. In my experience, groups, however small, tend to be less productive. However, I have grown to enjoy working closely with other [soon-to-be] developers. Whenever I sit down to pair with a fellow Boot, I absorb a few of their tricks and techniques. It's a fast track learning experience for both participants. It also helps me to not get frustrated when the code doesn't work. As one Boot recently quipped after a particularly long and tedious session, "misery loves company." I've also found that I benefit more from a fluid driver/navigator set-up, especially while we are still remote. That said, I remain a little wary of spending a full eight hours working this way. I suspect pair programming might be fatiguing in larger doses, unless you're very fortunate in your choice of pairing partner.
And then there's the feedback. I have to say I enjoy giving feedback. It hasn't been hard to come up with feedback since everyone I've had contact with has been pretty awesome. The hardest thing is thinking of recommendations for improvement and phrasing those recommendations in a manner that I would want to read constructive feedback. On the other hand, I was nervous to read feedback given to me, while also hopeful that it would help me further my learning. And guess what? It wasn't too shabby! The overarching recommendation for improvement was that I tend to get lost in thought and not communicate what I'm thinking all the time. I expect that this probably makes it hard for my partner to follow along at times. Trust me, I am aware and working on it! Unfortunately, after years of being a lawyer, I've had it beaten into me to think and then speak.
Overall, I think that pair programming and feedback are helpful tools for learning at Dev Bootcamp, and I'm excited to try pair programming 'in real life.'