Code Review Etiquette For The Modern Developer
No, it’s not just LGTM. It’s about far more than just LGTMs and GEFNs. Sure, the little rocket 🚀 and 🚢 emojis help, but that isn’t what code review is all about, and it never was. If code reviews for you are a checkbox exercise, you’re in the right place. If code reviews for you are what slows you down, you’re also in the right place. Frankly, regardless of what your relationship with code reviews is, you’re probably still going to learn something today, so keep reading.
High priority
Opinions on this may vary, but the way I look at it is from a team perspective. A pull-request (PR), is an attempt to get some work done, move it to the next stage. That isn’t an individual goal, that is a team goal. If every team member only cares about themselves and the work they do, you don’t have a team, and you’re unlikely to succeed.
This is why, for the last few years, I have made it my priority to review people’s code as soon as they submit a PR. Learning to break your own flow to help the team succeed will make you a better engineer and help you learn that context switching can actually work in your favour. If everyone starts doing this on the team, you suddenly find your PRs reviewed and maybe even approved within just a few minutes.
Break your flow and review people’s code promptly. The team’s success is your success.
Make it meaningful
Look, I’ll admit that I have left LGTM and GEFN messages on people’s PRs before, but the former only when I genuinely had no questions and was happy to approve then and there, and GEFN when there was a discussion involved as to why the solution isn’t ideal but acceptable under the circumstances. Provided you are part of a good team with great values, that will be more often the case than you expect, and when it isn’t, then it’s time to write a more elaborate comment.
This is no place to write another Dostoyevski, though. Keeping it succinct,
0 Comments