Ineffective programmers sweat the little details, and tend either tend to spend too much time on them, or solve them in such a way (usually isolated), that it hurts the design of the whole system, and shoot themselves in the foot for later one. Usually this is manifested in spaghetti code, or over-complicated engineering of things that should be simple.
While an experienced programmer, sees them as details that have to be solved, but without loosing touch of the bigger picture.
Particularly interesting is a part in the paper that describes how expert engineers would quickly abandon alternatives that incur higher cognitive cost. It is possible that breadth-first search happens before this, which is not surprising (in fact, is expected, if you think in terms of Ericsson's explanation). The crucial move is what heuristic the expert uses to prune their decision tree, in a rapid, economical, sensible, and ultimately practical fashion.
So in fact, the blog post's claim of "Both product developers and designers have a tendency to jump on the first great idea they generate and head down one path, instead of patiently exploring the space of possible solutions" can't really be called a characterization of novice product devs/designers -- because you may observe the exact same behavior (i.e., observable behavior) in experts.
The Lawson study cited in Nigel Cross's paper said the recurring theme in expert designers was their claim to be keeping multiple concepts in parallel. This is a reiteration of Ericsson's theories (long term working memory). The key difference, as it seems, is, unsurprisingly, exposure and experience.
IMHO, "pragmatists" vs. "realists" is a suboptimal generalization.
There's a natural abstraction hierarchy in every field I know. I claim that those fields that don't have good abstractions are precisely those that don't fare very well.
So, in my experience, concept designs are best used when two wildly varying ideas are able to combine. Do two failed startups take their ideas, mesh them together, and produce one new totally innovative one?
I'd like to hear stories about that.
My attitude has always been worry about that problem when we get there, and find a solution that is acceptable - not necessarily the one you had in mind first.
One line that I always try repeat to myself (especially in circuit design) is "If the solution seems difficult, try to restate or reconfigure the problem.
Its like the old getting lost in the trees cliche
Understanding what something isn't is as important as understanding what something is - in my experience anyway.
