> ...building a prototype without knowing what it's for
I'm not sure if it's 'brogramming', but it turns out this is exactly how it SHOULD be done. We call it iterative development.
The "specifications focused engineering" you babble about was called 'waterfall', and I'm pretty sure the 1) Develop Requirements, 2) Code, 3) ???, 4) Profit model was discredited long ago.
In the 21st century (and most of us had figured this out by the late '90s) we say fuck step 1, do #2 as quickly as possible then wash (aka refactoring), rinse, repeat. Step 3 turns out to be "get it into production" which means sales for a commercial product and internal use for something developed in-house. #4 comes after a few of those wash, rinse, repeat cycles, assuming you do it right.
Granted, you may have to replace true "production" use with some (usually expensive) simulated testing for things like medical equipment and nukes. But for non-safety stuff (and I'm guessing that's the majority of code written today), requirements development occurs only after you have real users get their hands on a real end product.
This is also why languages like C and in fact languages in general sans some middleware like Rails, Drupal or J2EE simply aren't the way to go for most projects. If you can't do #2 and have a working product for users to touch and feel really, really quickly, your project will probably be more expensive to develop than it's worth.