Unnecessary nitpicks that are holding Pull Requests for days/weeks are stressful though. Because they are holding a feature hostage to satisfy the ego of the commenter on an opinion that is subjective. It is especially unnerving when the commenter is dropping the nitpick and then disappears and never comments on the PR again, or only after months. I appreciate when the commenter clearly points out that this could be an optional change to slightly improve the code (or by opening a separate issue after merging).
When I get approval with no other feedback, I become deeply concerned. For non-trivial changes I let them soak in review for longer than necessary, until I'm unfamiliar enough with it than I feel confident reviewing my own code. I often find bugs this way.
My team sees code reviews as a way to lift the burden of responsibility from the person who wrote the code and share it evenly among the reviewers as well, so bugs that make it through code reviews belong as much to the reviewer as the author.
So I'm actually kind of stoked when a code review catches a bug in my code. They're often the exact kinds of edge casey corner cases that would've manifested as the kind of heisenbugs that lead to exactly those kinds of long days and late nights - but the code review caught it, so none of us will have to go through any of that over it. Yay!
Do I wish I hadn't made the bug in the first place? Sure. But to err is human - and statistics means this err will be you averaging X bugs a month, Y of which won't get caught before the code review, Z of which will get checked in when the code review doesn't catch them either. The goal isn't to have no bugs, it's to reduce X Y and Z until it's no longer cost effective to do so (which is at a very different point for NASA than it is for your website or app.)
I'm also acutely aware that when you've been staring at the same code too long, your brain starts replacing the code that's there with what the code "should" be, and you start missing the obvious right in front of you. Again - human nature. The solution is a second set of eyes from time to time. This isn't an excuse to be lazy or to avoid trying to improve, but it is a perfectly acceptable excuse not to beat yourself up when you've been putting in the effort, and still somehow missed the fact that you were assigning a reference to itself.
What's that? You want to be human too? I'll allow it!
I got used to the reveiws. Then I joined very small teams and I miss not having them.
If you look at it as a learning experience, you get other people to look at your code and give you helpful advice. If you have somewhat abrasive coworker, look at what they say not how they say it.
I played hockey with a guy who would just shut down whenever the play didn't go how he thought it should go. If someone didn't pass to him when he thought they should, he would just basically stop and give up as a result of the difference between his expectations and reality.
The key to getting over it is to not dwell on the work you've done in the past and just accept what is being given to you now.
If the code review comes back with bugs and you're getting stressed about it, you're probably still thinking about all the work you did in order to get to the point of committing it. Focusing on the feedback that came back from the code review and how you can implement it will help to get over the anxiety.
I'm writing a book - Programming Spiritually - that helps developers deal with stresses and issues in their work in a more holistic way. If you're interested in being notified on progress with the book you can check out https://leanpub.com/programming-spiritually
The issues I've seen re: code reviews are often due to a lack of emotional intelligence amongst developers who use reviews to promote their own ego or lack the experience to know how to craft their feedback in a cordial manner.
I do get embarrassed if I repeat a mistake and am really tough on myself in that aspect.
Linting definitely helps, setting up the IDE properly can catch things, in C/C++ running memory profilers etc.
I think people who are passionate about what they produce will always feel similarly. Caring about what you produce is important. It doesn't matter whether you just started coding or have been doing it for a couple of decades.
If it works, it has tests, and it is understandable, merge it ffs.
Other than that, for a while we tried the policy that if a commit you reviewed broke something, the reviewer had to fix it, not the committer. It doesn't really work though, as you might expect.
Edit: I should point out that I'm convinced the main benefit of code review is that your team knows what code you've worked on and what you've changed. Catching mistakes is a nice bonus, but this kind of information transfer is a huge productivity boon.
I've realized that I personally value code that works properly a lot more than any style/standard issues. I've tried to be very thorough in my own code reviews, reading it in its entirety and pointing out areas that look like actual causes for concern in terms of how the code behaves in hopes they'll do the same for me.
That said, most times I've had code reviews, it's more of a superficial rubber stamp. Probably been guilty of doing that too... not really as much fun reviewing code as writing it.
Also a second set of eyes just really helps sometimes. That said, it's also important that your reviewer is experienced enough that they can provide a substantial code review. I much prefer a critical eye to "looks good to me" every time.
The stress and burnout that results when code reviews aren't properly done and production is constantly on fire is _far_ worse than the alternative.
It's always good to get a good code review and get confidence than deploying buggy code to prod and worry what would happen tomorrow.
I would go so far as to say that your first and second paragraphs are antithetical.
I always try to give some positive review comments as well as just getting a list of negatives is grating.
It occasionally annoys me for a few seconds when someone will nitpick the style of the code, but I get over that quickly. Usually I just change it and move on.
> [...] only to find out you left it there on purpose as a take-it-upon-myself approach to checking your peers' competency.
This is never my goal. I don't send a review your way in the first place unless I think you're competent. But sometimes entirely competent people are overworked, distracted, a bit too trusting... it happens. It's human. It's fine! It's happens to all of us.
I just want to not check in broken shit.
It leads to long days and late nights. If you're overworked, it's just going to make things worse. This might involve me leaning on another reviewer more for a bit. This might be more closely scrutinizing my own code for a bit. This might be me offering to help take something off your plate if I think I can fit it onto mine. This might be a little friendly ribbing that helps you bring your focus back, if you're just a bit distracted.
Maybe you fancy yourself to be a rockstar?