Also, 100% on the change list description. I mentioned the same thing in a similar post[1] of mine.
[1] https://blog.mattchung.me/2020/11/09/3-tips-on-getting-eye-b...
Back when I was still in a project that did code reviews, it really helped for me.
Similarly / a tip: `git add -p`, to view and review your changes one at a time. You can split up changes into separate commits as well using that technique.
I spot things in `git add -p` that I had missed when writing the code in my IDE.
Then I spot more things in the github "Create PR" page that I missed in the previous step.
Then sometimes I spot more things in the created PR that I missed in the steps above.
Always skim back over your PRs, especially in the final context that they'll be reviewed in. Something about it puts you into "reviewer" mode and you'll get a better PR out of it.
> Hard agree.
Edit: Damn, I misunderstood both the GP and you. My apologies.
The implication here seems to be that one is only likely to be able to see 'trivial' mistakes in one's own work; that, unfortunately, tends to be a self-fulfilling prophesy, as, if you are focusing on issues like syntax, you are probably not giving so much attention to more analytic issues such as what implicit assumptions need to hold for the code to work. One thing, that is not uncommon in my experience, is for the early part of your work to be predicated on assumptions about what the as-yet unwritten parts will need or do, and some of these assumptions turn out to be wrong. There is some hope that, on revisiting the early work with an analytic eye, after completion if the remainder, you will see this to be so.
There are a couple of things that helped me improve how well I review my own work, both mentioned in the article: take a break between writing and reviewing, and don't make excuses (to yourself or publicly) or otherwise minimize problems found by the reviewer (the same goes for anything you found in testing.)
i realize now that i could help my reviewers by first submitting a PR to myself into the branch to be merged.
One way is imagining you want to explain it to a coworker or new hire.
I find it enormously useful, and it has become second nature for me.
When I'm stuck I now sometimes write down an imaginary question to someone, and usually the act of explaining my problem makes the solution clearer.