Re: Latest Joel article

"Roddy Pratt" wrote
>
> Computer science and technology is all about levels of abstraction,
> and I think that's what Joel is getting at.

The theory is fine--I never disputed it. His implementation is off--that was
my point..

> Knowledge of many levels below - or above - say, Delphi is a sign of an
> inquisitive nature: This also is usually a sign of a good engineer.

Interest is a good indication--but knowledge flows from both interest and
exposure--you can't tell too much from specific hits or misses in a
candidate's knowledge. All that tells you is what the resumé already should
have--what the applicant has been exposed to. So knowledge checking has
value only as a reality check against resumé experience claims: given what
they claim to have been expose to, were they in fact paying attention and
learing?

If a candidate claims he implemented a custom 'X' technology, then dig for
the details--what problem did he face, what technologies came into play,
what would he approach differently next time? Tech details can be very
informative here in separating the brains of the project from the merely
there.

Even there, however, I'm generally going to be more interested in the
applicant's domain knowledge than his ability to crank a quick algorithm. If
an applicant says he worked at an insurance company, then what are that
industry's special problems? How do they manage versioning? What appoach did
his company use for distributed apps? Is that the industry standard? These
kinds of questions tell you the difference between a head-down,
code-and-go-home plodder and a real star problem-solver.

Sure, I think a great developer has to be able to handle multiple levels of
abstraction and complexity, but does that mean he needs to know microcode
(or even that CPUs contain firmware)? I don't think so. _If_ those issues
come up (and in most jobs they never will), then s/he'll pick it up as
required. In fact I'd argue rather the opposite--I've seen a lot of so-so
programmers waste all day diagnosing a 'problem' with some API they're
using, when the actual issue is some top-level mistake in their own code.
'Going deep' too early is a very bad sign. And again, _if_ down-to-the-metal
knowledge of a particular problem area is important, them I'm probably going
to argue that that is because it's a specific domain issue for that specific
job--it has nothing to do with the more general question of what makes a
great developer.

bobD


.

Relevant Pages