There’s just something about working with others that makes the job so much more enjoyable. In many agile development frameworks, the idea of “Pairing” prevails as a key concept. When pairing occurs, two developers work together to progress a single user story, working together weave code into coherent, valuable functionality.<\/p>\n
There are many reasons why this makes the code better. Sure, all of a sudden you’re using two people to do the job that is more traditionally done by one, but cleaner code, a sense of mutually owned work, and nearly interruption-free coding (you can’t chat with your friend on IM all day if there’s a coworker looking at the screen as well) make it worth it.<\/p>\n
Yesterday it struck me, though, that there’s something else about pairing that makes it all the more powerful of a concept. Now, I’m not a developer, but us non-dev types like to pair on our work sometimes too. Yesterday I was working with a new ThoughtWorker (who’s in orientation as we speak) on a ThoughtWorks-led open-source side project that you’re all soon to hear about. As we argued over mundane details in the UI mockups we we had created, something struck me that hadn’t struck me in a while:<\/p>\n
This stuff is fun!<\/strong><\/p>\n Simply riffing with someone over why a particular UI element will or won’t work is amazingly interesting to me…who knows why. Either way, my point is that not only is Pairing all of the things I mentioned above, but with a good pair work is so much more interesting and enjoyable. And, as I’ve ranted about before<\/a>, all workers should be able to enjoy the work they are doing.<\/p>\n