[littlestymaar]

Review your own code before asking for somebody else to review it.

My personal routine: before pushing code on the repo, run git rebase -i, review all your commits and change them if anything looks wrong (the commit message, some random crap being mixed with the actual content of your commit, silly mistakes, etc.). It will cost you around 2 minutes per commit maximum, and your pull request's quality will increase dramatically.

Also, git add -p when committing to review your work as soon as possible.

[benignslime]

This is great advice in general. Git is one of the best tools to help you organize your thoughts into digestible chunks, and a skill that I've consistently found to correlate with poor code at review time. One of the things that always enabled me to write high-quality documentation or reports is the constant review. Re-read each paragraph as you write them, iterate while your mind is on topic. If you write it lazily the first time, and never go back until you wish to review the entire feature, you may have already destroyed your time and effectiveness of your implementation.

It's a little difficult to give OP advice on their situation when it's unknown what product or workflow they're in. I've always found that if I'm taking too long testing or debugging, it might be a problem with the projects toolchain. If developers don't put in the time to make their projects testable and debuggable, those man hours will be eaten up over time.