...And how to make sure you get one before your changes become as stale as those pretzels you left on your desk in March 2020.
It's pretty simple: You changed some code. You'd like to publish the thing to production so you can return to more important tasks, like learning life skills from the latest issue of Nintendo Power, developing a CSS-only solution for inverting a binary tree, or adding yet another easter-egg to the product that you can show your boss after you're fired.
Some teams don't require code reviews before merging & publishing changes. If that's you, you're probably here looking for memes (they're at the end). For the rest of us, we'll need some tools & tricks to ensure our changes don't get ignored...
Know the Obstacles before you:
- Reviewing code doesn't get anyone promoted, so most engineers don't prioritize it. (If your company does, please email me)
- That one engineer / tech-lead / manager that reviews everyone's stuff is usually overwhelmed, and the sight of another PR link might just be the extra push they needed to quit and start a second career streaming on twitch. By most Thursdays, I'm dangerously close to starting a channel about the Eye of Mauritania.
Cheat Codes for us Gamers:
- Be a good reviewer. If you review changes for your colleagues, and do it promptly, they'll be more likely to return the favor.
- Being a good reviewer is just level 1. Be a higher-level NPC, code-review wizard. Be so OP that other engineers beg for your review before they publish. How? Find out now for the low low price of $53.38, payable in 17 easy installments. Or just read this article.
- Ask nicely. Or better yet, be nice all the time. It's not always easy to summon the activation energy required to help the team's jerk-in-chief. Human nature and all that.
- Offer to jump on a call and do a live-review, if they prefer. Some people prefer this. For the sane among us, this offer might scare them into reviewing your code right away.
- Be sure your changes include the proper metadata: A good description of the problem you're solving, background info that will help them understand the problem space, a link to the ticket / change-request, before & after screenshots.
- For love of all that is sacred, keep the changes small. If you're asking someone to review a PR with 1.21x109 lines changed across 88 files, you're gonna see some seriou- well, you're gonna have a a bad time. You might have to take your team's pulse on this one, but I would prefer reviewing a dozen smaller PRs over the course of a week than one King-Hippo-sized dump on a friday afternoon.
The Memes
