Chapter 6.4 — Stash Pop, Branch Switch & Restore☕ 12 min read

Code Review Culture

Review the code, not the coder. Egos chote, code better.

01Stash Ko Wapas Laao (Pop)

Code review is NOT just finding bugs. It is knowledge sharing, mentoring, and maintaining team standards. If the only thing your reviews catch is typos, you are doing it wrong.

Benefits of code review: catches bugs before production, ensures consistency, spreads knowledge across the team, and documents design decisions. Every review is a teaching moment.

Without review: code becomes siloed. Only one person understands each module. That person goes on vacation — your team is stuck.

With review: at least 2 people understand every line of code. The bus factor improves. Knowledge spreads organically.

Review is a conversation, not a courtroom. The goal is better code, not proving who is right. Ask questions, suggest alternatives, share context.

Automate what you can: let linters catch style issues, let humans review LOGIC and ARCHITECTURE. If you are spending review time on missing semicolons, your tooling is broken.

# What code review catches:
# ✅ Logic errors and edge cases
# ✅ Security vulnerabilities
# ✅ Performance issues
# ✅ Missing tests
# ✅ Unclear naming
# ✅ Architecture concerns

# What code review should NOT catch (automate these):
# ❌ Formatting (use Prettier)
# ❌ Linting errors (use ESLint)
# ❌ Type errors (use TypeScript)
# ❌ Test execution (use CI)
# ❌ Import order (use tooling)

# Rule: If a computer can check it, a computer SHOULD check it.
# Humans review what computers cannot: design, logic, and readability.

02Switch Branches with Stash

Using prefixes makes review intent clear and reduces friction. Without prefixes, "This is wrong" feels aggressive. With prefixes, "suggestion: this might be cleaner" feels collaborative.

nit: — minor style/preference issue, not blocking. nit: could use optional chaining here

suggestion: — a better approach, but your way works too. suggestion: consider extracting this into a utility

blocker: — must fix before merging. Bug, security issue, wrong logic. blocker: SQL injection vulnerability

question: — asking for clarification, not suggesting change. question: why this approach over X?

Prefixes transform review from confrontation into collaboration. The author knows exactly what is a suggestion versus a requirement.

## Good Review Comments

nit: Minor formatting preference, not blocking.
"nit: prefer single quotes here for consistency"

suggestion: A potentially better approach.
"suggestion: consider using a Map instead of an object for O(1) lookups"

blocker: Must fix before merge.
"blocker: this API call doesn't handle the error case, could crash the app"

question: Seeking understanding.
"question: what happens if the user is not authenticated at this point?"

## Bad Review Comments
"This is wrong" → Aggressive, no explanation
"Change this" → No reason given
"LGTM" → Didn't actually review
"Rewrite this whole thing" → Vague and unhelpful

💡 Pro Tip: Every blocker comment should explain WHY it is a problem and suggest HOW to fix it. A blocker without a solution is just criticism.

blocker: this query is vulnerable to SQL injection. Use parameterized queries like: db.query(INSERT INTO users VALUES (?), [name])

— this is helpful, specific, and actionable.

03Stash Drop & Clear

Review within 24 hours. A PR waiting 3 days blocks the entire team momentum. Fast reviews mean fast merges, and fast merges mean fast delivery.

Be kind, not condescending. Explain WHY, not just "this is wrong". The goal is understanding, not compliance.

Distinguish blocking issues from preferences. Do not block a PR on a nit. If it compiles, passes tests, and has no bugs — approve it.

Suggest alternatives, do not just criticize. "This works, but consider X because Y" is infinitely more helpful than "This is bad".

Do not surprise-block. If you see a concern, comment early even in draft PRs. Do not wait until the author thinks they are done.

Acknowledge good code. "This is a clean solution, nice use of the strategy pattern!" Positive feedback reinforces good practices.

Review the code, not the coder. "This function is confusing" is about the code. "You write confusing code" is about the person. Never make it personal.

# Reviewer workflow
# 1. Read the PR description first (understand context)
# 2. Review the "Files changed" tab (read every line)
# 3. Check out the branch locally if logic is complex
git fetch origin
git checkout feature-branch
# Run the code, test it

