Tips for Developing in a Vacuum

Recently, I was tasked with building a complicated and unique API for uploading and managing web ontologies. Unfortunately, I didn’t have access to a team on this project, so I was stuck architecting and building a complex system alone.

Developing systems alone is not an uncommon situation for software developers. Oftentimes, the owner of the product might never even see, or want to see, the inner workings of the product. To top it off, the system you’re working on might be closed source — meaning you can’t share the code with friends or colleagues to get outside opinions, effectively leaving you to create products alone and inside a vacuum.

Creating in a vacuum is an extremely difficult thing to do well. You run the risk of overcomplicating your work, missing use cases, or simply not getting enough work done because you’re too worried about making the first two mistakes.

Difficult isn’t the same thing as impossible, however. By being mindful and following the advice below, you can avoid creating a fragile, unusable system.

Avoid Analysis Paralysis

One of my constant struggles when working alone was getting stuck in a cycle of writing or architecting something and then spending twice as much time debating on whether or not I should have written it. I found myself spending days debating how to create the perfect system instead of actually creating it. Constant internal debate on what’s best for the longevity of the system is an easy trap to fall into — and while I still do from time to time I’ve developed a couple of tricks that help me avoid it.

First, avoiding analysis paralysis begins with realizing what generally causes it in the first place — fear. Fear that your end product won’t be good enough, that you’re missing an extremely important use case, or that a future developer will rip your system apart for not being good enough. You could be afraid that what you built won’t stand up to scrutiny or that the customer will reject it outright. These fears can quickly overwhelm you and create an atmosphere of hesitancy and defensiveness that will delay your project again and again.

There is no easy trick for getting over these kinds of fears. I’ve found that for me, accepting that each thing I’m afraid of will most likely happen at some point in my career (no matter what I do) helps. I know for a fact some future developer will shred the system I built alone, either with cause or simply because they’re grumpy. I’ve accepted that there are flaws in the system that will only be visible with another eye on the project. By accepting the reality of these cases, I’ve been able to move past the fear and instead decide how I’ll handle those situations when they arise.

Second, just start writing. Even if you throw out everything you write during that time, you’re building up speed to get over any other mental hurdles you might have. Never discount momentum when it comes to creative work. I can promise if you just start and avoid even pausing, that you can eventually push through whatever it was that was stopping you.

Use What You Build

The easiest way to find the corners you’ve cut (or the entire walls you might have forgotten to put up) is to use your own product. Consuming an API you built by creating a UI on top of it, building an integration to a third-party service, or simply recreating your API in a different language will demonstrate where your product falls short.

Put yourself in the shoes of your customer by figuring out what it is they actually do and what your tools are supposed to accomplish. I’ve made an effort to spend time pretending that I’m an intern in charge of a certain task and allowing myself to only use the tools I’ve created for that task. This has almost always exposed shortcomings in my product and helped me smooth the rough edges before a release.

Demonstrate Continually

You will almost always receive some direction at the start of a project. You might get handed a list of requirements or simply be given a verbal send-off. What you might not get, however, is any kind of check in or continual guidance from the project manager/owner.

No matter what anyone says, though, requirements will almost always change, and those requirements might not be communicated to you in a timely manner. Apart from continually messaging or calling the stakeholders of a project (potentially annoying them and consuming your time with endless meetings and deliberation), what can you do to stay on top of things?

I’ve found the most effective method for staying in contact and maintaining that essential back and forth is to demonstrate the product as often as I can. When a new feature is added, I send emails or set up meetings to show it off, including as many of the stakeholders as I can on the invites or email chains. What I’ve found is that these meetings and emails tend to spark larger conversations about the product itself and expose those requirements that might have gotten lost or forgotten.

Go Easy on Yourself

The final bit of advice I’d offer is to give yourself a break. There’s only so much you can accomplish alone. You’re going to make mistakes, and some of them will be big ones. You’re going to rewrite things you felt were perfect at the time. Most likely, your work will eventually be torn down either figuratively or literally by other developers — and it will be hard to keep going after that.

Know that you are still a talented, hardworking software developer who has solid ideas and problem-solving skills. Learn from your mistakes and move on instead of dwelling on the past or on things you cannot change.

Finally, even though you’re developing in a vacuum, know that there is a large and supportive community out there just waiting to get to know you. Come join us!