Code Review Workflow for Project Teams

In the last 11 years of my career, I’ve participated in code reviews almost daily. I’ve sat through 100s of review sessions with seniors and colleagues. Here’s how to make your code reviews smoother, faster and easier: 1. Start with Small, Clear Commits    - Break your changes into logical, manageable chunks. This makes it easier for reviewers to focus and catch errors quickly. 2. Write Detailed PR Descriptions    - Always explain the “why” behind the changes. This provides context and helps reviewers understand your thought process. 3. Self-Review Before Submitting    - Take the time to review your own code before submitting. You'll catch a lot of your own mistakes and improve your review quality. 4. Ask for Specific Feedback    - Don’t just ask for a “review”—be specific. Ask for feedback on logic, structure, or potential edge cases. 5. Don’t Take Feedback Personally    - Code reviews are about improving the code, not critiquing the coder. Be open to constructive criticism and use it to grow. 6. Prioritize Readability Over Cleverness    - Write code that’s easy to understand, even if it’s less “fancy.” Simple, clear code is easier to maintain and review. 7. Focus on the Big Picture    - While reviewing, look at how changes fit into the overall system, not just the lines of code. Think about long-term maintainability. 8. Encourage Dialogue    - Reviews shouldn’t be a one-way street. Engage in discussions and collaborate with reviewers to find the best solution. 9. Be Explicit About Non-Blocking Comments    - Mark minor suggestions as “nitpicks” to avoid confusion. This ensures critical issues get addressed first. 10. Balance Praise and Criticism    - Acknowledge well-written code while offering suggestions for improvement. Positive feedback encourages better work. 11. Always Follow Up    - If you request changes or leave feedback, follow up to make sure the feedback is understood and implemented properly. It shows you’re invested in the process. -- P.S: What would you add from your experience?

100 lines of code: reviewed in 10 minutes. 1000 lines of code: reviewed never. Code reviews exist to catch bugs, improve maintainability, and help teams write better software together. But most engineers treat them like assignments to pass instead of collaborative checkpoints. That mindset kills the process before it starts. ➧ When you're submitting a PR: 1. Keep it small Aim for 10-100 lines of code per pull request. Past 100 lines, reviewers start skimming. Past 500, they stop caring entirely. Large PRs are harder to review, take longer to approve, and make it nearly impossible to catch real bugs. Break your work into isolated, logical chunks. Yes, it's more work upfront. But it ships faster. 2. Write a description Give context. Always. Your reviewer might be on a different team, in a different timezone, or new to the codebase. Don't make them guess what you're solving. If you're fixing a bug, explain what broke and link to the ticket. If it's a visual change, add before/after screenshots. If you ran a script that generated code, paste the exact command you used. Context turns a confusing diff into a clear story. 3. Leave preemptive comments If part of your diff looks unrelated to the main logic, explain it before your reviewer asks. "Fixed a typing issue here while working on the main feature." "This file got reformatted by the linter, no logic changes." These small clarifications save back-and-forth and show you're thinking about the reviewer's experience. ➧ When you're reviewing a PR: 1. Be overwhelmingly clear Unclear comments leave people stuck. If you're making a suggestion but don't feel strongly, say it: "This could be cleaner, but use your judgment." If you're just asking a question, mark it: "Sanity check, is this intentional? Non-blocking, just curious." Over-communicate your intent. Especially with remote teams or people you don't know well. 2. Establish approval standards with your team Decide as a team when to approve vs. block a PR. At Amazon and now at Nielsen, we approve most PRs even with 10+ comments because we trust teammates to address feedback. The only exception: critical bugs that absolutely can't go to production. Without clear standards, people feel blocked by style comments and approvals feel arbitrary. Talk to your team. Set the rules. Stick to them. 3. Know when to go offline Some conversations don't belong in PR comments. If the code needs a major rewrite, if there's a design disagreement, or if you're about to write a paragraph, stop. Ping your teammate directly. Have a quick call. Save everyone time. Leave a comment like "Let's discuss this offline" so they know you're not ignoring it.

