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.