Streamlining Code Reviews with Standardized Practices

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.

Line-by-line code review is finally dead. It's been a zombie for years - everyone's always hated doing it - but AI coding tools have exploded the number of PRs and made it finally impossible. Every org we work with bumps into this really quickly (see the attached chart). They start doing more AI coding and it breaks their processes because suddenly each dev is creating a few PRs each day but no-one wants to review them. (Also the PRs are often bigger but that's a topic for another day.) No-one signs up to be a coder because they love reading someone else's code, so no-one's motivated to spend half their day reviewing. So the review backlog grows and grows. This is a problem, but the solution isn't to shout at devs to review more. Rethink code review. The point of review is: 1) find bugs 2) make sure the code is consistent with the rest of the repo 3) check decisions with future implications 4) communicate the changes to other devs 5) have two sets of eyes so ISO27001/SOC2 auditors are happy (1) and (2) are now best done NOT by humans, but by automated tools including LLMs, probably multiple of them. (3) and (4) are important and should 100% be still done. (5) is still valid. Here's the coding/review process we see working best right now: * developer plans with the agent * developer reviews plan * agent implements * developer reviews all the code, especially the tests/acceptance criteria (sometimes get the AI to write the tests first to make this easier/parallelisable) * that review can either be locally or in a draft PR - best is usually in a PR because then CI can be running in parallel * the agent watches CI for failures and watches automated review feedback, triaging and fixing eagerly * then finally “Ready for Review” * only at this point does another developer act as reviewer, but they don’t review line-by-line, because that's been done by multiple agents * the developer needs to understand the goal and then review schema or infra changes, also review the new tests at least at principle level * the most important thing they need to review: decisions made in this PR which might have ramifications * what you’re looking for here is things that might have security implications, scalability implications, non-functional requirements implications, etc Your tools should be surfacing these decisions so that a developer can assess their implications. Yes, that's what we're building with Cadence - checking the code and the session log in parallel to understand and surface decisions - but use something else if that's better for you. But fundamentally it's time to rethink code review. Your devs will thank you for it!

Let's discuss how network code reviews and their connection to enhancing engineering excellence are essential, as many networks require top-tier code! As network engineering evolved from CLI wizards to infrastructure coders, something crucial followed: the need for real code quality processes, not just scripts that "work", but automation that is secure, readable, tested, and maintainable. At hyperscale, where a code bug can affect thousands of devices or misapply policy on the Internet scale, your review process becomes a critical control plane of safety. Let me guide you through how to enhance your network automation workflows by incorporating a robust code review discipline. The old reality: “It works on my repo” In many teams, automation started with “good enough”: - Engineers wrote network tooling in isolated repos. - Shared scripts via Slack or internal wiki. - Debugged issues in production environments (!) The problem? No codebase hygiene. No common patterns. No idea who changed what, when, or why. It worked… until it didn’t. What you can change: Build a code review culture for network engineering 1. Review templates tailored to Infra-as-Code Introduce a structured Pull Request template with: - Purpose & Context (what is this changing and why?) - Scope of Impact (which layers/services are affected?) - Validation Output (did it pass simulation/tests?) - Rollback Plan (how do we undo it safely?) - Security Considerations (are creds/tokens handled properly?) This forces engineers to think beyond the diff: to the blast radius of their change. 2. Linters and static analysis for network code You can integrate: - pylint, black, and bandit for Python scripts. - Custom YAML schema validators for network intent files. - Automated checks for dangerous patterns like: a) Raw eval() usage. b) Hardcoded credentials. c) Unbounded loops touching live devices. The goal here is to stop bad code before humans even see it. 3. Mandatory peer review with role separation You should enforce: - At least two reviewers per PR. - One must be a peer network engineer. - One must be a tooling/platform engineer (if code touched core systems). This creates cross-disciplinary learning and helps prevent siloed fragility. 4. Review rotations and async playbooks To keep velocity high: - Reviewers can rotate weekly, avoiding bottlenecks. - Build review checklists for common change types (e.g., policy rollout, topology update, new remediation logic). - And track review debt: PRs waiting too long can get flagged and prioritized. The results: 1. Security incidents related to automation code? Can be dropped to zero. 2. Code reusability and onboarding can be sped up. 3. Code review becomes a mentoring tool, not a bottleneck. 4. Most importantly, engineers will be more confident pushing changes at scale. Your automation must not be glue, and it needs to be safe, tested, and future-proof. I discuss this in more detail in my The Routing Intent newsletter!

