Update CODE_REVIEW.md

Author: neozenith

guides/CODE_REVIEW.md

@@ -5,17 +5,21 @@ There are **\*three types of Code Review** inspired by conference talks by Trish
 - https://www.youtube.com/watch?v=a9_0UUUNt-Y
 - https://www.youtube.com/watch?v=3pth05Rgr8U&t
 
-## Draft / Early Feedback
+## The Three Types
+
+### Draft / Early Feedback
 
 Github has a feature to mark a Pull Request as a draft. Often this won't run CI checks as it is known that it is in a partial working state.
 
 These are great to get early feedback about design decisions before sinking too much effort.
 
-## Educational
+### Educational
+
+Sometimes the person creating the Pull Request is the Subject Matter Expect (SME). 
 
-Sometimes the person creating the Pull Request is the Subject Matter Expect (SME) like a @newwwie/core-maintainers. They have authority to just push the change through, but it is important for others to see and follow along what the change _**IS**_ and _**WHY**_.
+They have authority to just push the change through, but it is important for others to see and follow along what the change _**IS**_ and _**WHY**_.
 
-## Goalkeeper
+### Goalkeeper
 
 This is probably the more common one that people think of when it comes to code review. They are looking at quality control and trying to stop bugs getting through.
 
@@ -29,3 +33,17 @@ Sometimes a solution isn't exactly how you would expect it to be solved, that is
 **Nitpicking should never block code getting released**.
 
 The regulating factor here is that if the code could not reasonably be maintained by someone else, then that is leaving tech debt and lowering the bar for the whole project.
+
+## Before Code Review
+
+Before requiring the valuable resource which is someone's attention there are some things you can do, (and yes your attention too is valuable, and I am grateful you have read this far 🫶).
+
+- Run code formatters
+- Run code linters
+- Run test suite
+- Add test coverage
+- Read your own PR as though someone gave it to you for review
+    - Does the code represent the pragmatically smallest amount of code changed to reach the outcome?
+    - Can you squash some of the commits together to better tell a story? Eg 17 commits down to 3 commits?
+    - Can you pre-emptively add comments on PRs to draw attention to the important parts?
+    - Have you added appropriate documentation so the next person can self-service contribute?