Mayank Ahuja’s Post

View profile for Mayank Ahuja, graphic

Follow for Your Daily Dose of Coding, Software Development & System Design Tips | Tech Book Buff | Exploring AI | Everything I write reflects my personal thoughts and has nothing to do with my employer. 👍

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

  • No alternative text description for this image
Deniz Erdoğan

Senior Software Engineer | Scrum Master at Ford Otosan

2w

Nice 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.

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

Jim McMaster

Java Software Engineer

2w

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

Jai Jalan

I specialise in building, marketing software products from 0 with strong foundations | Built 20+ products with $100Mn+ ARR, Unicorns | Ex-Microsoft | IIT alum

2w

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

Like
Reply
Raul Junco

Simplifying System Design

2w

Code Reviews are a tool to learn, not to blame. Simply put, Mayank Ahuja

Owain Lewis

Director, Software Engineering | Courses for tech leaders | Learn to automate with AI.

2w

The reminder to critique code, not the coder is so important. Reviews should help the team grow, not create tension.

Alexandre Zajac

SDE & AI @Amazon | Building Hungry Minds to 1M+ | Daily Posts on Software Engineering, System Design, and AI ⚡

2w

Code reviews are about code and learning, not ego 🔥

Mojisola Alegbe

Frontend Engineer | Everything Tech | I build scalable, high-performance applications that drive growth for businesses and teams | JavaScript | React | TypeScript | GCP | Nodejs | Public Speaker

2w

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.

Like
Reply
Marcus Greiner

🌱 Life In Development | Software Developer (C#, .NET) | Passionate About Code Excellence and Clear Documentation

2w

This is one of the most important points for me and one that I am still working on: Don't take feedback personally.

Guilherme Bayer

Senior Fullstack Developer | Software Engineer | 10+ years | LATAM | Javascript | Python | React | Node.js

2w

Shipping reliable code is the name of the game. Let's keep it constructive and collaborate effectively.

Like
Reply
See more comments

To view or add a comment, sign in

Explore topics