Code review is not about making the code better. It’s about making the product better. A quick story. The code looked clean. Tests passed. CI was green. During review, a reviewer asked one question: “What happens if the webhook retries?” Nobody had thought about duplicate events. That single comment stopped a release. We fixed the flow, added an idempotency key, and avoided multiple charges to real customers. Product saved. Reputation intact. That’s the point.  Reviews save customers, not just lines of code. Here’s a practical playbook for reviews that actually protect the product. For the author • Keep PRs small. Small PRs get reviewed faster and have fewer surprises. • Self-review first. Run tests, lint, and a quick smoke locally. Don’t waste reviewers’ time. • Write a short summary. Explain intent, edge cases, and rollback plan. • Tag only relevant reviewers. Too many cooks slow the ship. • Link to design notes, tickets, and relevant docs. Context is gold. • Add automated tests and explain what you did not cover and why. For the reviewer • Acknowledge within 24 hours. Even a quick “I’ll review by X” keeps momentum. • Scan for product impact first. Ask: could this break billing, data, or UX? • Focus on intent over style. Prefer patterns used by the team, not personal preferences. • Use a checklist: correctness, security, performance, observability, rollback. • Give actionable feedback. Point to examples or tests that would help. • Keep tone constructive. Critique the code, not the person. • Approve when it’s safe. Minor nits can be fixed later. Process tips that scale • Automate checks. Use CI for unit tests, static analysis, security scans, and linting. Let the machine catch noise. • Gate merges on green CI and at least one approval. • Reserve a daily calendar slot for reviews to avoid context switching. • Document common review patterns and keep a living checklist. • Use feature flags and canary releases for risky changes. Roll forward, not blind. • Maintain runbooks for incidents and rollbacks. Ship with a plan. • Practice blameless postmortems when things go wrong. Using AI sensibly • AI tools like GitHub Copilot or Amazon Q can speed drafts, suggest tests, and summarize diffs. • Treat AI output like a first draft. Verify logic, correctness, and product impact. • Don’t rely on AI for design decisions or security-sensitive code. When a review works well, you reduce bugs, speed delivery, and protect customers. When it goes wrong, it’s usually process, not people.  Fix the process. #coding #tips #tech #programming #softwareengineering #softwaredevelopment

Tired of arguing with your coworkers during #codereviews? Why not start a Team Working Agreement with your #softwaredevelopment team? A team working agreement sets the ground rules for your team and how they review code. You should discuss and document key things like: 1. How fast should reviews happen? Agree on an appropriate turnaround times for reviews and state that in your TWA. Also describe what can be done if someone isn't adhering to the turnaround times. 2. What's our limit on PRs? Define PR size limits: whether that's roughly the amount of lines changed or a maximum on the number of files to be reviewed, a guideline can help keep a #pullrequest small. And remember: Small PRs mean faster, more efficient reviews. 3. Are you allowed to self-approve? Handle self-approvals: Can authors approve their own PRs? If so, when and under what circumstances? Are you making sure this won't be abused? 4. Determine whether you'll allow nitpicks. While I strongly suggest taking nitpicks out of the review (because most are subjective or can be fixed before the review), state if you'll be allowed to bring up nitpicks in a review at all. If you do, be sure to use the "nitpick: or nit:" prefix and explain what should be considered a nitpick.  5. What's allowed to block a review? Clarify what can block a #PR from being approved (and ultimately, merged into prod): Security issues? Missing tests? Missing documentation? Readability? Something else? The clearer your team is about blocking vs non-blocking issues, the fewer your debates will be during the #codereview. By drafting your own Team Working Agreement, you can start to make reviews less painful and more productive. And remember, you can always revisit this document and make changes as your team evolves. Just make sure you discuss and agree to the changes as a team! Get a TWA template in my book: https://lnkd.in/dKwGg667 And follow (theLGTMBook to be a better #codereviewer! https://lnkd.in/gJaDvkEu

