

Two Things Design Experts Do That Novices Don’t - lliles
http://noisebetweenstations.com/personal/weblogs/?p=2214

======
whacked_new
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.

------
ardit33
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.

~~~
jkneib
Actually the expert does not have to step back to see the bigger picture,
because he already has it from his experience.

~~~
whacked_new
Agreed. It is precisely the experience that allows the expert to maintain the
"big picture" in their head without incurring a penalizing cognitive load --
an ability that novices lack.

------
ced
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.

------
tel
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.

------
ejs
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

------
mtkd
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.

------
mynameishere
www.paulgraham.com/progbot.html

