Code Review Etiquette - 𝐇𝐚𝐫𝐝-𝐞𝐚𝐫𝐧𝐞𝐝 𝐋𝐞𝐬𝐬𝐨𝐧𝐬 After 10+ Years of Reviews 🚀 The goal is shipping reliable code, not winning arguments. 😊 𝐀𝐬 𝐚 𝐑𝐞𝐯𝐢𝐞𝐰𝐞𝐫: 𝐃𝐨'𝐬 ✅ ◾ Review the code within 24 hours - blocking teammates kills productivity ◾ Start with "What problem is this code solving?" ◾ Look for security vulnerabilities first, then architecture, then style ◾ Ask questions instead of making accusations ("What's the reason for...?" vs "This is wrong") ◾ Suggest alternatives with code examples when possible ◾ Acknowledge good patterns and clever solutions 𝐃𝐨𝐧'𝐭𝐬 ❌ ◾ Don't nitpick about style if there's an automated linter ◾ Don't rewrite the code in your preferred style ◾ Never make it personal - critique the code, not the coder ◾ Don't approve without actually reviewing ◾ Don't block PRs for minor issues 𝐀𝐬 𝐚 𝐂𝐨𝐝𝐞 𝐀𝐮𝐭𝐡𝐨𝐫: 𝐃𝐨'𝐬 ✅ ◾ Keep PRs small (under 400 lines when possible) ◾ Add context in PR description (screenshots for UI changes) ◾ Self-review before requesting others ◾ Break down large changes into smaller PRs ◾ Respond to comments within one business day ◾ Add tests for new code ◾ Document non-obvious decisions 𝐃𝐨𝐧'𝐭𝐬 ❌ ◾ Don't take feedback personally ◾ Don't push back without explanation ◾ Don't mark conversations resolved without addressing them ◾ Don't submit PRs without testing locally ◾ Don't expect instant reviews for massive changes You can add more, based on your experience. 👍 Happy to discuss. --------------- 👍 Follow - Mayank Ahuja 🗒️ Newsletter - https://lnkd.in/dJByxEYY #code #codereviews #softwaredevelopment #technology
Great, thanks for sharing! Wanna know why you'll never witness the rise of a new wasteland order? 💥 WITNESS ME! 🌋 As I dive into the inevitable extinction event for middle managers: the great AI meteor of efficiency! ☄️ 'I am your redeemer!' or just another spreadsheet fossil? Check out at https://lnkd.in/dv9YTeC2
I love this post. It contains a lot of the information in the Google Code Review Guide. https://google.github.io/eng-practices/review/reviewer/standard.html
Code reviews can make or break team dynamics. For me, the best reviews focus on collaboration, not ego. If a comment doesn't help the author improve, it's noise, not feedback. And let's be honest, blocking PRs over minor issues is the fastest way to kill momentum. What’s your take on balancing speed vs perfection in reviews? Mayank Ahuja
Code Reviews are a tool to learn, not to blame. Simply put, Mayank Ahuja
The reminder to critique code, not the coder is so important. Reviews should help the team grow, not create tension.
Code reviews are about code and learning, not ego 🔥
After years of code reviews, I've definitely learned that the goal is always to improve the code and the product, not to win an argument or impose one’s personal preferences.
This is one of the most important points for me and one that I am still working on: Don't take feedback personally.
Shipping reliable code is the name of the game. Let's keep it constructive and collaborate effectively.
Senior Software Engineer | Scrum Master at Ford Otosan
2wNice sharing. With your permission, as a reviewer, I'd like to add a few points that I personally pay the most attention to: ◾️ Prioritize code readability. Code is written not only for machines but also for humans. Aim to write code that is easy for everyone to understand. ◾️ Identify repetitive code. (Note: This requires a high dose of love for reading code 😄) ◾️ Consider the feedback you receive and create standards specific to the company you work for. ◾️ Prepare a document for code reviews. Explain the standards you apply with examples of code and clarify the reasoning behind them. ◾️ If you have time, don't hesitate to try pair programming. ◾️ If you're doing only a technical review, avoid interfering with business rules. Leave this responsibility to the team members of the person who wrote the code.