A lot of my mentees are pointing out that self learners are being overlooked with bootcampers despite having a better range of projects in their portfolio. I am not too sure how true this is and one's portfolio is not the be all and end all, but I can think of one thing in particular that a bootcamp offers that is very hard to replicate when going down the self taught route.
One major benefit of bootcamps is you get the chance to work in groups, working with other developers is something that you will absolutely have to do and employers will definitely give a lot of weight to that experience that bootcampers have.
Working to a set of coding standards, discussing user stories, retro's, and git workflow (which is what this post focuses on) are all super valuable and all tough to replicate when developing solo.
The one of these that you can work on alone is git workflow. Just because you are not part of a team does not mean you should slack when it comes to a solid git workflow that will prepare you for the future workplace, so what does that look like?
When working as part of a team and you are assigned a ticket you will more often than not create a new branch and do your work there. So what should you do when working solo? Create a new branch and do your work there of course.
The goal while learning is to as closely replicate real world scenarios as you can, so yes you should be creating a branch and doing your work there. For example, let’s say you are adding authentication to your project you should create a branch called something like
feature/user-auth and add all your work here.
In the workplace when you are happy with your work and have tested it locally you will open a pull request and your work will generally be checked by one of your colleagues, so although you won’t get a code review (unless you have a kind mentor of course ;) ), you can still go through the motions of creating a pull request and merging it into your master, main or production branch.
What’s The Point?
Well, as I have said it gets you used to what you will be doing in the real world and more than that all of this branching, merging and pull requests will be living inside your repository history, there for anyone to see. So you can talk about your workflow and back it up with evidence, potential employers will be impressed you have taken this level of effort and seriousness to your side projects.
You can take this a little further if you like, here are a couple of other suggestions of things you can do to replicate some real world scenarios in your workflow:
Agile Planning - You may find yourself working in sprints or some other form of agile work. How about creating a Trello board for your projects full of user stories, mini sprints and even retro's and link this in your repository readme.
Github Issues - Alternatively open an issue on Github for bugs, features and any other user stories you may have, then create branches and pull requests which resolve said issues.
All of this may seem like overkill or pointless, but it is all about the image you are showing, you take your work seriously, act professionally and follow industry best practices. Who wouldn’t want to hire somebody like that?
Now go build stuff!