On Pair Programming
On Pair Programming
Join the DZone community and get the full member experience.Join For Free
Discover how TDM Is Essential To Achieving Quality At Speed For Agile, DevOps, And Continuous Delivery. Brought to you in partnership with CA Technologies.
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.
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 , DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.