I’ve worked as a solo web developer for the last three years and as time has passed I’ve had to find ways to fill in the partner-sized gap that exists in my regular team. Not having someone else around working on the same project or possessing similar skill sets or responsibilities means my code ships without peer review and lacks perspectives beyond my own. This makes the code less resilient and prone to errors or laziness. These and other reasons are cited in arguments that solo development should be considered an anti-pattern.

In a partner’s absence I’ve instead turned to automation and code analysis tools to help keep me honest. It’s no substitute to having humans check over my work, as tools will only catch the problems we can make hard rules for and I’m still relying on myself not to screw up while writing those rules. The alternative is not having any second passes over the code by others, though, and I’m absolutely willing to spend the time on testing and tuning linting configurations in order to get more eyes looking through the code and exposing problems, even if those eyes are electric.

Most of my work is in Ruby on Rails, and there are a few tools that I’ve assembled to make imaginary developer friends:

  • Testing - Write good tests so you can find out when you’ve successfully implemented a feature and whether you’ve broken anything else in the process.
  • Rubocop - A static code analyzer that checks your work against the community Ruby style guide and finds ways you might consider changing your code to make it compare more favorably with best practices.
  • Reek - A static code analyzer like Rubocop, but focused on code smells that’ll help you find what areas of your code base might benefit from some more attention. Learning why the guideline you just violated exists can take you down refactoring roads you’d not considered or known about - the sorts of things you might learn while pairing with a more or differently experienced developer on a team.
  • Git hooks - There are tools like overcommit that help you manage git hooks so that you can run all of the above before it allows you to commit or push, but automation can certainly be written manually (and more simply) too. Maybe you want your imaginary developer not to let you commit code that fails some of your checks, like you’d expect a peer review to help you eliminate potential problems before the code is accepted.

Having just one real friend to check things over should have a solid return on investment, but if the reality is that you can’t buy more help, try piecing some help together out of tools out there to help teams of all sizes. Sure, you may not get the same level of benefit, but there’s still something to be said for using tools made from the collective experience of your larger communities.