Why “that person” commenting on your PR and blocking you is actually your ally
By: Ian Drennan
Tags: Software Development, Mentorship, Engineering, Career Development, Pull Request

We’ve all been there. It’s the 11th hour and you’ve been grinding on code, fighting builds and failed tests, and you’re finally in the home stretch. The code is checked in, the PR (Pull Request) is up, and you’re ready for people to approve this thing and get it out to production….and then…..

Before we get in to that let me give you a little background. My dad was a punch card programmer. When I was in school, being a “computer nerd” was the kiss of death for the social hierarchy nonsense that exists. I was a closet computer nerd, and swore I’d never get in to the industry (#ifailed — funny how that works out, but that’s a story for another time). Professionally, I’ve been in software engineering for 20+ years. I wrote software through the DotCom boom, for scientific studies in biotechnology, then moved on to being a consultant for private aviation, law firms, and major financial institutions. Working through a few other odds and ends in the industry, I found myself at VMware (incidentally, one of the most prestigious moments of my career). Along the road, I’ve had to ‘do it all’ so to speak. Many of the companies I’ve worked for had limited budgets, high delivery expectations, and limited time. Other endeavors in life shaped my risk vs reward abilities. For better or worse, I’d grown accustomed to paving my own way, and releasing software on my terms…until I started working at VMware. More on this later. For now, let’s get back to that PR.

“Have you considered writing this way?”; “consider yield”; “I don’t see any negative unit tests”; “why did you do Y?” — and the list goes on. The general reaction to PR feedback from many engineers is, very often, quite defensive rather than receptive. When we find ourselves in this situation, it’s easy to take these comments personally — after all we’ve been up crazy hours dealing with the minutiae other people don’t see. We hide behind a myriad of excuses in an attempt to defend our processes or justify the dismissal of valuable feedback — “other parts of the code do it this way”; “I’ll make a task and track that later”. Worst case, we simply start to ignore the information we’ve been gifted.

Gifted?! That wasn’t a typo. Consider this — some person took at least 30 minutes, very likely more, out of their already busy day to examine your code. They’ve tried to understand the problems you’re attempting to solve, share their experience, and also help your career! That’s right, help.

To understand this perspective, there are two anecdotes I’d like to share. First, on our team there is a reviewer (lets call them Person 1) who is uncompromising on quality and clarity. At first, working with them was a frustrating experience. It seemed like every little thing was nit picked at times and all I wanted to do was get my code released. Over time, and with some of the insights of my second anecdote below, I started to see that this person cared. They cared a LOT about how we did things and was constantly trying to make sure we all held ourselves to a higher standard — “status quo” wasn’t enough. We all have things that are important to us, and those are usually our strengths. We also have weaknesses, and with the right guidance they can be turned to strengths. A push, if you will, to help us all to be better.

The second anecdote is how our annual evaluation process works at VMware. We’re all evaluated on our code quality, how we contribute (or hurt) the code bases we work on, the way we respond and comment on PR’s, and how we fill out our stories. At first, it seems like a mountain of unnecessary paperwork. The process, however, also serves to independently validate people against this data. In fact, the evaluation is most often left to people who don’t work with the engineer being evaluated in order to be evaluated without bias. When we start looking at it from this perspective, the picture changes and it’s easier to see why the way we digitally represent ourselves is important.

When you consider the above, suddenly those frustrating comments begin to take shape as constructive, helpful (albeit sometimes abrasive) feedback. Rather than criticism, that information becomes an opportunity to be a better engineer, teammate, and contributor (not to mention steppingstones along the path of furthering your own career goals).

As I said to a co-worker who was recently the recipient of what appeared to be a particularly brutal PR, “it’s ok to have that defeated feeling. Think about it this way, though. How lucky are you that you have some of our best engineers HELPING you? They’re taking a significant amount of time out of their day to give you thorough, thoughtful feedback.”

So, how has this altered perspective changed things for me? Simply stated, I started to consider the following (and also encourage any engineers that I have the pleasure of collaborating with to do so as well):

As the Author

Would I show this at an interview? Every piece of code is an indicator of my abilities.

Every piece of code is an indicator of my abilities. Is the problem I’m trying to solve clearly stated? If someone unrelated to the problem read the code, would they understand the business and technical problems being solved?

If someone unrelated to the problem read the code, would they understand the business and technical problems being solved? Have I documented and applied the acceptable success criteria? Have I implemented sufficient negative test scenarios, happy path scenarios, unit tests, integration tests, etc.

Have I implemented sufficient negative test scenarios, happy path scenarios, unit tests, integration tests, etc. Is my commit message succinct and relevant? Does the commit message clearly articulate the items under change in summary and what a reviewer can expect when reading the PR?

Does the commit message clearly articulate the items under change in summary and what a reviewer can expect when reading the PR? Have I elevated our quality bar? At the very least, have I avoided the propagation of bad practices?

At the very least, have I avoided the propagation of bad practices? Am I thorough and calm when answering questions? When someone comments on the PR and I believe they are inaccurate, am I able to clearly defend my decision? If not, do I correct the item? Or, lacking an acceptable defense, do I try and defer (note: deferring over correcting is a red flag)?

As the Reviewer

Have I engaged the Author in a manner that establishes trust? We’re all busy, and it’s easy to fire off a terse one liner to the author. If my goal is to help them, or educate myself, have I done this in a constructive and approachable manner?

We’re all busy, and it’s easy to fire off a terse one liner to the author. If my goal is to help them, or educate myself, have I done this in a constructive and approachable manner? Are my comments helpful? This one is tricky. We all have our opinions as to how something should be done. The reality is we need to measure against “this is a demonstrably bad idea” and “well, that’s one way to do it”. In one situation, it’s an important point to stick to our guns. In the other, we find ourselves more in debate methodology and need to recognize this will simply distract the author from actually implementing necessary changes. As one of my mentors said, “Pick your battles wisely, and don’t use up all of your currency on items that don’t matter.”

This one is tricky. We all have our opinions as to how something should be done. The reality is we need to measure against “this is a demonstrably bad idea” and “well, that’s one way to do it”. In one situation, it’s an important point to stick to our guns. In the other, we find ourselves more in debate methodology and need to recognize this will simply distract the author from actually implementing necessary changes. As one of my mentors said, “Pick your battles wisely, and don’t use up all of your currency on items that don’t matter.” Is my phrasing absolute? If yes, then is it an appropriate topic to draw a hard line on?

If yes, then is it an appropriate topic to draw a hard line on? If there is an item of contention, is it simply a stylistic difference? Is it a position that the person will be unable to recover from? Or am I just arguing because I want it done my way (note: this is also a red flag)

Maybe these thoughts will help prevent you from blowing a gasket the next time you receive comments on a PR, and help you be a better mentor and teammate — after all, we’re all this together.

May the PR odds be ever in your favor!