Git Pull Request Workflow 0. 𝐒𝐭𝐚𝐫𝐭 𝐰𝐢𝐭𝐡 𝐚 𝐂𝐥𝐞𝐚𝐧 𝐒𝐥𝐚𝐭𝐞 ➟ Before beginning any work, ensure your local repository is synced with the latest code from the remote main branch. git checkout main git pull origin main ➟ Create a descriptive branch for your feature or fix git checkout -b feature/add-user-authentication ➟ Use a clear, consistent naming convention for branches (e.g., feature/, bugfix/). 1. 𝐌𝐚𝐤𝐞 𝐋𝐨𝐠𝐢𝐜𝐚𝐥, 𝐀𝐭𝐨𝐦𝐢𝐜 𝐂𝐨𝐦𝐦𝐢𝐭𝐬 ➟ Develop your feature or fix in small, logical chunks. ➟ Each commit should address a single, meaningful unit of work. git add src/auth/ git commit -m "Ticket 1234: implement JWT token generation" 2. 𝐏𝐮𝐬𝐡 𝐘𝐨𝐮𝐫 𝐁𝐫𝐚𝐧𝐜𝐡 𝐭𝐨 𝐑𝐞𝐦𝐨𝐭𝐞 ➟ Once you’ve completed your local changes, push your branch to the remote repository. git push -u origin feature/add-user-authentication ➟ Create a pull request (PR) through your Git platform (e.g., GitHub, GitLab, Bitbucket). Include: - A clear title summarizing the change. - A detailed description explaining the purpose, implementation, and potential impacts. - Links to related tickets, issues, or documentation. - Screenshots or videos for UI/UX changes. 3. 𝐂𝐨𝐝𝐞 𝐑𝐞𝐯𝐢𝐞𝐰 𝐏𝐫𝐨𝐜𝐞𝐬𝐬 ➟ Automated Checks - CI/CD pipeline should run tests, linting, and static analysis to validate the code. ➟ AI augmented Feedback - Tools like CodeRabbit can provide immediate, context-aware suggestions for: - Code style inconsistencies. - Common bugs or anti-patterns. - Security vulnerabilities. - Performance optimizations. ➟ Human Review - Teammates should evaluate: - Architecture and design. - Maintainability and scalability. - Alignment with business logic and requirements. - Adherence to coding standards. Tip: ➬ Encourage open, constructive discussions during reviews. ➬ PRs are an opportunity to collaborate and improve, not a battleground. 4. 𝐊𝐞𝐞𝐩 𝐘𝐨𝐮𝐫 𝐁𝐫𝐚𝐧𝐜𝐡 𝐔𝐩 𝐭𝐨 𝐃𝐚𝐭𝐞 ➟ Keep your feature branch synced with the target branch (e.g., main) to avoid conflicts later. 5. 𝐅𝐢𝐧𝐚𝐥 𝐏𝐫𝐞-𝐌𝐞𝐫𝐠𝐞 𝐂𝐡𝐞𝐜𝐤𝐥𝐢𝐬𝐭 ➟ Before merging your PR, ensure the following - ✅ All CI checks pass (tests, linting, builds). ✅ Required approvals are obtained from reviewers. ✅ All review comments are addressed with follow-up commits. ✅ Documentation is updated (e.g., README, API docs). ✅ The branch is up to date with the target branch (perform a final rebase if necessary). 6. 𝐌𝐞𝐫𝐠𝐞 𝐭𝐡𝐞 𝐏𝐑 ➟ Choose the appropriate merge strategy based on your team’s workflow - - Squash Merge [Combines all commits into one for a clean history.] - Rebase Merge [Maintains a linear history while preserving individual commits.] - Merge Commit [Creates a merge node, preserving the full commit history.] ------- Remember, A good PR isn’t about showing how much you’ve done, it’s about making it easier for someone else to understand and build on your work. 🤗 #git

9 code review practices your team should follow to go from Good → Great projects. (these helped my team deliver 100s of projects without wasting hours fixing bugs) 🟢As a team: ➡️Establish goals and expectations beforehand: for example: + functional correctness + algorithmic efficiency + improving code quality + ensuring code standards are met ➡️Use code review tools Use: (GitHub PRs, GitLab MRs, and Atlassian Crucible). + easily track changes + streamline the review process ➡️Automate code checks:  It will help you to: + find syntax errors + avoid common issues + reduce code style violations and potential bugs. 🟡As a reviewer: ➡️Start early, review often:  do this to: + catch issues early + prevent technical debt + ensure that code meets project requirements. ➡️Keep reviews small and focused:  you get: + an easier process + shorter turnaround time. + better collaboration in the team ➡️Balance speed and thoroughness:  + do comprehensive reviews  + but avoid excessive nitpicking ➡️Give constructive feedback: always be: + specific, actionable, and respectful + focus on improvement rather than criticizing.  + make a space for open communication to answer questions & give clarifications. 🟠As a reviewee: ➡️follow up on feedback:  + don’t take the comments personally + actively work on feedback after the session + make necessary revisions and follow up to confirm ➡️Follow coding standards:  focus on improving: + readability + maintainability Remember - mutual respect during the code reviews is crucial for a great team culture! – P.S: If you’re a Sr. Software engineer looking to become a Tech Lead or manager. I’m doing a webinar soon. Stay tuned :)

3:47 AM on a Tuesday. My phone buzzes. PagerDuty alert. The system is down. I scramble to my laptop. Database connections maxed out. API timeouts everywhere. Users can't access the service. We get it back up. Block the offending caller. System stabilizes. The post-mortem hits differently. Two experienced engineers reviewed the PR. Tests passed. Code worked exactly as specified. But nobody asked one question: "How would someone abuse this?" That single question would have saved us. One line of code. Five minutes. Crisis prevented. Here's what I learned after years of causing (and fixing) production incidents: Code review isn't about what to check. It's about how you think. Most engineers do one of two things: • Rubber-stamp with "LGTM" • Spend hours arguing about formatting Both miss the real problems. I tried comprehensive checklists. Ran formal review sessions. Eventually everyone burned out. Then I found something that actually works. Three focused passes. Each with a different persona. Each asking different questions. Pass 1: Does it work and make sense? Pass 2: Can we live with this code in six months? Pass 3: How would I break this? I wrote the full breakdown of the three-pass system, including exactly what to look for in each pass and how AI can help. https://lnkd.in/ehSMw8ka