http://www.joelonsoftware.com/articl...vaSchools.html

What do you think? Specially of the OOP-bashing he does near the end.

José González D'Amico wrote:
>
> What do you think? Specially of the OOP-bashing he does near the end.

I don't see this as OOP-bashing, while *really* understanding OO fully
requires good abstraction skills, understanding the basic concepts is not
really that hard. He is absolutely right that it does not make up for
knowledge of the kind of programming fundamentals he talks about.

> What do you think? Specially of the OOP-bashing he does near the end.

I don't think he bashes OOP either. He just doesn't think it's a good way to
separate the good from the bad programmers (and he is talking specifically about
new graduates here). While he might have a point (although I think it's
debatable), teaching people C is all too often to teach them bad habits. So
while the good programmers will still be good, the bad ones will be worse :-)
Teaching them non-procedural languages is a good thing

However, we do work in an industry where there are a vast number of
untrained/badly trained people working as developers. Some of these have a
talent, and will educate themselves in what I call professional skills, but
many/most of them will not. Even in the Delphi world, it constantly amazes me
how little is known about object orientation, for example.

I think Joel is reacting to the same problem anyone recruiting programmers has -
how do you pick the good ones? It's difficult in an interview situation. It's
even more difficult if you're hiring a new graduate. He likes to use pointers
and recursion (possibly because they were the things he found hard?). I have
tended to use more general problem solving questions when I've had to do it. And
I always want to see code. But it's still a hard problem.

Cheers,
Jim Cooper

__________________________________________

Jim Cooper jcooper
Skype : jim.cooper
Tabdee Ltd http://www.tabdee.ltd.uk

TurboSync - Connecting Delphi to your Palm
__________________________________________

Hi,

José González D'Amico wrote:

> [..]

> What do you think? Specially of the OOP-bashing he does near the end.

He is not bashing OOP. I think he is completely right about the necessity of
knowledge about recursion and pointers. I would even add that a basic
understanding of how a computer works on an electronical level should also
be required for a CS graduate. (I don't expect him to use a soldering iron
to repair a broken motherboard, though. ;-) )

twm

"José González D'Amico" wrote
>
> What do you think? Specially of the OOP-bashing he does near the end.

As with Wayne and Jim, the 'OO-bashing' doesn't particularly bother me,
though it is wrong-headed.

First, the idea that OO is too simple to allow the good programmers to stand
out is simply silly--pointers aren't hard in any basic sense either. If an
old style CS101 course had a higher dropout rate than a new style Java
intro, the difference isn't between pointers and objects, but between the
relative complexities of what people are being asked to do with them (and as
he really admits, that's an academic politics issue and has nothing to do
with subject matter).

As Joel mentions, the actual material of either approach is tiny--you spend
the rest of the semester 'getting it.' It's got no more to do with Scheme
vs. Java than learning to think has with whether or not Latin is required.

So fundamentally, I think Joel has his glasses on backwards: he thinks he
can tell the great from the mediocre programmers quickly based on the
material he was taught in college, but admits he can't do that with the new
kids. And part of the reason for that, apparently, is that he's still
conducting his screening the way he did and with the same questions he used
twenty years ago.

Where's the vaunted mental agility that he's demanding of his interns? The
yardstick he was using was always extrinsic--like telling how new a pair of
shoes are by how shiny they are, it worked great until people started
wearing sneakers and suede. But at that point it's really the standard that
fails, not the shoes: there are still old and new ones just like always, and
you still need to figure out which are which.

Maybe Joel needs to stop waxing nostalgic about Latin, and start figuring
out a better way to think about applicants. The first thing to consider is
asking what he really wants--and I'd suggest that that's /not/ the ability
to whip out pointer code on a whiteboard, and really never was.

bobD

"Bob Dawson" <RBDawson> wrote in message
news:00a1
>
> Maybe Joel needs to stop waxing nostalgic about Latin, and start figuring
> out a better way to think about applicants. The first thing to consider is
> asking what he really wants--and I'd suggest that that's /not/ the ability
> to whip out pointer code on a whiteboard, and really never was.
>

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

You start at the highest level of abstraction (user interface modelling,
say) and gently burrow down through overall system designs, class
hierarchies, algorithms and data structures, high-level programming
languages,pointers, assembler, machine code, microcode, VHDL, registers,
flipflops, transistors and quantum theory...

