The problematic activities described here, overgeneralization and solving imaginary problems (aka Coding for A Rainy Day), are simply typical newbie mistakes.
Otherwise highly competent developers almost always fall into this trap early in their careers, so the important thing is to have someone experienced in charge of the project who can veto their weirder ideas until they mature.
I think every software company should hand out a copy of "The Pragmatic Programmer" to all new hires. It gives much good advice on how to not overcomplicate things.
- Designing too much flexibility at the start of a project and regretting it when it takes ten weeks to build a prototype.
- Designing too little flexibility at the start of the project and ending up living with unmaintainable cruft.
- Realizing that all projects are hell and planning on a rethink/rewrite/refactor when the real requirements become clear because no one can predict the future, so why not hold some contingency for the inevitable.
In the real world, I suppose, that means not doing anything clever, except to backpedal and fix a problem.
Got it -- the end should read "more remote places"
Intelligence is like four-wheel drive. It only allows you to get stuck in more remote places
http://www.quote-feed.com/Quote/Quote31.htm
Sorry -- quote collector here :)
http://scottaaronson.com/blog/?p=418
On the other hand, this style of thinking has some risk of demotivation. It collapses varied results into a static judgment prone to a 'fixed mindset': no matter the inputs of intellect/talent/effort, the end result is you hit a limit. So smile at the insight but remember which limit you hit still matters. The deeper snow is more fun.
... but smart people tend to require a bigger rationalization to be satisfied. And they also tend to be more capable of creating a rationalization of that magnitude.
The question is whether they've developed the habit of "reality testing" and discarding flawed rationalizations.
