This actually causes "coder's block" in me when I start a new project. If I have this cool app or site idea, it often never gets off the ground because I spend too much time trying to create some architectural framework that I assume I need.
This is REALLY bad for me in Cocoa/Cocoa Touch apps. Objective-C is so verbose and writing classes is so "mechanically cumbersome" (having to write .h and .m files and duplicate stuff, for example) that I sometimes lose interest before I ever really get off the ground.
The trick I use to beat this tendency is to totally eschew good software engineering principles at first. Typically all of my code lives in main.m (and I usually start out in CodeRunner rather than XCode). Interfaces are done sloppily in Interface Builder or entirely in code. This really helps me get started.
Before long, of course, I have this unwieldy spaghettified mess of a single source file. By that time, though, I have some stuff WORKING, so doing some refactoring into a good architecture for the code I have while keeping the working stuff working is kind of fun.
I find that the limited free time (wife, kids, etc.) I have available for side projects forces me to prioritize. If I gold-plate everything, nothing will ever get done, so I simply don't write code that's not absolutely necessary.
I will code very thin "frameworks" if it becomes obvious that it will save time over the long haul, but there is no "this might be useful someday" code. If it doesn't move the project forward, it doesn't get done.
If your most precious resource -- time -- is limited, it forces ruthless prioritization.
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.
I try to think in terms of interfaces, but implement quick & dirty.
So, for example, I may imagine that data sources for a page will come from several places: the db, Google maps, an api like Twitter etc. And I will create stub classes to capture this concept, but the methods will just return hard-coded elements. Eventually if the project goes anywhere I can build out the underlying methods as necessary.
I find this helps me feel like I'm doing real engineering but not get too lost in the abstractions.
Right there with you. I have started doing the same thing on my iOS projects. I just keep telling myself to plow ahead and not to make it perfect. Go with my gut instinct at that time and keep on moving forward.
What I also like to note to myself, mentally anyway, is that it is far far far... more rewarding to start and finish an app or project than it is to be "almost" finished, but what you may consider perfect code.
This is REALLY bad for me in Cocoa/Cocoa Touch apps. Objective-C is so verbose and writing classes is so "mechanically cumbersome" (having to write .h and .m files and duplicate stuff, for example) that I sometimes lose interest before I ever really get off the ground.
The trick I use to beat this tendency is to totally eschew good software engineering principles at first. Typically all of my code lives in main.m (and I usually start out in CodeRunner rather than XCode). Interfaces are done sloppily in Interface Builder or entirely in code. This really helps me get started.
Before long, of course, I have this unwieldy spaghettified mess of a single source file. By that time, though, I have some stuff WORKING, so doing some refactoring into a good architecture for the code I have while keeping the working stuff working is kind of fun.