Yeah, this is basically my approach too; my first priority when "banging out an idea" is /get it working/ and make a "minimum viable product" (or tool, utility, script...whatever). If it's awesome, I might consider re-writing it, learning from the mistakes or architectural flaws of my first design. Note that the very first revision can usually be dropped in favor of a paper design of the thing, where you can visualize the flaws before writing the first line, and correct them before you start typing.
There are also things that I have that technically work, but are ugly, but are never getting fixed. I learned from them and it's fun to look back at how much better I got over time. I could probably go back and turn everything into nice classes and remove big blocks of commented-out code, but...it'd be pointless. I'd rather work on something new and do it better the next time. Tackling exciting new problems is what makes coding interesting for me, and I'd hate to lose that "just" to be proper.
I like to think of my lang dirs in my homedir (ruby, c, python, js, php, etc) as language-specific "coding sketchbooks" where I'm developing recipes that I might borrow from later. It's kind of similar to being a chef, I suppose -- you finely craft and refine dishes for your day job ("staging/production"), maybe you're lucky enough to get some paid time to work on your ideas ("dev"), and you dedicate one night a week to culinary experiments on your own time, maybe with friends or family ("passion").
I feel like a good programmer is like a good chef, and if you lose the passion, you mostly stop getting better.
It's important to get your hands dirty and do a bottom-up approach, but it is equally as important to think top-down as well. What I mean is don't be ignorant of the "gold plate" while you are creating the minimal viable product, but be flexible enough so that it doesn't get in your way.
There are also things that I have that technically work, but are ugly, but are never getting fixed. I learned from them and it's fun to look back at how much better I got over time. I could probably go back and turn everything into nice classes and remove big blocks of commented-out code, but...it'd be pointless. I'd rather work on something new and do it better the next time. Tackling exciting new problems is what makes coding interesting for me, and I'd hate to lose that "just" to be proper.
I like to think of my lang dirs in my homedir (ruby, c, python, js, php, etc) as language-specific "coding sketchbooks" where I'm developing recipes that I might borrow from later. It's kind of similar to being a chef, I suppose -- you finely craft and refine dishes for your day job ("staging/production"), maybe you're lucky enough to get some paid time to work on your ideas ("dev"), and you dedicate one night a week to culinary experiments on your own time, maybe with friends or family ("passion").
I feel like a good programmer is like a good chef, and if you lose the passion, you mostly stop getting better.