Reply to post: Reality check someone please?

Pair programming – you'll never guess what happens next!

Mortimer

Reality check someone please?

Oh boy, where do I start ... I apologise in advance if this sounds like a rant (because it is ;-) ).

Coming from the other side of the table, operations, and having worked very closely with developers for some 20+ years, most comments posted here just confirms my long established view that (most) programmers are just average talents with very inflated egos.

As the recipient of, and responsible for, actually hosting and running all the crap that leaves the development department I can safely say that a vast majority of you (yes that includes you!) are just average programmers and produce somewhere between mediocre and fairly decent code. Seldom do I encounter truly brilliant code, and I say that despite having had the pleasure of working with some very gifted and talented people through the years.

To all the statements along the lines of "doesn't work for me" and "I do it better myself" (yes, especially that one) I say, total and utter BS!

Being in your own "little bubble" or "in the zone" is exactly when YOU make all the same mistakes that you accuse your potential co-programmer of doing and that you find so annoying. You are no better, period. That is what my experience, from the real world, tells me.

Heck, talent is normally distributed according to the classic bell curve and still, by the sound of the comments here, it sounds like you all belong to the upper 10% of the talent curve.

I believe that not for a second. To every commenter here that silently thinks "But I'm smarter than those around me and I wouldn't make those mistakes", I have news for you, you're not and yes you do!

I had the pleasure of working in a shop that used XP and DevOps long before the terms were even minted and popularised (as so many other things IT these are old concepts) and from real concrete examples I can say that pair programming does indeed work. It has the potential to produce great quality, scalability and robustness. Especially the last two properties are highly desirable when you actually go to production.

A vast majority of programmers are (almost) clueless as to how their code will behave in production and how it will integrate and cooperate with other parts when you assemble everything into a complete system. Having the combined knowledge and expertise of two people analysing the same problem is very valuable for producing a solution that actually works.

By my own estimate, maybe 10-20% of programmers "get it" and can see and think in terms of the whole picture and design and code accordingly. The rest of you just type away at your own little local problem and don't care about or ignore what the universe around you looks like and how it works, thus producing code that just barely fit together and requires duct tape to do so.

When it comes to building systems and not just snippets of code, most programmers are in reality quite bad at it.

Pair programming has the potential to catch and remove bad or outright incorrect logic, algorithms and behaviour early and save a ton of headache later on. People in general are lazy (at least I am) and programmers are no exception. You cut corners and skip steps that really would have helped the overall quality of your code. Having someone constantly scrutinising your work makes it harder to get away with that unnoticed.

Other obvious benefits have already been pointed out elegantly by previous posters.

Having said all that, I do of course recognise that it is not a silver bullet and you have to be conscious of when it is appropriate to use and how you pair people to make it work to your benefit. But many of the objections raised here I put down to people actually not having tried it and, perhaps, to some degree fear that your own comfortable and lazy way of doing things might actually reflect badly on you if someone was watching how effective you *really* are and what you are *actually* doing all day long (like checking FB and other non-related stuff). It is indeed comfy inside your own little bubble.

If it turns out that two people in a pair is just as efficient as you and your colleague are on your own, what does that say about your own programming skills?!

More people would be challenged, and become better (or even great) programmers by stepping outside that bubble and interact more.

Some of the best quality code I've seen was produced using XP and DevOps in concert.

To balance the sheet I have also seen some really horrible code make it into production, especially stuff coded by (young more often than not) programmers who thought they knew best, when in reality they didn't have a clue (and yes, that is just as likely to include you dear reader).

In short, more programmers would be better off taking a step back and taking a humble look at how good your skills and methods *really* are in comparison to others. Chances are you are just average Joe and not John Carmack.

Pair programming is one tool, among many, that can produce solid, measurable results when applied correctly. It is there, try it, use it, or reject it as you may, but don't dismiss it right away or for the wrong reasons.

POST COMMENT House rules

Not a member of The Register? Create a new account here.

  • Enter your comment

  • Add an icon

Anonymous cowards cannot choose their icon