I think everyone’s experienced it – that feeling you get before you make a pull request to a project, when you post a new article on your blog, when you’re about to update your app to version 1.1. That feeling that you forgot something, or there’s some edge case that you didn’t think of that will bring down your entire application and ruin your career as a software developer. Release Paralysis.
Release Paralysis is a general feeling of anxiety around the release of work you’ve done to be reviewed or used by others. It can range from submitting your very first bug fix to a new team, to posting a new article to large communities like Hacker News or Reddit. Often associated with Imposter Syndrome, the author is anxious that their work will be viewed as substandard, incomplete, or irrelevent. Release paralysis can be experienced by individuals, teams, or entire organizations.
So what can we do to fix this?
The first thing I like to recommend for this is testing. Of course, you’ll want to do some level of manual testing, but to be sure of your application’s quality you need to make a concerted effort into unit and integration testing as well. These methods provide easy, measurable, and repeatable ways of ensuring you haven’t broken any existing functionality when fixing a bug or adding a feature. Of course, integration tests in themselves can be a headache to maintain and provide false negatives, but if they’re written well they will provide immense value to all future releases.
From a blog post or article point of view, try to find other articles that address the same or a similar subject. This isn’t necessarily an indication that your post is correct or incorrect, but it’s a good way to ‘test’ your ideas against other people who might have had similar experiences with a technology or subject. Even if you don’t find a point of view that matches your own, there might at least be a few ideas or points you can use to reinforce or verify your point of view against.
If you’re about to release to a larger audience, ask a peer to review your work first. They may not have be a subject matter expert, but most of your audience probably won’t be either. At the very least they’ll be able to give it a quick grammatical/syntax review, point out any obvious errors or ommissions, and ask you the same questions you’ll probably get from the audience. You’ll be able to fix those errors and be prepared to answer any questions that may come up.
Be honest with your audience. If you’ve only taken a cursory glance at the subject or technology that you’re dealing with, say as much. Some people feel this may discredit your opinion, but I think it adds credibility – being able to admit you’re not an expert gives context to your article as well as indicates that you realize there is more research to be done on the subject. If you come off as an expert, which most people assume the author is when they read a snippit of code or a blog post, you’re going to be reviewed as an expert, which may give undesired results.
When working on a new project or idea, embrace the fact that you will never be truely done. Instead of waiting to ensure you cover all the use cases or have all the facts, consider releasing early with a minimum viable product, “happy path”, or outline of ideas. Benefits of this approach include early market penetration, targeted user feedback, and provide a great way to drum up interest in your project or idea. It also separates you from the people who talk about doing something and the ones who actually execute – even if you only have a small feature, you’re one feature ahead of everyone else.
Also make it apparent that this there is more work to be done – provide a changelog, list planned features, give yourself a frequent update schedule. Let people know that there is more to do, and that you’re fully intending on doing it. That way users will feel as though they can give feedback and it will be addressed, especially if you give them credit for any bug fixes or changes in your changelog.
Waiting until everything is finished will do two things: lose user interest (they haven’t seen anything, or anything new) and give your competitors an opportunity to get ahead.
Lastly, the best way to learn, get experience, and improve the quality of your code – ship it. Publishing something to a community of peers is one of the best ways to get feedback and learn. Sure, there are going to be jerks who completely denounce your contribution, but they’re usually few and far between – most of the people in our community (at least in my experience) are there to share ideas and give honest feedback. The trick is to harden yourself against the overly aggressive or irrelevent comments, and know that you don’t have to personally respond to each and every comment that comes up.
Think of it this way – by putting yourself and your ideas out there, you’re already more qualified than any anonymous commenter without the knowledge (or courage) to write on the topic.