My first real pull request — not a one-line fix but a feature with actual logic — came back with 47 review comments. I remember staring at the screen and feeling physically sick, because in my mind 47 comments meant I had done 47 things wrong, which meant I was bad at my job, which meant I was going to be fired. That interpretation was wrong on every count, but it's the interpretation that most junior developers reach for, and it took me years to develop a healthier relationship with code review feedback.

The senior engineer who reviewed the PR pulled me aside the next day and explained something that I now tell every junior developer I work with: the number of comments on a PR is not a measure of the author's competence. Comments are the reviewer engaging with the code seriously enough to think about how it could be better, and a PR with many comments often means the reviewer thought the work was worth investing time in. A PR with zero comments is the one to worry about, because it usually means the reviewer skimmed it without engaging.

The most valuable comments on that first PR weren't about the code I wrote — they were about the code I didn't write. "Why didn't you extract this into a function?" "Did you consider what happens if the API returns an empty list?" "What's the reasoning behind this naming choice?" Those questions taught me that code review isn't just about catching bugs; it's about transferring the implicit knowledge that senior engineers have — the instincts about what to worry about, what to test, what to name things — to engineers who haven't developed those instincts yet. Every comment was a small lesson, and the 47 lessons I got from that PR taught me more than any tutorial I've ever read.