Getting code reviews is the most difficult part to attain, ESPECIALLY on your own project. It would be easier to get code reviews if you contribute to open source by looking for issues in repos and attempting to solve them and submit a pull request. Open source pull requests almost definitely will get your code reviewed by the project owner if they are actively maintaining the project. It will also provide you with good github experience, which is also an important aspect that it is hard to get experience in as a sole developer. The hard part here is finding a repo and dedicating yourself enough to it so that you understand what is happening and what needs to happen in your particular issue request. Otherwise, as a general rule, when you are writing your code, think to yourself, if someone else who knows nothing about this were to come in and read it, would they be able to understand exactly what is going on (with each function, with folder structure, etc) and follow all clean code principals. Also, refactor your own code to make it cleaner just for practice.

On github - in your own projects you can get as much as experience as possible if you do this...

1. every time you add a new feature/bug fix, create a new branch. Follow a naming structure with your branches in a project. For instance, every branch maybe should be... feature/name_of_feature

2. Push that branch to github.

3. do a pull request from github.

4. merge from github.

5. go back to your project, go back to your master branch and pull the updated master code from github.

6. in vsCode - use git lens and always keep an eye on your gitgraph.

7. learn and use often, git stash, git stash pop when you want to save your work but don't want to commit yet.

8. when on a new branch, commit often with clear messages and when you are completely done...

9. use rebase, and squash so that all branches only have one commit before you push them to github.

10. the only other thing I use in github sometimes is cherry pick, but don't worry about that.

11. all other git commands you will learn along the way when needed, learn how to google for those things, no need to remember everything.

Even for rebase/squash, I have a document i created for myself when I first started to remember the process exactly, then just refer to it.

12. Create some merge conflics so you understand how to resolve them. This is sometimes hard to do as a sole developer, but happens a ton when working on teams.

Try to create documents on how to do everythign so that you don't need to remember ANYTHING other than how to find your resources!