Technical debt is expensive, but 'Social Debt'—broken trust and poor communication—is far more damaging to a project's success.
1The Ego-Less Engineer
You are not your code. When someone finds a bug in your Pull Request, it's not a personal failure; it's the system working. Mid-level devs welcome critiques as a way to ensure production stability.
2Code Review Etiquette
A good reviewer points out what's done WELL, not just what's wrong. Positive reinforcement builds a culture of excellence and makes the 'red ink' of fixes much easier to swallow.
3Impact over Activity
Being 'Senior-leaning' means identifying bottlenecks for the whole team. If you see a teammate struggling, spending 30 minutes to unblock them is often more valuable than writing 100 lines of your own code.
4Step-by-Step Breakdown
Coding is a team sport. At a mid-level, your 'Impact' is measured by how much you help your team succeed, not just how many tickets you close.
Code reviews aren't an interrogation; they're a learning opportunity. High-quality reviews focus on readability, maintainability, and security while maintaining a respectful tone.
Constructive feedback is a gift. Being able to give and receive critiques without taking it personally is the hallmark of a mature professional engineer.
You must be a 'Translator'. Can you explain a complex technical trade-off to a Product Manager without using jargon? This bridge-building is a vital mid-level skill.
In a Code Review, what is the best way to suggest a change to a teammate's code?
- →Use imperative commands like 'Change this line immediately'
- →Ask curious questions or provide rationale, e.g., 'What do you think about using a Map here for O(1) lookups?'
- →Just fix it yourself and push the changes without telling them
- →Don't say anything to avoid hurting their feelings
Why is 'Active Listening' important during a technical planning meeting?
- →So you can find flaws in everyone else's ideas
- →To ensure you fully understand the requirements and perspectives of other departments (Design, QA, PMs)
- →So you can look busy while thinking about your own code
- →To memorize exactly what your manager says so you can repeat it later
Level Up 🚀
Advanced cheat sheets, SEO tricks, and interview prep for this topic.
Browser Support
Fully supported.
Fully supported.
Fully supported.
Fully supported.
Accessibility (A11y)
1Inclusive Communication Practices
Async, text-first communication (written PR descriptions, RFCs, meeting notes) is more accessible than sync-only culture — it accommodates non-native speakers, different time zones, and anyone who processes written text better than live speech.
// Example: a PR description template
## What & Why
## How to test
## Screenshots (if UI)SEO Implications
- 1
Discoverable Documentation Compounds
Well-titled PR descriptions, ADRs (Architecture Decision Records), and wiki pages act like an internal search index — future teammates (including future you) find prior decisions through search rather than re-litigating them in a meeting or rebuilding something that already exists.
Best Practices
Write the 'Why', Not Just the 'What'
A PR description that only restates the diff wastes the reviewer's time. Explain the tradeoffs you considered and why you picked this approach — it turns a review into a conversation instead of a rubber stamp.
Default to Public, Async Channels
Ask questions in the team channel instead of DMs when possible. It lets teammates in other time zones find the answer later without re-asking, and lets more senior engineers jump in before you're blocked for a day.
Frequent Bugs
A reviewer leaves a dozen nitpick comments on style and formatting but says nothing about the actual logic, so a real bug ships while the PR 'looks' thoroughly reviewed.
Automate style and formatting with a linter/formatter in CI so humans can spend review time on logic, edge cases, and architecture instead of semicolons.
Real-World Examples
Blameless Incident Postmortem
A junior engineer's deploy causes a 20-minute outage. Instead of assigning blame, the team runs a postmortem focused on the systemic gap (no staging alert, no rollback runbook) that let the mistake reach production.
// Postmortem template
## Timeline
## Impact
## Root cause (systemic, not personal)
## Action items with owners