Pair Programming
My first pair programming experience was a rather insightful one. Upon hearing that a pair programming exercise was scheduled for us in the early weeks of our web-development bootcamp, I was immediately struck with panic. Being an introverted coding noobie I felt completely unprepared to showcase my problem-solving and coding skills in front of a stranger. Fortunately, I was paired with another coding noobie and pair programming is absolutely not meant to flaunt your skills to a colleague.
As the name suggests, pair programming takes two programmers and pins them together on the same computer. Each programmer has a specific role, often referred to as the driver and the navigator. The driver is at the keyboard, focused on addressing the immediate task at hand. The navigator observes, researches, and plans for what comes next. To promote equal participation it is encouraged to switch the roles at regular intervals. Since pair programming is quite demanding it is also recommended to take short breaks at regular intervals or to follow the Pomodoro technique. While it may appear to be twice as costly to have pair programming there are many advantages that come with it.
- Problems are solved more quickly
- Fewer mistakes
- Sharing knowledge
- Helps focus
- Faster integration of new members
- Collective code ownership
Despite having to study remotely, Lighthouse Labs has provided us with many opportunities to try out pair programming. I have found that I have benefitted greatly from it. I’m sure I’m not the only one who has difficulty focusing on the task at hand — especially when so many distractions are readily available at home (social media, family members, cats, the washing machine, etc). Having someone there to keep me accountable really reduces how scattered my brain can be.
I’m sure matching personalities is important to have an effective and efficient pair programming session but so far I have been very lucky, in the sense that I’ve benefitted from everyone. I’ve learned things ranging from basic javascript concepts, cool extensions for vscode, shortcuts, and general workflow techniques. What’s great is that the knowledge flows both ways, everyone has something to share and something to learn.
The idea of collective code ownership is one I’ve only experienced on a small scale during a group project. To a large enterprise, I imagine it being a very big deal. This quote sums up the concept.
Collective code ownership abandons any notion of individual ownership of modules. The codebase is owned by the entire team and anyone may make changes anywhere.
My first experience with it was during a group project. One team member had been assigned a certain aspect of the project. When changes needed to be made because the concept of the project had slightly changed, it seemed as if the burden was on that one member to alter to code accordingly because that code “belonged” to that person. Working on that code felt like when you go on a hike and see a “private property” sign. Once you pass that sign there’s always an underlying awkwardness. I’m still not sure how I feel about code ownership. If someone is looking to make themselves valuable to a company, for job security, or as a pathway to a promotion, code ownership makes complete sense. Maybe collective code ownership could make you more disposable. I can definitely see why in some situations, people would be hesitant to share their knowledge. On the other hand, sharing is great and makes the work experience much more pleasant.
I’m sure I have many more pair programming sessions ahead of me and I’m looking forward to them.