Find yourself some rules to stick to !

    I realized that keeping a few rules could be more important than any other skill of a developer. Some of them are :

• making a precise image of what you want

   If you are writing an algorithm, unless you are 90% sure that this is the right solution, at least in your best, you shouldn't be writing it at all and think harder. Programming is much like the real life and a lot of principles are valid in both.

• having a plan one step further 

   Developers have a tendency to think something through, make a plan, but we cut it off right after we reach some expected state in that plan. It is always good to know about the next step. Unless we have a project manager that makes the overall plan for us.

• be able to make decisions (there is nothing worse than chronic indecision)

   If you have a decision to make regarding something more high-level, like writing a validation component, it may have tons of consequences. It may very well lead you to procrastination and triple realization time, because you are not able to make a quick decision. These are the worst...hate this.

• sticking to the plan 

   I think that this is not necessary to exemplify. Start doing A and suddenly you are doing B or A,B or A,B,C :-)

• avoid ambiguity or mess 

   Have you ever come back to a component that you wrote long time ago in a different language than your primary one and you found obscure comments, redundant files, etc ? In other words, you abandoned something that looks like if it wasn't finished yet ? Nightmare...

• learn to recognize when to use prototyping

     Software development landscape is too diverse. All the planning, solving problems, prototyping. Either you think something through really well to be as much sure as you can by its correctness and validity OR you create a prototype, trying to see it in action soon and reveal what would have been unknown otherwise. 
     I have a rule that when I am about to create some new feature, I rather go with prototyping. When I am about to refactor a component, I rather think it through very carefully, avoiding getting stuck at the same time. Because I might find myself hesitating between 5 possible solutions, each of which introducing different consequences...

• if you are a startaper, be ready and willing to fail fast !

Another obvious fact. A developer entrepreneur must recognize that it is time to admit he would be better off and declare the project dead.

I've been underestimating this for many years if I take a look back. Humans are used to learn from mistakes, but these mistakes are hidden and the real causes are not obvious. So I'm catching myself doing the same mistakes again and again.Unfortunately neither of these rules isn't easy to stick to. 

Anyway, unless I am really sure it is the right choice or I have some doubts, I will miss the enthusiasm needed for accomplishing the task...At least this protection mechanism is reliable.