The last summer I got a pretty awesome offer from a company in Sibiu and decided to give it a try, so after one and a half year at Wolters Kluwer (former FRS Global) in Cluj I have started working at Colt Technology Services in Sibiu, where I had the opportunity to learn new technologies and methodologies, one of them being pair programming. Although I am not fond of it, I have to admit that there are situations when it has its advantages…
Pair programming is a technique which consists of two programmers working together on the same task sharing a single workstation. One of the programmers is the driver, who is writing the code, while the other one – the navigator – instantly reviews every single line of code that is being written. Roles are switched often, ideally every half an hour. This all sounds good in theory, by doing pair programming, we may theoretically reduce the number of mistakes and increase the velocity of the team. But this doesn’t really happen every time we decide to pair up.
Because the navigator constantly reviews the lines of code being written, the driver should get immediate feedback in case he made a typo or a logical error. In case of typos… yes, the driver gets immediate notification and corrects the mistake he/she has just made, but not all logical errors are noticed by the navigator. The driver would observe his typos even without pairing, since the compiler/interpreter will notify him. Bigger mistakes, for instance logical errors might not be noticed by the navigator and be committed anyway. In my opinion if you want to reduce the bugs you might create while developing, use TDD or BDD. The constant notification of my pair that I’ve made a typo is annoying, since I am constantly interrupted, therefore I lose focus.
I have to admit that when we did pair programming, I have hardly opened Facebook or used any instant messengers, but I was daydreaming a lot… Unfortunately our tasks were pretty simple, there were no big design issues that we should have discussed. It was plain simple, so for the navigator it was boring as hell.
In the first few weeks it was fun, I liked that we communicated a lot, but after a while it got annoying. I started to miss that feeling when I was sitting on my own with the headphones on my ears listening to music with a cup of hot tea near me and just being focused, living in the code and breathing statements. While working in pairs, I could not focus as much as I wanted to, since I got constantly interrupted by my pair, he had an idea that he wanted to try, which often meant that I stopped what I was doing and let him give a try to what he wanted. The problem is that when I start coding, I usually have a clear picture how I want to implement it and when somebody is constantly interrupting me, it is just frustrating.
At Wolters Kluwer we had an awesome atmosphere and anybody could interrupt the other one if he/she needed help and most of the time we would have done half or an hour pairing to solve the problem. In these cases I didn’t mind if I had to stop what I was doing and do something else. Neither did my colleagues seem upset if I have asked them to help my figure something out. But this all came naturally, we were not forced to do pairing. I think all developers know when they need help, when do they feel that they cannot solve the problem and instead of wasting precious time they simply ask for help. I can understand that for some developers it’s not that easy to swallow his pride and ask for help, especially if the atmosphere is not that friendly. Coworkers may be too competitive and in those situations one may struggle and waste a lot of time finding a solution instead of just asking somebody for help.
I strongly believe that forcing pair programming at a company is a huge mistake. After two months of work I got so frustrated that I was ready to leave the company. Fortunately they have given up on pairing… Deciding that your employees should do pair programming is just a way too drastic decision. I think the company should have helped us more to create a friendly work environment rather than forcing pairing. A few team buildings would have been sufficient to bring the team members closer…