Today, The Curbside Prophet will be having another first! Because this one is mandatory and graded.
Well, yeah this entry is something a Sir JJ would want from his students. Because like me, he doesn’t like mainstream. Instead of submitting a boring essay he opted for more personal and opinionated blog post. I would not want to post the guide questions here as they would just box my thoughts in one corner. But I gotta do what I gotta do — to think outside the box. But for the curious ones, here it is. Well yeah, it from a Dropbox site, because to Sir JJ, a Facebook group is too mainstream as well. Just scroll to the bottom of the page.
Just recently, Sir JJ unleashed yet another of his antiques paring us off randomly. Well, the random part was greatly influenced by me. But his point of paring as off is to test the effectiveness of a new programming paradigm — PAIR PROGRAMMING.
To start off, pair programming is a style in programming wherein two programmers work side-by-side at one computer. One of which is the driver, that someone types at the computer or write down a design. The other is the navigator, someone who observes the driver looking for tactical and strategic defects in the driver’s current work.
Apparently, two heads are better than one. And this is the cliche I was hinting at the title of this post. But what exactly makes pair programming better compared to the traditional solo programming? Well, Larry Constantine, author of more than 150 technical articles and 16 books, commented that the code benefited thinking of two bright minds and the steady dialog between two trusted programmers. He concluded that two programmers in tandem was not redundancy, but rather it was a direct route to greater efficiency and better quality. Also, the presence of a pair makes the other get a little nudge at doing better to cope with each other’s level of understanding. Additionally, particularly in the field of education, the students tend to worry about jeopardizing their partner’s grade making them strive a little harder.
Pair programming is not just unicorns and rainbows because it has its downside as well. Generally speaking, it is conflict in knowledge and attitude. Good pairing chemistry is important because the eventual success of the project relies on how the pair performs. Aside from that, bias/habit can also challenge the effectiveness of pair programming, where the programmer has been conditioned to work alone and not willing to cooperate with others. Economics is a matter to consider since allowing two programmers to work on the same thing is rather costly. Coordination of schedules between pairs makes pair programming a tad bit of a challenge. And lastly, distance, where pairs cannot make it possible to be physically co-located.
In my case, I was set-up to work alone. And statistics say, I belong to approximately 5% of students who ALWAYS desire to work alone. However, I was rather surprised to have enjoyed pair programming and the output was of better quality relative to if I was to work alone. At first, it was a little awkward with my pair, although we are good friends, because I have never had peer programming with her, and I don’t know her standards, and we have quite different approaches in programming. But clearly, the cliche is true. No need to argue.
Pair programming is something that I would recommend to fellow programmers. Even if it pushes you out of your comfort zones of working alone (I’m actually talking to the rest of the 5% who prefers working alone), you get more than what you expect. I don’t see pair programming as being redundant with two people working in the same thing with the same output, but rather two people working together complementing each other’s skills and producing a more quality output.
I’m just a curbside prophet, with my hands on my keyboard trying to activate my rocket to come.