A few thoughts on Pair Programming
At this point in the game I am an aspiring programmer about to jump head first into my first coding bootcamp in Front-End Engineering in a couple days. This is the second and final blog post about set B on my pre-course work. The pre-course work is also the extent of my coding experience to date. I am full of excitement to get underway and begin what I hope to be not just an amazing lifelong career, but a passion of mine to continually learn and develop my skills and knowledge in programming.
An interesting topic on Set B focused on various aspects of Pair Programming. Since I am new to development, I also looked into a few other resources outside the prescribed pre-course work gist-list.
Wikipedia defines Pair programming as: an agile software development technique in which two programmers work together at one workstation. One, the driver, writes code while the other, the observer or navigator,[1] reviews each line of code as it is typed in. The two programmers switch roles frequently.
While reviewing, the observer also considers the “strategic” direction of the work, coming up with ideas for improvements and likely future problems to address. This frees the driver to focus all of his or her attention on the “tactical” aspects of completing the current task, using the observer as a safety net and guide.
In one article entitled Llewellyn’s strong-style pairing he boldly proclaims his golden rule for this style of programing as follows, “For an idea to go from your head into the computer it MUST go through someone else’s hands”. This is interesting because with this programming style I can several parallels to “Teaching”. This is even more apparent when there is a significant difference in experience between the “Driver” and the “Navigator”, as the lesser experienced of the pair should benefit greatly from the more experienced partner.
I am very eager to try pair programming, hopefully in one of the following weeks in the bootcamp. This is a style of programing I feel that I have a good chance at accelerating quickly as I am considerate and have good interpersonal communication, which seems a paramount trait in this style of programming regardless if I will be the driver or the navigator.
