On remote communication

:wave: friends!

I’m not going to lie. Remote is hard. Communicating is even harder when we can’t see each other’s facial expressions or hear the tone of voice.

I’ve received some feedback about tone in GitHub pull-requests that came off as less than friendly. It’s the first time I’ve seen this problem, and in the past, I’ve used a list I like to call the five commandments of code reviews.

#1 Thou shall not use the word “just.”

“Just” is a poisoned word that tends to undermine one’s effort. If it were just this or that, you’d do it yourself.

#2 Thou shall not make assumptions

We’ve all seen this. A piece of code gets introduced that, in your previous experience, caused problems. The gut reaction is to reject the PR with “this will break”. That tone of reply assumes the author hasn’t considered the issues and starts the conversation on the wrong tone. “Have you considered X?” is a much more productive way to address potential problems.

#3 Thou shall not be married to the code

Most software engineers I know (myself included) have a huge ego problem. So, when someone tells us that the approach isn’t ideal, it stings. Remember that criticism is (and should be) about your work, and not directly about you.

#4 Thou shall not use the same person to get PR reviews all the time

Yeah, just no. Having a :+1: buddy isn’t reviewing. It’s AaaS (Approvals as a Service).

#5 Thou shall make an effort to look at PRs that need reviews daily

There are so many missed opportunities when folks don’t spend 30m looking at unreviewed pull-requests. Getting more eyes on a problem means a better solution overall, and faster approvals mean faster shipping.

Remote is hard, but we’re Status; we’ve got this!


you broke the first rule.


You got me there :wink:


Totally agree with all your points and this one in particular.

I personally try to review all PRs from my team. It can be tedious sometimes, but I go at them as they pass.
The multiple advantages are:

  • it often means there will be more reviews on the PR. Hopefully, more feedback === more quality
  • I get to learn about the new feature or how to fix a particular bug
  • in general, I get to know more the code base

Good points here! Agreeing with everything said.

A while back I wrote a short article about Improving your Open Source experience for contributors as well as maintainers of OSS. Maybe it has some lessons learned that are useful for ppl reading this here as well…