> But I've seen some horrible programmers here. They can go through the
> entire CS curriculum here and still not 'get' it. By the same token, I've
> seen plenty of people who came in to MIT with self-taught
> skills, and experience in the 'real world', who aren't going to
> gain much from most of the regular CS classes.
[sorry, this turned out to be rather long]
I wanted to stay out of this discussion, but this is a good point. Places
like MIT and Berkeley, etc., tend to attract self-taughts, and I suspect
that if many of them never went on to get their CS degrees would still be
damn good programmers. These are what the real-world calls geeks, and are
driven by knowledge and a desire to learn.
In my 10+ years of experience, I've come across code from experienced CS
programmers that really s*cks, and I've met interns that could program
circles around me. I think it's a matter of whether you really love to
program or not, not whether you have a CS degree or not.
As far as telling good from bad (at the interview), I think the only real
evidence is to look at code. This should be done in two steps: first, get
code samples and review them, then second, give the candidate some simple
project to code (something obscure that they can't just copy from someone
else and let them do it on their own time, no need to waste your time), and
then critique that. A BAD programmer will give you back code that is one of
these:
o Clean code, works bad
o Messy code, works good.
o Messy code, works bad.
A GOOD programmer will return:
o Clean code, works good.
A GREAT programmer will return:
o Clean code, works good, runs fast, small footprint[, extensible].
One thing that drives me nuts with both CS and self-taughts is code where
everything is hardcoded into the program. I can't stress enough how
important it is to get your configuration information from external files.
DON"T HARDCODE ANYTHING THAT CAN BE READ-IN, UNLESS ABSOLUTELY NECESSARY!
rant, rave, rant.
One thing that I did while working in a shop with lots of custom code was to
create a module for reading-in configuration info (see
http://www.neonedge.com/perl_tools/Config/). If you can't move your code
from one place to another without changing more than the bang-line, your
code is broken and should be fixed. I've since used the same module for
creating rule-sets and creating plug-in code snippets. In fact I'm using it
extensively in NeonDB (see the www.neonedge.com/neondb.html page).
That's my "12 cents" ("2 cents" was the original goal ;-),
Grant M.
