Article summary
As a software developer, working alone can be very liberating. You can move at whatever speed you feel comfortable with. You have the freedom to explore ideas without having to explain or justify them to anyone else ahead of time.
You can twist and turn — speed up or slow down. The mere presence of another person (either pairing or working in parallel) can encourage us to move on a straighter path and at a steadier speed.
But while following your whims is fun, the end result can be a technical nightmare. Why? One person working alone doesn’t have pressure to produce something that’s readable or maintainable by anyone else.
The Pitfalls of Working Alone
A developer working alone will have a great deal of confidence in the system as a whole, since the whole thing was conceived in their head and implemented by their hands. This overconfidence can result in a lack of documentation or a lack of testing. If documentation is intended for others, and a developer has reason to believe there will never be any others, then why maintain documentation?
A similar attitude can shape how automated tests are written (if they even are). I’ve seen some instances where very introspective solo developers wrote tests to cover situations they felt they personally were likely to mess up in the future. It’s certainly better than nothing, but stuff like that will have to be scrapped if other people are ever brought onto the project. So many proof-of-concept applications and prototypes have to be completely thrown out and rewritten from scratch because the author realizes they might have a successful idea.
The biggest issue is with the code that gets produced. When we are heads down on a problem, we can write code that’s confusing to anyone who didn’t go on the same mental journey we did while trying to solve it. Think about all the times you’ve had to explain some weird idiosyncrasy in one of your pull requests, and then imagine an entire code base full of them. If you don’t ever have anyone looking at the code you’re writing, no one is ever going to point out the weird stuff that you can’t see.
This is especially problematic with subject matter experts, who can produce code that makes perfect sense to them but is incomprehensible to everyone else.
How to Develop Alone
Being disciplined about following a few software engineering principles from the beginning of any solo project can help make your life easier down the road if you ever find yourself needing to onboard anyone else to your project. Outside of being disciplined about maintaining good documentation and testing, there are a few habits you can get into to help solve some of these problems.
1. Write Thoughtful Tests
If you do automated testing, have the right focus. You don’t have to shoot for an enterprise-grade test suite, but remember: the better your test suite, the easier it is to make changes later. Writing tests to cover your personal development deficiencies might seem logical when you’re working solo. But it’s actually the opposite of what you want to do.
Instead of trying to code guard rails for yourself, put yourself in the shoes of other developers who don’t have the context you have. Think about edge cases that might seem obvious to you but wouldn’t be to others. If you find yourself writing an idiosyncratic piece of code, write a test that documents why you had to do it in the first place.
2. Review Your Own Code
Getting a code review from yourself a month from now is almost as good as getting a code review from someone else. Make it a habit to go back and review your own code after a certain amount of time has passed. Temporal distance tends to cure the myopia that can produce convoluted code.
When you’re heads down and focusing on one area of the code, it’s too easy to lose focus on the big picture and write something that makes sense at the time, but isn’t going to be clear to others or even to yourself once you’ve moved on to something else. If you make reviewing your own code a regular practice, you will be surprised how much you can clean up long after the fact.
3. Keep a List of Weird Stuff
Always have a running list of all of the “weird stuff” in your app. If you do something quick and dirty because it’s expedient, write it down somewhere so you can come back and fix it. If you need to research a better way to do something, write that down too. (And when you’re in the mood for some refactoring, grab something off the list and fix it.)
The things on this list are exactly the things that outsiders might ask you about someday. Having this list reminds you that they exist, and it also helps you answer the question, “Was it done this way on purpose, or can we fix it?”
If you need to onboard people to your codebase, these types of issues can also be assigned to help start orienting people to the code. Since you’re intimately familiar with the problem, you can provide enough direction to get someone started, and also provide a lot of useful context for why it was done that way in the first place.
The main thing to remember is to try and find ways to force yourself to take a step back and look at the bigger picture from time to time. If you can’t get other people’s perspectives on your code as you’re writing it, try to look at it yourself with a different perspective once you’ve gotten some distance from it, and constantly ask yourself if what you’re doing might seem unusual, and if it does take a note.
Keeping a handle on things this way will help keep your code cleaner and more understandable to outsiders, should you ever need them.