Pair Programming

This technique has been in my repertoire since the beginning of my career as a software developer and is the cornerstone of many of my projects. Therefore I am well versed in what it involves, benefits, challenges and so on.

I agree on what the authors are saying in this article mostly and I am kinda glad that I read it because I noticed some stuff that they say it is wrong and that I do a lot of the time when I am giving classes or I am working on a collective project.

Like for example the micro managing part.

In my entire carrier I never understood what that term meant and it describes almost perfectly what I have been doing most of the time in my projects. Most of the time I assume the role of navigator while pair programming either in a project or during a class, I would think it is because I consider myself a very good programmer, and because my mind most of the time already knows or imagines what must be done in order to solve the problem I always tell the driver exactly what to do. And sometimes the driver is just so, sooooo slow. And rather frequently I just tell them to change places with me and let my code.

Because of my impatience I can see now that I have been doing this stuff wrong. I mean sure, I have been a rather good navigator a lot of the time, but also I have been a prick most of the time. And I am sure that I have made some people very, very angry.

Thanks to this article I will improve my soft skills, because being a good programmer isn’t enough in the modern world to be successful. You must also be a good team player.