A software engineering fundamental I've always been bad at is PR reviews. Not out of laziness, not for lack of team spirit. I just struggle with them, and always have.
I can trace the reasons back to a few things. A lack of experience reviewing other developers' work, insecurity in my own opinions that has followed me throughout my career, and a seniority bias that leaves me feeling underqualified to review almost anyone.
For most of my career I worked in contexts without a solid review culture. Often I was the only developer, or part of a team small enough that reviews were just the team lead checking that critical features matched the spec. Nothing more structured than that.
Reviewing code is a skill, and like any skill it needs training. You have to filter out the noise and identify the core of the feature first, then build context outward from there. Once the happy path is covered, you need to understand the feature and the surrounding code well enough to stress-test it, to probe the edge cases until the weak points surface. It's a kind of craft, and it takes time and patience to sharpen. I'm learning that firsthand right now.
The trouble is that I'm not a naturally confident person. I doubt myself constantly, assume my opinion probably isn't the right one, and give a lot of weight to other people's perspectives. I'm empathetic by default, always trying to understand the reasoning and the context behind a decision.
That instinct doesn't serve me well when reviewing code. I start second-guessing my own observations and go blind to real issues, assuming that if the developer built it this way, there must be a good reason. Who am I to challenge it? I should be learning from it instead. Which is, of course, wrong. Fresh eyes routinely catch things the author can no longer see after living inside a feature for too long. Sometimes you bring a perspective or an area of expertise they simply didn't have. Learning from PRs is valuable, but you have to separate matters of opinion from actual bugs. And when in doubt, just ask.
Asking and debating gets harder when you're reviewing seniors or developers you genuinely admire. The bias is obvious, you assume their position must be the correct one and that your role is only to learn. That's understandable, but the underlying principle still holds. An outside perspective can outweigh seniority. The only extra care worth taking is thinking things through a little more thoroughly, because some implementations look like mistakes but are actually deliberate. Those moments, untangling why something was done a certain way, are some of the best ways to learn a new codebase.
You might wonder why I'm agonising over something like PR reviews. Isn't AI about to replace human review entirely, freeing us to vibe-code our way through every ticket? I don't think so. Not the way I see it, anyway.
At my company we run a hybrid setup: human peer review, ideally cross-team, alongside a custom AI agent embedded in our CI pipeline that catches a lot before it reaches us. And right now, I'd argue the value of PR review is higher than it's ever been. Code generation is accelerating exponentially. The speed is staggering, and the natural tendency is to sit with a feature less before committing it. That makes review one of the last real gates between production and AI slop.
Maybe one day the automated review will be good enough to make the human check redundant. But for now, it's where the knowledge, the judgment, the sense of how things should actually be done still gets enforced.
If you made it this far, thank you. Now go back to Slack and be a good teammate. Pick up a PR that needs reviewing, check the diffs, check out the branch, and dig into it properly. Those approvals shouldn't be given lightly.