5 ms·

Nice post. I agree with almost all of the author's points. However, I would add that "reviewing one's own code" is more difficult than it may appears. It's like

Nice post. I agree with almost all of the author's points. However, I would add that "reviewing one's own code" is more difficult than it may appears. It's like reviewing your own prose, one develops blind spots. That being said, combing through your own CR for trivial mistakes is just due diligence. 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-balls-on-your-code-review/ https://blog.mattchung.me/2020/11/09/3-tips-on-getting-eye-b...

Cthulhu_ 6y ago
While true, sitting down and reading your code in the review tool as opposed to your editor or git client does help; shifting your mindset from author to reviewer also helps. 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.
- mumblemumble 6y ago
  This is what I do. Even that small change in perspective is often enough for me to catch quite a few stylistic or functional problems two which I was completely oblivious when looking at the code in the IDE. Even in the IDE's own diff viewer.
- syncsynchalt 6y ago
  Hard agree. 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.
  - angrais 6y ago
    What you've described indicates that while you may not agree, reviewing your own code helps identify issues.
    - scott_s 6y ago
      I think you misread what they wrote: > Hard agree.
      - angrais 6y ago
        But then they described agreement? Edit: Damn, I misunderstood both the GP and you. My apologies.
p5a0u9l 6y ago
i will often read through my changes in the browser UI in a similar manner as my reviewers. more often than not, that change of perspective will highlight something silly i missed. i realize now that i could help my reviewers by first submitting a PR to myself into the branch to be merged.
- syncsynchalt 6y ago
  If you're on Github (or Github Enterprise) look for the "Create Draft PR" feature (it's in the button dropdown for the final "Create PR" step)
- Izkata 6y ago
  Fisheye/Crucible lets you view the code review before hitting "start review" to publish it to everyone else; I also give my reviews a look over in that context before publishing for the same reason, it makes anything odd stick out more because it's not the UI I've been looking at.
mannykannot 6y ago
Naturally; if self-review were as effective as peer-review, we need not do the latter! 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.)
BurningFrog 6y ago
I've developed the habit of trying to look at my code (or UI) as if I had never seen it before. You can think of it as an empathy exercise. 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.
- guytv 6y ago
  ... just like you explain it to a... rubber duck? https://en.wikipedia.org/wiki/Rubber_duck_debugging https://en.wikipedia.org/wiki/Rubber_duck_debugging
  - BurningFrog 6y ago
    A bit like that, yes! 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.

Cthulhu_ 6y ago

While true, sitting down and reading your code in the review tool as opposed to your editor or git client does help; shifting your mindset from author to reviewer also helps. 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.

mumblemumble 6y ago
This is what I do. Even that small change in perspective is often enough for me to catch quite a few stylistic or functional problems two which I was completely oblivious when looking at the code in the IDE. Even in the IDE's own diff viewer.
syncsynchalt 6y ago
Hard agree. 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.
- angrais 6y ago
  What you've described indicates that while you may not agree, reviewing your own code helps identify issues.
  - scott_s 6y ago
    I think you misread what they wrote: > Hard agree.
    - angrais 6y ago
      But then they described agreement? Edit: Damn, I misunderstood both the GP and you. My apologies.

p5a0u9l 6y ago

i will often read through my changes in the browser UI in a similar manner as my reviewers. more often than not, that change of perspective will highlight something silly i missed. i realize now that i could help my reviewers by first submitting a PR to myself into the branch to be merged.

syncsynchalt 6y ago
If you're on Github (or Github Enterprise) look for the "Create Draft PR" feature (it's in the button dropdown for the final "Create PR" step)
Izkata 6y ago
Fisheye/Crucible lets you view the code review before hitting "start review" to publish it to everyone else; I also give my reviews a look over in that context before publishing for the same reason, it makes anything odd stick out more because it's not the UI I've been looking at.

mannykannot 6y ago

Naturally; if self-review were as effective as peer-review, we need not do the latter! 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.)

BurningFrog 6y ago

I've developed the habit of trying to look at my code (or UI) as if I had never seen it before. You can think of it as an empathy exercise. 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.

guytv 6y ago
... just like you explain it to a... rubber duck? https://en.wikipedia.org/wiki/Rubber_duck_debugging https://en.wikipedia.org/wiki/Rubber_duck_debugging
- BurningFrog 6y ago
  A bit like that, yes! 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.