Week 2 Reading Response

I am happy to report that Week 2's reading load paled in comparison to Week 1's. For the most part, we were assigned two documents: Practical Styles of Pair Programming, by Iwein Fuld, and The Art of Agile Development: Collective Code Ownership, by James Shore.

For the most part, pair programming has been a foreign concept to me, but this past semester in my Compilers class we were instructed to group into two-person teams. So, this is how I was introduced to pair programming. Fuld identifies two roles in pair programming, which are the "driver," who is the one behind the keyboard, and the "navigator," who is the one following and guiding the driver's work. Though the article talked about many of the benefits of pair programming, it seemed that the only benefit that I received was that my partner was smarter than I, and he shouldered a majority of the load, acting as a "driver" with no navigator while I sat and watched. I refer to this as a "benefit," but it in reality, it was no such thing....it was, in fact, a crutch, minimizing my understanding and interest in projects and the class as a whole. Reading this article helped me to identify several of the mistakes that we made in our rather lackluster attempt at pair-programming. The following quote from the article seems to describe my situation perfectly, "The driver knows what he's doing and because the navigator doesn't pick up on what he's saying he turns silent and speeds up. The navigator sees that the driver is doing ok and decides not to slow him down but space out and look out the window a bit." It appears that we were committing several pair programming blunders. A) We were both low on sleep, B) we stopped thinking aloud, C) I didn't always stop the driver when something didn't makes sense, and lastly and most importantly, we never tried switching roles. All of this resulted in what Fuld has labeled "The Disconnected Pair or The Sleeping Navigator."

Now that I have touched upon a pair programming failure, I will briefly report a success. As I mentioned in my other Week 2 blog-post, Robert and I have been working on similar tasks this past week and decided to take this pair programming article to heart. We employed many of the concepts covered in this article, and it definitely resulted in a quicker process which created a higher quality product and allowed me to gain an abundance of knowledge. We successfully fulfilled our roles as driver and navigator.

The article on Collective Code Ownership was also very enlightening, but in a different sort of way. Seeing as I have had absolutely zero past situations in which collective ownership could be employed, this article served more as warning and guidance. I found a great deal of healthy responsibility being placed upon my shoulders. The article explained that it is my duty to always leave code better than I found it. Though not directly stated, I felt that the number one point of the article was that laziness is NOT an option. When coding, I cannot do a half-hearted job, assuming that somebody else will fix my mistakes, as collective code ownership doesn't mean "no-code ownership." In summary, A) I should always be looking to improve other's code, and B) I should take pride in the work that I do, but not be so proud that I try to be the sole owner of that code and get offended when someone else modifies it.