Think this is from the pragmatic programmer, it's stuck with me for years:
It's a lot easier to hit your target if you're using tracer bullets instead of learning the physics required to hit your mark without a good feedback mechanism. Tracer bullets let you guess and compensate for the actual path the bullet travels when all physics variables are taken into account without actually needing to understand the physics. You don't need to be a super dev sniper to be really productive if you work pragmatically.
That is such a great book, and tracer bullets are one of its great metaphors. Pulling it off the shelf, I see the section they are introduced in is titled "Code That Glows in the Dark" and lists the following advantages of the approach:
""
- Users get to see something early
- Developers build a structure to work in
- You have an integration platform
- You have something to demonstrate
- You have a better feel for progress
""
These are followed by "Tracer Bullets Don't Always Hit Their Target", and "Tracer Bullets vs. Prototyping", then goes on to discuss prototyping... Published in 2000, there is so much more in there than "use a framework" (though that would be good advice!).
Thanks for reminding me of it. About time for some rereading.
On some other recent thread someone was complaining that many programmers are completely lost at debugging, tracing execution, identifying relevant errors, etc., and just resort to Stack Overflow whenever the framework fails. I've seen the same - and learning programming without instant feedback is the most likely culprit here.
It's a lot easier to hit your target if you're using tracer bullets instead of learning the physics required to hit your mark without a good feedback mechanism. Tracer bullets let you guess and compensate for the actual path the bullet travels when all physics variables are taken into account without actually needing to understand the physics. You don't need to be a super dev sniper to be really productive if you work pragmatically.