When I was the only guy in my team writing code, I found it helpful to put a bit of processes - like having a threshold of test coverage, and running some kind of analysis (flake-8, for example) on my codebase. Another thing I did was letting one of my friends look at a random piece of code in my codebase. He would suggest changes, but what helped more was that I wrote code more consciously than I would if I did it all alone.

You could switch to working on some other component and then come back after a few days - I find that length of time often makes me fairly critical of my own code!

Go through the motions of reviewing your own code separately from writing it. IOW, have a code review tool such as Github or Gerrit and create a PR or change request. Then review your code similar to how you might proof read a paper. I find just the change of mindset and looking at the code in a different context (the diffs in a browser window instead of the code in your editor) helps me to catch mistakes.

I usually do this for changes before I have someone else review them anyway. Of course ideally someone else could review the change but if you don’t have someone you don’t have someone.

The main limitation here is that while this should help you with bugs, it’s not good for catching things which aren’t idiomatic or having someone point out a better way to do something.

But it’s better than nothing.

You could try posting the snippets you need peer reviewed here on code review stack exchange - https://codereview.stackexchange.com

I recently came across https://www.pullrequest.com and have heard good things about them.

Add a good static analysis tool such as SonarQube to your continuous integration pipeline. It isn't really a substitute for human code reviews but it can quickly catch a lot of common problems.