Thoughts on Peer Programing

by Troy Leach and Gale Van Rossem

July 22, 2014

When a potential boot first starts to delve into the Dev Bootcamp experience one thing becomes abundantly clear almost instantly. One of the core skills developed at DBC is Peer Pairing. Offering major advantages in quality of code, sharing of ideas and onboarding of new programmers it is easy to see why pair programming is become one of the hottest issues in Web Development.

Clearly, pair programming is one of the most important skills that DBC teaches. Here is a look at four of the reasons that pair programming is so important:

Pair programming is increasingly common in software development in general and pretty standard for ruby on rails jobs and likely to be part of the interview process.

Enhances the learning experience - Knowledge is constantly shared between pair programmers, from tips on rules to design. Gives the oppertunity for one pair to examine the others code and provide feedback which is needed to increase their own abilities to develop.

Increases quality of code - less bugs. Pairing partners are less likely to go down in the rabbit hole, and tend to come up with better designs.

Promotes the sharing of ideas. Everyone has different minds that think in very different ways. Everyone also codes in different ways. Pair programming allows for, at a minimum, two ideas. This goes along with the idea that it enhances learning.

Pair Programming is a way of writing code with two people working on the same document. One person types and is typically called the "Driver." The other person is called the "Navigator."

Although the terms can mean different things to different programmers, typically the Navigator will instruct the Driver which line of code to work on next and watch for errors in the code.

The driver usually goes where the Navigator says and is not to work on any other line of code. The Driver is not to make any changes to the code without discussing with the Navigator first. In most pairs, the Driver and Navigator will switch roles from time to time. If both programmers are equal in knowledge and skill, they will typically split the time in the two roles about 50/50.

One thing is for sure. If you attend Dev Bootcamp, you are going to learn how to be a good pair programmer. With all of the benefits pair programming brings to the table, it is easy to see why it is spreading so quickly in the development community. DBC will likely continue to focus on pair programming as a main component of it's disruptive educational system well into the future.

Our Reflections

What was it like to pair for the first time?

Troy -

I was nervous. I really didn’t know what to expect and I didn’t know how someone would take to me. I have always been taught to be prepared for anything, anticipate what questions might be asked, what possible answers to give, but with this, I had now idea. As soon as the pairing started my partner made me feel right at home. In our ‘check in’ I expressed my feelings and thoughts and Gale listened. I believe a productive check in is vital for the success of any pairing.

Gale immediately made me feel comfortable and I was able to ask questions and feed off his knowledge. Some folks tend to tell ‘you’ how to do something, not really explaining the why’s behind. Gale did an excellent job of explaining to me, in a way that I could understand, why we were doing things.

Gale -

I was nervous before we started because I wasn't sure how easy it would be to communicate in a way that was efficient. The nerves went away quickly though, and I credit Troy for that. We had a great "Check In" at the beginning and I think that really helped us.

We both seemed at ease and ready to work at that point. We took a lot longer with the challenge than I expected. I don't think we could have done much to change that. It takes longer to make changes because you have to communicate a lot.

Troy was very good at communicating, and I think that really helped make it a productive and enjoyable session. Even though it went longer than I expected, it never felt like a drag. I think the finished product speaks for itself. I am very happy with what we accomplished and I enjoyed the experience very much.

I will be very lucky if every pairing session goes this smooth.

Did you enjoy it?

Troy -

I loved our pairing session. The time flew by, and yeah it took longer than either of us had thought but it didn’t seem like, ‘oh god we have to finish we are running out of time’ and I think we ended up with a very professional and educational site.

Gale -

Yes, Very much!

What worked?

Troy -

I really thought we worked well together with respect to driving and navigating. respecting each others thoughts and ideas. Clearly Gale has more experience than I but I never felt inferior. This site is OURS for sure. I don’t know that I like the "you drive, I navigate", then switch. I like the approach you type for 30 mins and we talk about what we are doing, then the other types for a while. What I’m trying to say is I think our communication worked very well together.

Gale -

I think we had a good system where one person was driving and the other navigating and we did switch at least once. I think we were both very agreeable and decision making was surprisingly easy because of this. At the same time, neither of us were afraid to state an opinion if we saw something wrong or something that just didn't work.

What didn't work?

Troy -

I know that constructive critisum is vital in making any relationship work. However I don’t feel like anything ‘didn’t work'

Gale -

I feel like it worked very well. I'm comfortable giving feedback here, but I really feel like we did the best we could considering it was the first real pairing session for each of us. I think it took a long time, but I don't see that we could have changed that in this case. We could have rushed through things, but we would not have learned as much.

I do think that I should have read the assignment closer, so that we wouldn't have had to revisit a few things. I'll take the blame for that.