Senior engineers don't just write good code. They make everyone else's code better. 7 code review principles that raise the bar: 1. Review for learning, not just correctness The best code reviews teach. Both ways. → Explain the "why" behind your suggestions → Ask questions that make people think → Call out things you learned (praise good work) When reviews become teaching moments, your whole team gets better at engineering. 2. Stop debating style, start automating it Don't waste review cycles arguing about 2 spaces vs 4 spaces. → Use language-specific formatters → Enforce standards through CI, not human judgment → Save mental energy for architecture and logic Standards + automation = no more style bikeshedding. 3. Label risk levels and match scrutiny Use Risk: [HIGH], Risk: [MEDIUM], Risk: [LOW] in your PR titles. Not all changes are equal. A database schema update needs more review than a doc update. A typo fix shouldn't get the same scrutiny as a payment processing change. 4. Write detailed PR descriptions (AI makes this easy) Always explain: What is the change? Why is it needed? What should the reviewer focus on? → Use Claude Code to draft descriptions from your commits → Include screenshots for UI changes → Call out non-obvious implications or edge cases AI tools make this easier than ever. Embrace better tools to improve your quality bar. 5. Review the system, not just the diff After your first pass, zoom out: → How does this affect the broader architecture? → Does this introduce new patterns or follow existing ones? → What happens when this code needs to change again? The best reviews catch problems that won't surface for months. 6. Document recurring patterns Keep a living document or checklist of common review issues: → "We always forget to handle the empty state" → "Remember to validate input at API boundaries" → "Use our existing auth helper, don't write new ones" Turn repeated feedback into shared knowledge. 7. Use AI! (Seriously!!) Your role as a senior today isn't just writing code. It's ensuring your team uses the best possible tools available. That means AI code review tools like CodeRabbit. But here's the key: AI alone can't catch everything. Human judgment alone can't either. → AI catches syntax issues, potential bugs, and performance problems → Humans catch architectural decisions, business logic, and team context → Together you get comprehensive reviews without the tedium Don't let ego hold you back from tools that amplify your expertise. Good code review practicers help build teams that ships faster, learns quicker, and makes fewer mistakes over time. What advice would you give on code review? --- PS: I write a weekly newsletter on AI engineering you might like. It's free: https://lnkd.in/e7Ymdh_j. Found this useful? ♻️ Repost for your team and follow Owain Lewis for more

A common mistake of developers new to a "tech lead" role: trying to perform every code review. They're concerned that something will break if they don't. But reviewing every pull request isn't feasible, and doesn't scale. What to do instead? Here's what I've learned: 1️⃣ Enhance your delivery systems outside of code review. Strengthen your release pipelines with tests, monitoring and rollback. This will help to prevent, detect and mitigate defects. 2️⃣ Document code review processes. Team members should be aware of the expected size, scope and structure for each PR. Add automated checks for testing and approval. 3️⃣ Establish paradigms. Introduce design patterns and structure to the codebase, that others can leverage and build on top of. 4️⃣ Integrate automated tools. Use linters and formatters to ensure consistent style. Set up automated static code analysis. 5️⃣ Teach your team to review effectively. Emphasize the importance of kindness, clarity, and thoroughness. Identify when blocking is or isn't appropriate. 6️⃣ Be aware of what's going out. Slack/GitHub integration works well. Know when to scan a pull request, and when to do a thorough dive. You can't write and review all the code for your team. If you could, hiring others would be pointless. Instead: put your team in position to ship better software, faster. 🚢 #softwareengineering #codereview