This is where my startup failed -- We made the decision to work in a new technology (then another!) but I was afraid of writing code I was less than proud of.

I then proceeded to learn what I could of best practices, spending far too long experimenting with the language and far too little actually doing. In the end, we ended up with two half-baked infrastructures in two different languages and reached the trough of disillusionment before anything we could show to be disillusioned about!

It's something that I've learned in other parts of my life, especially through writing, but have never quite managed in coding. The primary tenet of National Novel Writing Month is that to finish a rough draft of a long fiction work, you must, starter to professional, give yourself permission to suck, to write something you know is sometimes horrible. You do this so that you have a canvas to fix during editing, to find nuggets that you love, and can revise, and can work with.

Intellectually, I know this about programming as well, but I always have this twinge of guilt when implementing it, and go back to my old ways. The irony is that in larger projects, this can be a useful quality. Having someone on the team that can go back and look at the code, showing exactly where we need to improve before we ship is useful. In solo projects it is often disaster.

At least for me. :)