Agile Zone is brought to you in partnership with:

I have been working for almost two years now on infrastructure and deployment automation, exploring programmatic solutions to traditional systems administration problems and configuration management. I'm fanatical about testing, the scientific method and building good tools to support awesome   Oliver is a DZone MVB and is not an employee of DZone and has posted 29 posts at DZone. You can read more from them at their website. View Full User Profile

On Pair Programming

06.22.2013
| 11235 views |
  • submit to reddit

It has been a while since my last blog post; certainly not because I wanted to write less but I’ve just been trying to learn so damn much recently it hasn’t left much time for anything else. Whether or not I’ve actually learned anything is yet to be seen. This leads me to a subject which I am still struggling with – Pair Programming.

Not that I don’t “get it”, “understand it”, or “enjoy it” – I hope that I have attained all three of these – but due to my situation with software development it can be a bit of a struggle. What is this situation? Well, let me briefly explain.

My background, ultimately, is in Computer Science. I have a Bachelor’s Degree in it, and did study several years of programming in various languages and contexts. However my career up until the last couple of years has been decidedly in the Systems Administration realm. I enjoyed this immensely, and while my programming skills grew rusty I eventually grew to envy some of my colleagues whose abilities far exceeded my own in tailoring their own solutions to problems while I had to reuse whatever OSS fit the bill.

While at Nokia I was fortunate to get a lot of time to myself to implement some next generation configuration management solutions, and found myself hacking away at Ruby for quite some time. Enough, I guess, at least to make it possible to start my current job at SoundCloud as a Software Developer again. The environment is extremely challenging in that we have a lot of very interesting problems to solve, and many very talented developers working around you on these problems.

My team in particular seems to have tasks which span a number of systems, and we are aiming very much to approach our work end-to-end rather than just focussing on the back-end or front-end systems. The current situation is that I am most comfortable in Ruby (but don’t particularly like it anymore), working up my experience in Go, learning Javascript and ActionScript, and reacquainting myself with C and Python (ok, these last two aren’t used a lot). The codebases we work on are frequently not “owned” by us (which fortunately doesn’t really matter), and we often have to switch between several different systems and languages to solve the one end-to-end problem.

That was a rather long introduction. What’s the point? I find when I attack a problem, aside from the initial paralysis of indecision due to not knowing how to get started, I also can spend a good hour or two just acquainting myself with the codebase and finding my way around it. Where the hell do I make the change I want to make? How do I do it? How can I most quickly learn the conventions of this codebase? All of these questions have answers, but if I were to pair on the task from the beginning, it would also involve someone looking over my shoulder (or I over theirs) for a couple of hours while my brain just starts to fire. It doesn’t feel very productive for one, let alone two people.

The end result unfortunately is that after I’ve acquainted myself with the codebase, I probably won’t end up pairing with someone else to complete the work. I’ve figured out the problem, prototyped it until it worked, and then tidied up enough to call the problem “solved”. Maybe I’ve even added tests! Where in this process was I supposed to have started pairing? I genuinely do enjoy it, but when I’m faced with the prospect of wasting another co-worker’s time and exposing my ineptitude it doesn’t feel as enticing. I’m anything but a coding Ninja or Rockstar, and often it feels like that’s all I’m surrounded by.

If you are in a similar position, how do you deal with this? If you have any suggestions or comments on the subject I would love to read it and discuss further.

Published at DZone with permission of Oliver Hookins, author and DZone MVB. (source)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)

Comments

Peter Luong replied on Mon, 2013/06/17 - 8:10pm

I guess it depends on the knowledge of the pair. I find that if both of us are about to work together on a piece of code that we are both unfamiliar with, then it is worthwhile to separate. We can then investigate the code and reconvene once we are both familiar with the domain. That way we are both on the same level and continue to discuss the possible solutions to the problem. The other scenario is that if you have one individual who may be more knowledgeable then the other, then the advantage of pair programming is knowledge sharing. This may be beneficial as it may save the one or two hours you would have spent investigating the code. If you are working on the tests you may have thought you have captured all the scenarios and have marked the problem is "solved" but your pair may also think of edge case scenarios that you may have not thought of.

Chris Loggins replied on Thu, 2013/06/27 - 8:34am

It's not about wasting another developer's time and exposing one's ineptitude. It's about putting two sets of eyes on a problem. It's about helping each other learn that much faster, by filling helping to fill in the missing pieces.

I'd say it's more wasteful to spend 2 hours learning something a coworker can demonstrate in 10 minutes. The end result is the same: you still know the answer. One way wasted 110 minutes.

Sure, you might have to admit you're not the rock star. Another developer might have to teach you something. This isn't a bad thing. The end result is a better product, and two better developers. That's a win for the company no matter how you look at it.

To answer your question, I get over it. It's better in the long run to pair up.

Robert Carter replied on Thu, 2013/06/27 - 8:48am

I concur completely with the first commenter that it would be helpful and wise to separate and both become familar with the "domain".  The ability to become familar with a domain, and to hammer out a solution in your head is every bit as critical as coding the solution. If a developer does not take this "quality" time (or in this case both developers) to make sure due diligence is completed, the actual task of coding will take much longer, and may even result in a failed solution since the proper case was not taken to develop a strategy, check out alternatives, look for similar solutions in the codebase, talk to others, etc etc.  IF one person is already familar with the problem, and the other is not, I would put forward that the person who is not loses out on an opportunity to learn the domain in question, and does not "learn" from the opportunity to complete all this up front problem-solving... which is a critical part of what we do... coding is important, but in reality it is not the majority of what most programmers do.. We are problem solvers..

As far as pair programming itself, there are many diverse opinions on it. Having been in the field for 15 years, I find it extremely cumbersome, and not a productive use of resources.... Yes, there is some knowledge transfer, but overall I feel like each developer would be much more productive on their own, with code reviews or some other mechanism to handle the transfer of knowledge. In a nutshell, I do not like pair programming for the most part, and think it is counter-productive overall, and only productive in certain environments -- But that is just my opinion.

Abel Gaxiola replied on Thu, 2013/06/27 - 10:22am

Viewing and discussing the code with another programmer usually saves me time and gives both of us a better understanding of the code base.  I don’t pair with all coworkers because some of them don’t like to pair program; and I’m fine with it.  Pair programming should not be forced upon us.  I was against pair programming at first but now that I have tried it I enjoy it and find myself encouraging people to give it a try.

Oliver Hookins replied on Sun, 2013/06/30 - 9:10am

All very good comments, thank you!

Specifically with respect to the suggestion of getting up to speed with the technology or codebase separately, then coming together to pair - the problem I find with this approach is that there is such a strong temptation (perhaps even a necessity) to attempt to attack the problem at hand in order to learn the technology or codebase. Why spend a bunch of time solving example problems from the web when you could be attempting to solve the actual problem? It seems like more time would be wasted approaching it this way.

Of course, if you are a complete novice at something the only way forward may indeed be to do simple example problems. For example, if the codebase is completely unintelligible to you at this point. Perhaps I am dealing with a problem that largely exists at the novice end of the scale of programming ability, but it's also slightly sad that this excludes very novice programmers from enjoying and experiencing the benefits of Pair Programming in some ways.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.