IMO, what distinguishes a great engineer from a good one is the DEPTH of
abstractions that they can handle if required. Everybody has bounds at which
they think "here be dragons", and they just have to assume that the lower
levels work, and they don't really care how it happens. For me, it's at the
microcode level (although in truth I haven't used assembler for years).

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.

- Roddy

"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

Bob Dawson wrote:
>
> First, the idea that OO is too simple to allow the good programmers
> to stand out is simply silly--pointers aren't hard in any basic sense
> either.

My experience forces me to disagree about pointers (not about OO). For far
too many programmers, understanding pointers and references even at the most
basic level *is* difficult. I could provide endless examples of things I've
seen that, IMO, cannot be attributed to simple inexperience but to lack of
education and/or logical abilities. In both Delphi and C++, many errors in
the use and management of objects are a direct result of having no
understanding of pointers. Java and .Net, with their built-in garbage
collection partly alleviates some of these (memory management ones) but also
makes it possible to engineer even harder to diagnose problems. So even
someone that otherwise has gained a good grasp of OO and can show good
design abilities can still easily be tripped up if they lack other
fundamentals.

> As Joel mentions, the actual material of either approach is tiny--you
> spend the rest of the semester 'getting it.' It's got no more to do
> with Scheme vs. Java than learning to think has with whether or not
> Latin is required.

The question, like with Latin, is whether knowledge of pointers is still of
any *practical* value for application-level programmers. My opinion is yes,
it is still necessary and still will be for sometime at least. There *may*
come a day when that is no longer true.

> So fundamentally, I think Joel has his glasses on backwards: he
> thinks he can tell the great from the mediocre programmers quickly
> based on the material he was taught in college, but admits he can't
> do that with the new kids. And part of the reason for that,
> apparently, is that he's still conducting his screening the way he
> did and with the same questions he used twenty years ago.

This part I have some agreement - I think some of the questions he asked 20
years ago are still valid as part of this, but of course candidates should
also be judged on other, newer, concepts and technologies. A programmer that
has great fundamentals but absolutely no grasp of OO is also not very
attractive to me.

> But at that
> point it's really the standard that fails, not the shoes

The standard must evolve with the times, but not be thrown out wholesale.

Roddy Pratt wrote:
>
> IMO, what distinguishes a great engineer from a good one is the DEPTH
> of abstractions that they can handle if required. Everybody has
> bounds at which they think "here be dragons", and they just have to
> assume that the lower levels work, and they don't really care how it
> happens. For me, it's at the microcode level (although in truth I
> haven't used assembler for years).

My rule of thumb is that one should have a very decent understanding of at
least one level below that which one normally works at. More than one level
is of course better, but not having even one such level can result in
nothing but inconpetence. If schools are not at least teaching that one
level down then they are failing.

"Wayne Niddery [TeamB]" <wniddery> wrote in message
news:f961
> Roddy Pratt wrote:

> My rule of thumb is that one should have a very decent understanding of at
> least one level below that which one normally works at.

And one level ABOVE is equally important.

- Roddy

"Wayne Niddery [TeamB]" wrote
>
> My experience forces me to disagree about pointers (not about OO). For far
> too many programmers, understanding pointers and references even at the
most
> basic level *is* difficult.

Understanding OO is he same for many, though--even at the most basic level.
Why else would we get the recurring questions in b.p.d..oodesign about 'How
would I do this with an object?' where the most obvious answer is 'You
wouldn't--what you're asking that function to do is already wrong from an OO
perspective.'?

> ... In both Delphi and C++, many errors in
> the use and management of objects are a direct result of having no
> understanding of pointers.

You mean, no understanding of object lifetime management? <g>

bobD

"Roddy Pratt" wrote
>
> And one level ABOVE is equally important.

And I'd say /way/ more important.

The issue links in my mind to that of optimization. How does one optimize
code? I'd argue that it should be rigorously top-down--

First, make sure you're solving the actual problem (domain understanding)
Next, make sure you're doing only what the problem demands (program
design)
Next, make sure you're doing that efficiently and smartly (algorithm and
caching choices)
Next, make sure you've coded efficiently (code optimization)
Finally, look for specific low level speed tricks you can use.*

(* off topic, but may as well mention that a profiler starts getting
important by step three)

Ideally, I'd like a developer to be able to bounce around these layer with
equal aplomb (and I'm sure we all would), but push come to shove, I'd much
rather hire a programmer who can see up this ladder efficiently than one
who's too in love with bit-fiddling in code that should never have been
written in the first place.

For that reason, to me it's much more important in a job interview to see if
the candidate can look up a couple of layers than to test his ability to
drop down.

bobD

Jim Cooper <jcooper> wrote in message
<43b6688c>
> However, we do work in an industry where there are a vast number of
> untrained/badly trained people working as developers. Some of these have a
> talent, and will educate themselves in what I call professional skills, but
> many/most of them will not. Even in the Delphi world, it constantly amazes me
> how little is known about object orientation, for example.

I agree, though I think the only good training comes from years of on-the-job
experience. A competent, experienced programmer will be far more productive
than a fresh grad. Also, "self-taught" doesn't mean untrained. Some of the best
programmers I've ever known were self-taught.

I think Joel does have a point about recursion though. If a "programmer"
doesn't understand recursion, or where and when to use it, it is unlikely that
he is very good for much else either.

"Wayne Niddery [TeamB]" <wniddery> wrote in message
<43b6bec0>
> A programmer that
> has great fundamentals but absolutely no grasp of OO is also not very
> attractive to me.

Same here. I do believe that a good understanding of OO goes a long way toward
producing good code.

On Sat, 31 Dec 2005 13:41:24 -0000, "Roddy Pratt" <roddy at spam
fritter dot com> wrote:

>IMO, what distinguishes a great engineer from a good one is the DEPTH of
>abstractions that they can handle if required. Everybody has bounds at which
>they think "here be dragons", and they just have to assume that the lower
>levels work, and they don't really care how it happens. For me, it's at the
>microcode level (although in truth I haven't used assembler for years).
>
>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.

I'll go a bit farther--I don't think you can truly be good at any
given level without knowing something of the level beneath it.

As far as I'm concerned a good programmer can at least tread water if
they get dumped down to the assembly level. In the real world you'll
occasionally find yourself having to work deeper than your normal
level in a bug hunt and if you're going to drown when you're dumped in
that level you aren't going to be a good programmer.