When I woke up this morning and fired up my Chrome browser, this quote (unattributed) appeared on my motivational Momentum dashboard, and I thought it was coincidentally apropos to this post I was planning on writing today. One of the key components of the Learn-Verified program is its student community. Through Slack chat, peer and instructor support tied into the curriculum to assist other students with issues as they work on lessons and labs, and most recently with the ability to easily create study groups on a given topic, Learn is continuing to place emphasis on collaboration.
But one of the more significant ways of collaborating with other students in the program is through learning to Pair Program as a development methodology. At the end of each significant curriculum module, we are to pair with another individual to complete a final project. While generally pair programmers would be working at the same terminal, taking turns driving and providing feedback, Learn puts a spin on this as everyone is essentially “remote” and you could pair with someone on the other side of the world. Thankfully, with screen sharing tools like Screenhero (as I mention in a previous post), two individuals can be sharing the same screen and communicating verbally with keyboard and mouse input into the presenter’s screen while working on an assignment.
A few examples of how Pair Programming can be performed include:
- Pair – Pair the entire time working linearly together
- Pass – 1 person does 1 requirement and then the next person does the next one
- Parallel – work on different parts at the same time by agreeing on interfaces and stubs and meeting in the middle
Recently, I worked with one of my peers in a hybrid of “Parallel” and “Pair” programming, to create a Sinatra MVC application that replicated the basic functionality of twitter. The app allowed users being able to create/edit/delete/view (CRUD) their own posts, view other user posts, and ensure a user had the proper rights to perform these operations (i.e. a user needed to be logged in to view any post and could not edit or delete another user’s post). Both of us came in with ideas of what we wanted to implement with this project. We decided that we would initially work in parallel, where one person would work on a controller and model for one component, while the other individual would work on the views for a second component, following Sinatra and ActiveRecord conventions. Then we would share our work, and in reverse, one of us would complete the views for the other model/controller and another would complete the model/controller for the other views. At this point, we would also reconcile each other’s code to make sure a given MVC worked as expected. We went back and forth on this for a few days and until we agreed we were satisfied with fulfilling the basic requirements for the project. Subsequently, we virtually paired using Screenhero to implement a gem that would allow us to add flash messages to display error or success messages back to the end user (a capability native to Rails but not Sinatra) and also added a little design and color to the site using the popular Bootstrap framework. Our final project is available on github below.
One of the tenets of Ruby (in comparison with other programming languages) is that it allows a developer to implement the same functionality, yet the methods used can be completely different. While there are pros and cons to this, pair programming allowed me the opportunity to see additional ways adding a feature could be implemented based on how another person’s thought process works. There’s also the saying that “two heads are better than one” and by pairing together, we were jointly able to create a product that we could also individually be proud of.