Why is everyone in such a rush?
Walk into any bookstore, and you'll see how to Teach Yourself Java in 7 Days
alongside endless
variations offering to teach Visual Basic, Windows, the Internet, and so on
in a few days or hours. I
did the following power search at Amazon.com:
pubdate: after 1992 and title: days and
(title: learn or title: teach yourself)
and got back 248 hits. The first 78 were computer books (number 79 was
Learn Bengali in 30 days). I
replaced "days" with "hours" and got remarkably similar
results: 253 more
books, with 77 computer books
followed by Teach Yourself Grammar and Style in 24 Hours at number 78. Out
of the top 200 total, 96%
were computer books.
The conclusion is that either people are in a big rush to learn about
computers, or that computers are
somehow fabulously easier to learn than anything else. There are no books
on how to learn Beethoven, or
Quantum Physics, or even Dog Grooming in a few days.
Let's analyze what a title like Learn Pascal in Three Days could mean:
Learn: In 3 days you won't have time to write several significant programs,
and learn from your
successes and failures with them. You won't have time to work with an
experienced programmer and
understand what it is like to live in that environment. In short, you won't
have time to learn much. So
they can only be talking about a superficial familiarity, not a deep
understanding. As Alexander Pope
said, a little learning is a dangerous thing.
Pascal: In 3 days you might be able to learn the syntax of Pascal (if you
already knew a similar
language), but you couldn't learn much about how to use the syntax. In
short, if you were, say, a Basic
programmer, you could learn to write programs in the style of Basic using
Pascal syntax, but you
couldn't learn what Pascal is actually good (and bad) for. So what's the
point? Alan Perlis once said:
"A language that doesn't affect the way you think about programming, is
not
worth knowing". One
possible point is that you have to learn a tiny bit of Pascal (or more
likely, something like Visual
Basic or ) because you need to interface with an existing tool to
accomplish a specific task.
But then you're not learning how to program; you're learning to accomplish
that task.
in Three Days: Unfortunately, this is not enough, as the next section
shows.
Teach Yourself Programming in Ten Years
Researchers (Hayes, Bloom) have shown it takes about ten years to develop
expertise in any of a wide
variety of areas, including chess playing, music composition, painting,
piano playing, swimming,
tennis, and research in neuropsychology and topology. There appear to be no
real shortcuts: even
Mozart, who was a musical prodigy at age 4, took 13 more years before he
began to produce world-class
music. In another genre, the Beatles seemed to burst onto the scene,
appearing on the Ed Sullivan show
in 1964. But they had been playing since 1957, and while they had mass
appeal early on, their first
great critical success, Sgt. Peppers, was released in 1967. Samuel Johnson
thought it took longer than
ten years: "Excellence in any department can be attained only by the la
bor
of a lifetime; it is not to
be purchased at a lesser price." And Chaucer complained "the lyf s
o short,
the craft so long to lerne."
Here's my recipe for programming success:
Get interested in programming, and do some because it is fun. Make sure
that it keeps being enough fun
so that you will be willing to put in ten years.
Talk to other programmers; read other programs. This is more important than
any book or training
course.
Program. The best kind of learning is learning by doing. To put it more
technically, "the maximal level
of performance for individuals in a given domain is not attained
automatically as a function of
extended experience, but the level of performance can be increased even by
highly experienced
individuals as a result of deliberate efforts to improve." (p. 366) and
"the most effective learning
requires a well-defined task with an appropriate difficulty level for the
particular individual,
informative feedback, and opportunities for repetition and corrections of
errors." (p. 20-21) The book
Cognition in Practice: Mind, Mathematics, and Culture in Everyday Life is
an interesting reference for
this viewpoint.
If you want, put in four years at a college (or more at a graduate school).
This will give you access
to some jobs that require credentials, and it will give you a deeper
understanding of the field, but if
you don't enjoy school, you can (with some dedication) get similar
experience on the job. In any case,
book learning alone won't be enough. "Computer science education cannot
make anybody an expert
programmer any more than studying brushes and pigment can make somebody an
expert painter" says Eric
Raymond, author of The New Hacker's Dictionary. One of the best programmers
I ever hired had only a
High School degree; he's produced a lot of great software, has his own news
group, and through stock
options is no doubt much richer than I'll ever be.
Work on projects with other programmers. Be the best programmer on some
projects; be the worst on some
others. When you're the best, you get to test your abilities to lead a
project, and to inspire others
with your vision. When you're the worst, you learn what the masters do, and
you learn what they don't
like to do (because they make you do it for them).
Work on projects after other programmers. Be involved in understanding a
program written by someone
else. See what it takes to understand and fix it when the original
programmers are not around. Think
about how to design your programs to make it easier for those who will
maintain it after you.
Learn at least a half dozen programming languages. Include one language
that supports class
abstractions (like Java or C++), one that supports functional abstraction
(like Lisp or ML), one that
supports syntactic abstraction (like Lisp), one that supports declarative
specifications (like Prolog
or C++ templates), one that supports coroutines (like Icon or Scheme), and
one that supports
parallelism (like Sisal).
Remember that there is a "computer" in "computer science"
;. Know how long it
takes your computer to
execute an instruction, fetch a word from memory (with and without a cache
miss), read consecutive
words from disk, and seek to a new loca tion on disk. (Answers here.)
Get involved in a language standardization effort. It could be the ANSI C++
committee, or it could be
deciding if your local coding style will have 2 or 4 space indentation
levels. Either way, you learn
about what other people like in a language, how deeply they feel so, and
perhaps even a little about
why they feel so.
Have the good sense to get off the language standardization effort as
quickly as possible.
With all that in mind, its questionable how far you can get just by book
learning. Before my first
child was born, I read all the How To books, and still felt like a clueless
novice. 30 Months later,
when my second child was due, did I go back to the books for a refresher?
No. Instead, I relied on my
personal experience, which turned out to be far more useful and reassuring
to me than the thousands of
pages written by experts.
Fred Brooks, in his essay No Silver Bullets identified a three-part plan
for finding great software
designers:
Systematically identify top designers as early as possible.
Assign a career mentor to be responsible for the development of the
prospect and carefully keep a
career file.
Provide opportunities for growing designers to interact and stimulate each
other.
This assumes that some people already have the qualities necessary for
being a great designer; the job
is to properly coax them along. Alan Perlis put it more succinctly:
"Everyone can be taught to sculpt:
Michelangelo would have had to be taught how not to. So it is with the
great programmers".
So go ahead and buy that Java book; you'll probably get some use out of it.
But you won't change your
life, or your real overall expertise as a programmer in 24 hours, days, or
even months.
心情分类
推荐日记
分享排行
