<-- home

The difficulties of working a project solo

Working alone on a project is difficult, whether or not it’s for work or for yourself. When you’re working on a personal side project, it can be difficult to motivate yourself, but if you’re working alone on something professionally, the challenges you deal with are even more tricky.

When you write code for a personal project, it’s common that you’re writing this code for your own personal gain. For example, last night I downloaded an open source NodeJS/Redis chat application because I want to learn about NodeJS a little bit. The mistakes that you make, the code debt you build up, the bugs you don’t fix, they’re all things that really only you know about. Sharing your work is difficult, and this is especially true when you take pride in the work that you do.

When you write code professionally, you (ideally) don’t get a choice in having your work seen by others. Be it coworkers that might work in the same code or have to review your code, or it’s just the customers and users that are actually using the product that you’ve created. Either way, your work is no longer kept in your little hole. It’s graduated into the public ecosystem and that’s terrifying.

If you are alone on a professional project, this makes things potentially more terrifying, but I’m trying to break this mentality with a few techniques. In my current position, I’m the only developer working on my specific project. For many developers this is the dream. They don’t have to deal with other peoples’ code and deal with their code styling. You know every part of the code base so you don’t feel left out. Your productivity is unmatched at point as an individual because it’s just you working on this thing. There’s plenty of reasons that I love being a solo developer, but it’s not all rainbows.

One of the things that makes this difficult is that you don’t really have anyone to bounce ideas off of. You can’t chat with someone about whether or not they think my approach makes sense. There’s nobody reviewing my code to give me feedback which would help me improve overall. It’s easy to write code that you can understand, but that’s because you wrote it with all of the context in your own mind. How do you know that the code makes sense for someone else who might work on the code base? What happens if we get a second Android developer, or if I move on to work on a different project? One way to combat this is to regularly give yourself code reviews. I don’t have a lot of time to do this, but if I really like doing this when I revisit code that I might not have seen in a few weeks. After all, give yourself a few weeks and it’s like a whole new code base anyways. Some key things to pay attention to is how quickly can I get started in modifying the code, as well as how brittle/fragile is it?

If I can easily understand code that I haven’t looked at in months, then that’s a great sign of it being well written. It means that I took the time to make sure that the code was a clear representation of the logic that needed to occur. I once read a quote about beautiful code that went something like: “Code should look like the language you wrote it in was in itself created to solve your problem”. Just think about that. The code should look like this language was specialized just for you. If your code reads that well, you’re doing a great job.

If the code that I change is written well, then it should be easy for me to make modifications. If your code is tightly coupled and highly dependent on itself, then when you make changes, a lot of things can go wrong. Your code should have logical expectations of input, and have sensical outputs. Structuring your code like this doesn’t belong to any specific paradigm, but I recommend that you watch Jessica Kerr’s talk, Functional Principles for Object Oriented Development. It’s common in OOP to want to hide your data, or keep state hidden, but in functional programming, declarative functions are endorsed. I bring this up because code that is written to be very declarative is often very easy to modify as well. If your code has a very obvious and clear set of dependencies, then modifying it becomes much easier. You don’t have to go and find all of the hidden state that you might be affecting.

Another difficulty when working solo is that you’re the entire team. There isn’t a DevOps team waiting to help you, and there isn’t QA to help you test for bugs before you release something to your users. In order to keep yourself sane, make sure to invest in proper tooling and infrastructure. For example, make sure that you have a really robust logging system. When a bug occurs, your logging should be so explicit that as soon as you read the crash report, you know exactly what to do. Really, just listen to everything in the episode of Software Engineering Daily called Application Crash Monitoring with James Smith. Together they go through a lot about crash monitoring and it’s been really useful to me. With that being said, do yourself a favor and listen to The Art of Monitoring with James Turnbull as well. It’s another podcast episode with great thoughts and advice on monitoring. When you leverage data to drive your development, it’s as if you have a team mate that’s there helping you diagnose bugs.

None of these tips or considerations are exclusive to being a solo developer, but I feel like without the pressures of knowing that someone else will look at your code, it becomes a lot easier for someone to let them slip. Just remember to be systematic, mindful, and aware of the code you write, even if there isn’t someone there to do it for.