Publish-Only

There’s more than one way of delivering a code review, and that’s the topic that got me on this tangent.

"Message in the bottle" by Dasha Bondareva is licensed under CC BY-NC 2.0.

I’ve had code reviews from people who thought it was some sort of a flex to go to great lengths to find any kind of an issue in a pull request. It can take a lot of the joy out of the job and some days I’d dread sitting down at my desk knowing that I would have to deal with this kind of largely meaningless back and forth. I’ve toned down my own code reviews a lot after being on the receiving end of meaningless pedantry.

It may sound silly, but I had a colleague who would use emoji in code reviews and it was always kind of fun to see which ones he could jam into the review.

• Dependency bump? 📦 ⬆️
• Fixing a flaky test? 🎲 🚫
• Performance improvement? 🐢 ➡️ 🐇
• Deleting code? 🔥 🪓

What eventually happened is that other people started doing this and it became kind of a fun game to see if you could express the intent of a PR with emoji. When you get this kind of feedback, you know that whatever else is in there isn’t going to be harsh. It sets a fun tone for what can actually be an enjoyable exercise: you get to learn something from a colleague and sometimes what you learn is that your work is okay to merge without changes.

Contrast that with the reviews that are a laundry list which send the message “what are you even doing here?” and you pretty quickly get to know whom you enjoy working with. Making a code review not feel like being hit with a hammer is not hard. It just takes a bit of effort. You will give up some economy, but you’ll also retain more humanity.

On a slightly related note, one of the funniest things I ever saw at this workplace was a chat message where one developer announced they were going “afk (away from keyboard) for 20 minutes” only to have a teammate attach the “📰🚽” emoji to the message. Obviously you’d need to tread lightly with this kind of jocularity.

"1947 advertisement for Lux Toilet Soap" by Matthew Paul Argall is marked with Public Domain Mark 1.0 .

Now, depending on the culture of your workplace, you may need to put up with this kind of thing at work, but you do not have to grin and bear it everywhere else. The same types are on social media. Depending on where I’m sharing something, I may treat it as a publish-only space. For example, I find some people on Reddit can have a pretty hefty capacity for trying to ruin someone else’s day, so I often just won’t read the comments there. (That’s not to say Redditors are inherently cruel, but that the platform often doesn’t disincentivise bad behaviour.)

Your mileage may vary, but that’s what I’ve found helps me better enjoy my day. I accept that people who lash out exist, but I also accept that I don’t need to engage with them.

I could also just say I’m not going to share posts on Reddit, but the truth is that it can drive a significant amount of traffic. So, depending on how I’m feeling on a particular day with Reddit, I may just throw something over the wall and not stick around to find out what happened. If I feel I have a thick enough skin on a different day, I may engage fully. I don’t have a blanket ban on commenting there.

My one other caveat about Reddit is that I have to make sure there’s not even a whiff of an em-dash in my writing for fear that people start getting their LLM pitchforks out. I had one post removed from r/programming for being “mostly LLM-generated”. Spoiler alert: it wasn’t. My feelings on that are that I like em-dashes and I have for a lot of years, but I’ll probably need to use some other kind of punctuation in their place if there’s a chance a post gets arbitrarily removed. That’s currently not a hill I’m willing to die on.

Publish-only is a valid choice, in the same way that I don’t engage with someone who flashes me their middle finger from their car in traffic. If communication feels like a fool’s errand, I don’t have to default to playing the fool.

Related posts:

• Code Review Is the Hard Part