Working in a team is great. You can progress really fast and learn a lot from your colleagues. Having another set of eyes to proof check your work is a godsend because it can prevent silly things being deployed to production.
But, sometimes, life happens and you have to work alone on a project. Be it a specific technology, budget reasons or something entirely else, it doesn’t really matter. Working alone doesn’t mean it’ll suck or be really stressful if you keep yourself in check.
I worked on a couple of projects as a solo frontend developer, but I rarely had the feeling like I couldn’t do it or that I maybe didn’t learn as much as I could have. If you “act” like there is a whole team involved (or that someone new will be joining you on the project), that can force you not to take shortcuts and do everything properly.
It’s really easy to skip a couple of steps when working alone because, honestly, is anyone going to notice? The answer should be yes, you’ll notice it!
Opening a pull request that will be merged to master immediately might seem illogical, but having everything consistent will surely help you out in the long run. On top of that, you might notice something wrong when you’re doing a once-over.
Keeping your code neat is something you also shouldn’t skimp out on. Linters, prettiers and everything else should be setup as if you were in a team!
Writing tests is a no-brainer. It’s always a great relief knowing that stuff works even after a refactor. Not having to constantly think about that will allow you to focus on more important things! That shouldn’t change even if you’re working alone.
It might be boring, but if you don’t do it, nobody will. At a first glance, it doesn’t seem important since you’re the only one that will be reading it. I can tell you that I know for a fact that the future you will thank you for it. It’s unrealistic to expect you’ll remember every little detail, even though you’ve written everything yourself. Having a good documentation means that some of the mental burden can be relieved because you can refer to it at any time.
Heck, something might even change within the project and your new teammate will be even faster with the onboarding.
I have the benefit that there are other brilliant teammates on other projects. They might not know the domain of my project, but they can offer technical help if you explain it to them. Try to make it easy for them to understand it, and I’m sure that you’ll get new insights. The same goes for asking for help online. Just because you’re alone on the project doesn’t mean that you have to do everything by yourself.
If you have work colleagues, it’s not a bad idea to assign them on a pull request once in a while. You might be surprised how tunnel-visioned you can get!
If there’s a backend, I’m sure you can discuss domain issues with them, as well. They probably know a lot and it’s a good idea to double-check with them. You might learn about something you weren’t aware of!
Now that you’re alone on the project, you can do anything to improve your development experience. If there is a task that needs to be automated, why wouldn’t you automate it? If you can get the budget for it, you’ll save time and you’ll learn something new. This is a great opportunity to make up for not learning from your teammates. Something that a senior colleague always set up can now be done by you. It might seem daunting if it’s out of your comfort zone, but hey, how else are you going to learn?
From personal experience, these situations taught me some skills I would rarely have the time to research in other projects.
By sticking to these tips, I’ve been able to maximise my learning and do quality work as much as I could. Not having a teammate doesn’t mean that you really have to be isolated from everything else. And, who knows, you might even get someone working on a project by your side so you want to be proud of what you’re capable of doing all on your own, right?