Cultural Blog 4: Pair Programming and Feedback


A growing practice among programmers today is the pair programming session. Gone are the days of the lone coder, sitting in the corner, hoody up, headphones and yellow tinted glasses on, closed off to the world. Today’s programmer is a collaborator, usually sitting down for friendly sessions with someone who is either more experienced or less experienced than them. This method is almost essential in most tech companies (where the turnover rate is high), since new coders need to be shown the ropes and veteran coders need to make sure that their code isn’t destroyed by a bunch of untrained whipper-snappers.

At DBC, the benefits of pair programming are both apparent and occasionally out of reach to the new programmer. Personally, I was looking forward to being the bearded, bespectacled, beheadphoned, behooded guy in the corner working on my code, so it’s been a bit of a transition for me to be comfortable working out a solution with someone. The benefit, of course, is that pairing prepares us for a future of collaborative programming in our professional careers. It helps us learn from each other so we’re more on the same page, it gives us an opportunity to share our own knowledge in a personal setting, and it forces us to improve our communication skills as we learn how to explain why we used a particular method to solve a problem.

Of course, this works perfectly in theory, but not always thus in practice. When my pair is more experienced than I am, I feel stressed and under-prepared for the entire session. Maybe it’s my fault that I can’t keep up, or maybe it’s my pair’s fault for not helping me understand, but frustration can build. When I am more experienced than my pair, I have to do my best not to jump forward to the solution that I can already see. Instead, I do my best to help my pair along, making sure they understand the direction we’re going. This can also cause frustration, though, because as patient as I am, not moving forward can be excruciating. My pair feels frustrated as well, since they desperately want to understand, but still need time to work it out on their own. And if both pairees are equally prepared? Well, it can either be a beautiful experience or an ugly mess. When both are equal, they either complement each other and the code is created smoothly, or they disagree about every single aspect of the code because they believe their own idea is better. If they get lost, then they get really lost, since they both have the same strengths and weaknesses and can fall down the same rabbit holes.

So what does all this mean? Pair programming, like anything else in life, takes practice to be successful. You wouldn’t sit down and believe you can create magical code with your fingertips without any training, and it’s even less likely that you could do all that while also collaborating with another programmer, regardless of skill level.

Personally, I feel like I’ve been very successful in my pair programming endeavors. My fellow beginners and I get along well, we communicate our issues and concerns, and we always solve the challenge, even if we’re not particularly happy with the initial result. I find it very rewarding when one of us has an idea, and the other one is excited to run with it to see what happens. It makes everyone feel included, and the learning can continue.

After programming with a pair, we are required to provide feedback (semi-anonymously). As a former employee at Apple, I am all too aware of the feedback culture and the need to provide it ‘fearlessly’. When we saw any employee behaving in a way that did not promote a good customer experience, it was our responsibility to let that person know at the earliest possible opportunity, preferably in private. We also were able to provide positive feedback when an employee went above and beyond, but even this could sometimes be stressful.

Here’s the issue: any employee can give feedback to any other employee, regardless of position. New employees can provide feedback to managers, one department can provide feedback to another. This is a great idea in theory, but it can get out of hand when not used in moderation. Some employees make it their duty to provide feedback at every single opportunity, and it turns them into a sort of hall monitor. Not to mention, providing feedback also requires permission to share that feedback, and sometimes people don’t want to hear that they did something wrong. I still feel there’s an opportunity for providing in-the-moment feedback, but there must be a better way.

DBC hasn’t completely solved the feedback issue, but it’s definitely on the right track. When I pair program with someone, I’m required to provide feedback. Being forced to critique someone makes one analyze every word they say, and doing so in written form makes sure that they can edit anything they might later regret saying. We’re also required to give both positive and negative feedback, so I have to really think about the constructive criticism I want to provide. As mentioned earlier, my feedback is semi-anonymous, meaning it doesn’t contain my name or my pair’s name, and even though they might figure out who sent it based on context clues, others who read it won’t know who it pertains to. And that’s the clincher that makes feedback at DBC work so well: peer feedback evaluation. Even after following all of the protocols for providing feedback, my pair still doesn’t get my feedback unless it is rated highly enough by other DBC students. If it doesn’t meet the standards for Actionable, Specific, and Kind feedback, its rating is lowered and it never reaches the recipient for whom it was intended.

I personally love this system. I love getting feedback and being able to improve myself based on what others think of me. Usually, I know what issues I’m facing and am encouraged to work harder after receiving the feedback. My only negative feeling about it is the human equality element. Here’s what I mean: I want to provide both positive and negative feedback to my pair. My feedback is almost always constructive, and pinpoints an issue I think my pair needs to work on. However, some of the feedback I receive is overly positive, not always focusing on providing something for me to improve upon. I’m not sure if there’s a fear of offending, or if I really am that great (I’m not), but it rarely serves anyone to provide lip service. It makes me worried that I’m being too harsh in my feedback, but it also makes me resolve not to change my methods, because I really want to help my classmates.

Going forward, I’m going to continue to look for opportunities to improve on not only my programming skills, but also on my communication skills both during pairing sessions and feedback writing. I enjoy writing and reading feedback, so I will keep embracing that process. It really can work, but only when everyone involved is being as constructive and open as possible.

Feedback: give it, get it, apply it. I’m Edwin Unger, and I’m a web developer. Sort of.