You are finally back home. During your work day your mind was totally a volcano of creativity. You have so many cool ideas to implement (or at least to sketch). You go to your machine and you start to thing to the technical details. Many questions reach your mind. Maybe too many. Is it better to use Python or Haskell, or maybe C++? I have to start implementing my game prototype with Unity or with some other engine? What if in the future I want to add “feature X” after “feature Y”? So you start crawling the web for resources, opinions and more information on your problem. And this will generate more questions. You spend two hours in this way and you are still full of doubts. Then it becomes late. You are tired. You will check out this problems tomorrow. But tomorrow you will find others problem and not even a solution. And so on. Until every project loses its momentum.

This scene happens to me and other people too many times. This is a classical example of developer anxiety. It is one of the most frustrating experience in this field: you have an idea but you can not even start to implement it because of the many technical choices you have to make but you are not brave enough to do. Because developer anxiety can be very common, I’d like to share some of my experience on this.

The Causes

It is interesting to look at the reasons behind developer anxiety. Let's go in order.

1. Overgeneralization

[caption id="attachment_202" align="alignleft" width="300"]

A perfect represenation of overgeneralization: http://xkcd.com/974/[/caption]

This is one of the most common obstacle on the way of a successful project. Because developers are genetically trained to think about generalization and abstraction, our natural way to tackle a problem is to solve the general problem. Always. If we have to make a function to draw a triangle, we think on how to do a function capable to draw any regular polygon. If we have to represent a matrix of char, we design data structures that can store every grid of objects.

This tendency to overgeneralize over any problem can really slow down a project. Even if the generalized problem can solve many problems in the future, if it requires more than 15 minutes to be solved it is really recommended to take it apart and start with the particular one. Proceed in the development is fundamental for keeping the momentum of a newborn projects. If you lose two hours in solving the general problem, probably you get frustrated in not seeing a global advancement and the project can probably suffer of this.

In general the direction you want to take is from the specific to the general and not viceversa. It is better to have something specific working than a perfect general machine not working.

2. The Oracle

Another big anxiety generator is the "oracle syndrome". The anxiety arises from the attempt to predict in advance every possible flaw in the architecture, in the feasibility of some design choice and so on. Obviously this is not possible. Experience and knowledge can help into avoiding obvious errors, thinking about that is a wise choice, however it is not possible to solve every error in advance. This problem usually pairs with the overgeneralization one: for instance, trying to check if a particular data structure will be scalable to the general problem.

You have to resign yourself to the fact that you can not solve all the problem in advance. Moreover, often can happen that the “perfect solution” will be completely broken after the first practical problem you find during the actual implementation. As a result, all the time you have spent in thinking is completely wasted. So, please, stop overthinking on possible problems and start exploring the real world implementation.

3. The Perfect Shot

Another way in which anxiety is manifested is into the desire to deliver a software from scratch directly into its final form. A long beautiful elegant parabolic shot from "nothing" to a state-of-the-art product. It is evident that this problem is quite similar to the oracle problem but has a tiny huge difference. In this case the developer is not trying to anticipate every problem, is trying to develop every possible feature all at once. So, instead of a working prototype with limited features, he has a not working mass of code that partially implements 100 features.

In the best case. Because in reality, the anxious developer, thinking on how to implement all this features, will be overwhelmed and it will never write a single line of code. So, don’t try to be a perfect archer, rather try to be a golf player: try to reach the goal through manageable and reasoned intermediate steps.

4. Information BlackHole

The anxious developer will search for information. Is it better Python or Lua for this problem? Will it be this language scalable to ten billion users? Will this framework be supported in fifty years? More the developer searches, more it sees different opinions, pro and con that will have the only effect to increase the developer's overthinking. At some point, the amount of information will reach a critical mass and the developer world will collapse on itself.

In general, too information is even worse than no information at all. This desire of information is obviously driven by the “Perfect Shot” and “Oracle” flaws, but it is so important that it deserves a point by itself. Search for information is good, try to use information to know everything before start coding is BAD. There are two main reasons why the time used to explore the available domain knowledge should be limited and well allocated. First, you can always find opinions that are opposite each other, second, every second you spend searching for information you increase the risk of falling into (3) or (2).

This is a problem that I feel very near because (unfortunately?) I know too many programming languages and I spend too much time into selecting the right one for the current task. Oh well…

The Solution

Now that we know the causes behind developer anxiety it is time to see The Solution:

JUST DO IT

Really. Trust me. It is so simple. I know it is hard. Often, even I can not follow this simple advice. But it is the solution. When you see your code “alive”, also if it is not perfect, you completely forgot about any of the previous stuff.

So my advice is to allocate a fixed amount of time for thinking: 2 hours, 6 hours, a full day, whatever. But when the time ends, you start working. It will not be the perfect software, but it is something. And in the coding workflow it is incredibly important to see something works.