Devs: Review your own PRs
You might think you already know that all your code is perfect (you wrote it after all) but it pays to review your own pull requests before anyone else does.
Creating a merge request feels kind of like shutting the screen of your laptop at the end of the day. You've worked hard and now you're finally almost done, just one more small step before you can relax...
I'm afraid that I'm here to advise you to add one extra step to your dev workflow - reviewing your own PRs.
It's a fact of life that no one is perfect. Although I'm sure your code is of the upmost quality, it pays to take a last quick scan before you let anyone else look at it - even if it's just to prevent the embarrassment of that forgotten console.log().
It's surprising to me the number of devs I've worked with who don't do this as standard. Imagine the amount of time it would save if all those small errors were caught early.
I've lost count of the number of times I've read my own code back in Gitlab and thought 'Actually, this could be better.' Usually I just notice something small like a variable I could inline or a missing type hint (PHP dev problems). But there have also been times where I've decided to do complete refactors of bits of code. And thanks to the existence of git rebase -i no one even has to know!
A PR gives you a great, succinct overview of what you've written. It allows you to see a concise big picture of your feature without allowing you to become mired in the gritty details. This is then the perfect time to look at your solution and consider if it's the best it can be. What would you comment on if the PR was from one of your colleagues?
Self-reflection is a valuable skill, perhaps one of the most valuable, and for a dev a pull request is in my opinion the best moment to practise it.