Two Things Design Experts Do That Novices Don’t

I think the bit about top-down, breadth-first search is erroneously regarded as a crucial concept of the paper this author cites. That is an excerpt from the introductory portion of the paper, and does not appear to be the rule in terms of being a problem-solving approach.

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.

I see it over and over in engineering, novices get tangled in the details, and don't step back to look at the bigger picture.

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.

I'd frame it that Experts deal with increasingly abstracted-out ideas. Expert physicists differ from pre-schooolers in "not having to sweat out arithmetic, algebra, etc."

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.

Interesting parallel: Y Combinator is a breadth-first search through the possible solution space. It galvanizes a number of potential solutions (similar to following a number of promising concept designs) and eventually is successful.

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.

This is something I have found very true. I try to avoid talking about certain problems with certain people because they will just focus on small seemingly unsolvable problems that don't matter much in the end.

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

When you're experienced at something you might not know a solution to a problem in that area, but you will often know what isn't the solution.

Understanding what something isn't is as important as understanding what something is - in my experience anyway.

www.paulgraham.com/progbot.html