We've all been told that "premature optimization is the root of all evil," but isn't that almost a tautology? As soon as we label something "premature" we've already basically decided it is undesirable. Try to think of some other premature things, and then classify them as "good" or "bad." One of those categories will be empty.
Premature optimization is a bad idea for the same reason anything else is a bad idea: it is at odds with—it works actively against—what actually matters. And I'm here to remind you that what actually matters in all but the most academic or maintenance-oriented kinds of programming is your productivity. In other words, there is no such thing as premature optimization for productivity. It is never too early to optimize for productivity, because productivity is one of those rare and slippery concepts, like Rationality, that is purely good by definition.
With that value structure in mind, I think we can say it better than Don Knuth:
Early optimization for productivity trumps all other kinds of early optimization.
The spoils of early productivity are so profound, not only because it makes programming fun and satisfying, but also because you can throw everything away and start over from scratch, once you're convinced that's the right thing to do, and you still come out ahead of the perfectionists.
Concretely, if I can leave you with just one tip for early productivity, it is that you should always (always) take the opportunity to switch from a programming language that leaves obstacles in your way to one that gets out of it.
The Raspberry Pi userland libraries are all written in C, and for a long time I thought I was stuck with it, unless I wanted to reimplement all that low-level machinery myself.
I got my first wind of developer efficiency when I switched from writing my OpenGL shader programs as string literals that had to be compiled along with the rest of the project, to loading them at runtime from text files, even though I had to write a 37-line C function for reading files from relative paths.
It was a huge breath of fresh air when I realized I could be writing C++ instead of C, encapsulating resources as objects and moving my teardown logic into destructors, so that I no longer had to play the goto error game. Unfortunately, the switch to C++ ruined my 37-line function for reading files, because the __FILE__ constant in C++ is not an absolute path. A small price to pay: back to string literals!
Then I found out just how easy it was to embed V8 and start using that C++ code directly from JavaScript, thanks to node-gyp, and that was when I felt the first twinges of a productivity that mocked all my previous toils.
In conclusion, it was Benjamin Franklin who said
Those who would give up essential Productivity, to purchase a little bit of Perfection—those folks got way too much time on their hands.
But perhaps it was Lil Jon who put it best:
Turn down for what?