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. :)
The gist is that you get into something because you have a good taste for it, but for the first few years of doing it your taste is far ahead of your skill. The trick is to keep doing things anyway, knowing they will eventually catch up and surpass your taste.
The surprising thing I've found about being okay about sucking at writing is that often the "barf drafts" (as I call them) that seem god-awful when I'm actually writing them, turn out being pretty darn good when I revisit them.
Lou Reed has a horribly sucky singing voice. I love him for it.