Review your code
When you review your own code, you are in a different state of mind compared to when you read the comments from other reviewers. In that state of mind, you will take (your own) criticism more easily and immediately switch to thinking of improvements.
Some of the noticable benefits are:
-
identifying a pattern of your common mistakes. That will build a subconscious recognition of these patterns so to identify them later right after or even before you repeat them and eventually to erase them from your coding output.
-
making other reviewers lives easier by answering obvious question(s) and leaving short comments on some major point(s) of concern. You may even leave some summaries (very helpful) on lengthy boring changes where the main reason might not be easily identifiable following the detailed changes.
Two general rules
What I find help keep a beneficial self-review habit are these two general rules:
-
disconnect before you come back later to review your work. How long depends on the changes, but generally speaking long enough that your brain is not still actually working on it, though not too long to require much effort to get back to it’s context.
e.g. for a small bug fixe, it could be just leaving the screen for couple of minutes (great chance for quick socialization ;) while for a big feature that took for 1–2 days of work, you’ll need to switch to another task for another (half a) day.
-
double check key changes only. Otherwise it turn into an infinite loop of “perfection”, and worst it might make you introduce more unnecessary changes or “refinements”.
e.g. for a software change that introduces new concepts in the solution/domain, double checking these concepts comprehensibility and durability might be a good, but probably not naming conventions and code style (which you should be automating by now). While for a bug fix, double checking the side-effects of that fix, if any were introduced, might be enough.