before I send a pull request for review
Mistakes happen, and they’re part of engineering. If someone suggests a better organization of files, a different function signature, or a better name for a variable, that’s nothing to hate myself for. Blindness to my own mistakes is also undeniable.
When I’ve worked on a ticket for a while, the tendency to get it over with and move on to something else becomes real. It becomes easy to glance over obvious things, and that results in sloppiness in pull requests. Sometimes, these mistakes make me cringe. Misspellings, test files, and random exits are some examples.
The following aims to address such blunders. This list exists so I catch that stuff before someone else does. Read before I press send.
- Did I leave a debug exit, a print statement, or a test file in this diff?
- Would I be embarrassed if my manager read the variable names out loud?
- Is there a magic number here that should be a constant?
- Could a custom exception replace this pile of if-statements?
- Can I explain, out loud, what every line in this diff does?
- Is this file where it belongs, Application, Domain, or Infrastructure?
- Did I leave a commented-out block I was too lazy to delete?
- Does the PR description say why I made this change, not just what changed?
- Is there a TODO I wrote at midnight that I'd be confused by tomorrow?
- Did I actually run this, or am I trusting that it works because it compiles?
- Did I rename something halfway and leave the old name in a comment or a docstring?
- If a reviewer asks "why not do X instead", do I already know my answer?
Pull requests don't need to be a piece of perfection. They'll always have room for improvement and that's what reviews are for. These checks show that I respect my craft and value other engineers' time.