# 4. Leave structured comments with prefixes
# 5. Approve or request changes
gh pr review 42 --approve -b "Looks good! Just the nits above."
gh pr review 42 --request-changes -b "Please address the blocker above."

# 6. Follow up promptly on revised PRs
# Don't make the author wait another 2 days for a re-review

04Partial Restore from Stash

Your code is NOT you. Feedback on code is not feedback on your worth. A comment on a function is not a comment on your intelligence.

Respond to EVERY comment. Even a simple "Done" or "Good point, fixed in abc123" shows you respect the reviewer time.

If you disagree, explain why. Do not just ignore the comment. "I considered that approach, but it would break X because Y" opens a dialogue.

Make requested changes or explain why you chose a different approach. Silence is not an answer. Engage with the feedback.

Re-request review after making changes. Do not assume the reviewer will check back. Make it explicit.

Do not push new commits after approval without asking. The reviewer approved the code they saw. Changing it silently breaks trust.

Thank your reviewers. They spent their time improving YOUR code. A simple "Thanks for the thorough review" goes a long way.

# Author workflow
# 1. Self-review before requesting reviewers
# 2. Create PR with clear description
# 3. When review comes in, address each comment:
# - Agree? Fix it, push, comment "Fixed in abc123"
# - Disagree? Explain why respectfully
#   "I considered that approach, but it would break X because Y"
# - Unsure? Ask for clarification
#   "Can you elaborate? I'm not sure how that would work here"

# 4. Push fixes
git commit -m "refactor: address review feedback"
git push origin feature

# 5. Re-request review
gh pr edit 42 --add-reviewer original-reviewer

# 6. After merge, thank the reviewer
# "Thanks for the thorough review! Caught some good edge cases."

05Apply vs Pop — Kab Kya Use Karein

Humans should review logic, architecture, and readability — not formatting or linting. Every minute a human spends pointing out a missing semicolon is a minute wasted.

Set up CI checks that run on every PR: linter, formatter, tests, type checks. If CI fails, do not review. Let the author fix CI first.

GitHub required status checks: Settings → Branches → Require status checks to pass. PRs cannot be merged until CI passes.

Pre-commit hooks (Husky + lint-staged) catch issues before they even reach the PR. Fix problems at the earliest possible stage.

CODEOWNERS file automatically assigns reviewers for specific paths. Database changes get the DBA. Auth changes get the security team. No more guessing who should review.

# CODEOWNERS: auto-assign reviewers
cat > .github/CODEOWNERS << 'EOF'
# Global owners
* @team-lead @senior-dev

# Frontend code needs frontend team review
/src/components/ @frontend-team

# Database changes need DBA review
/src/migrations/ @dba-team

# Security-sensitive code needs security review
/src/auth/ @security-team
EOF

# Required CI checks on GitHub
# .github/workflows/ci.yml runs on every PR
# Settings → Branches → main → Require status checks:
# ✅ lint
# ✅ test
# ✅ type-check
# ✅ build

# Now PRs cannot be merged until CI passes
# Reviewers only see code that already passes automated checks

The best code review culture has one rule: review code within 24 hours, and never block on a preference. If you find yourself debating semicolons vs no-semicolons in a PR, that is a linter problem, not a review problem. Automate style decisions and free humans to focus on what matters: is this code correct, secure, and maintainable?

Lo kar liya — Key Points:

✅ Code review is for knowledge sharing and quality, not just finding bugs or proving superiority
✅ Use comment prefixes: nit (minor), suggestion (better approach), blocker (must fix), question (clarification)
✅ Review within 24 hours — blocked PRs kill team velocity
✅ Authors: don't take feedback personally, respond to every comment, re-request review
✅ Automate style/linting with CI and pre-commit hooks; humans should review logic and architecture
✅ Use CODEOWNERS to automatically assign the right reviewers for specific paths
✅ Always review code, not the coder — attack problems, not people

Previous6.3 — Stash Push & Save 📋 All Chapters Next Chapter6.5 — Stash Untracked & Including All →