Good books in computer science?

[Steven D'Aprano]

Graham Ashton wrote:

> On 2009-06-14 14:04:02 +0100, Steven D'Aprano
> <steve at REMOVETHIS.cybersource.com.au> said:
> 
>> Nathan Stoddard wrote:
>> 
>>> The best way to become a good programmer is to program. Write a lot of
>>> code; work on some large projects. This will improve your skill more
>>> than anything else.
>> 
>> I think there are about 100 million VB code-monkeys who prove that theory
>> wrong.
> 
> Really? So you don't think that the best way to get good at something
> is to practice? 

Shame on you for deliberately cutting out my more serious and nuanced answer
while leaving a silly quip. As I went on to say:

"... you can program by (almost) mindlessly following a fixed number of
recipes and patterns. This will get the job done, but it won't make you a
good programmer."

There are huge numbers (millions?) of lousy programmers who program every
single day and never become good programmers. "Practice makes perfect" only
works for mechanical skills and rote learning, neither of which are
especially applicable to good programming. (Although rote learning is
helpful for reducing the time taken to look up syntax and library
functions.) Without some level of understanding and creativity, as soon as
you hit a problem that can't be efficiently solved by one of the patterns
or recipes you've learned, you're in trouble.

All the practice in the world won't give you the discipline to write
appropriate comments, or to test your code thoroughly. Practice won't
*necessarily* make you creative -- you can't be creative in a field you
know nothing about, but having learned the language and the libraries
doesn't necessarily mean you can apply the tools to solve novel problems. 
Many programmers know a few good tricks, and try to hammer every problem
into a form that can be solved by one of the few tricks they know, no
matter whether it is appropriate or not. Witness how many people try to
write regexes to parse bracketed expressions, a problem which requires a
proper parser.

(This is not necessarily a bad thing, but it often is.)

You could write a piece of code like:

s = ""
for word in some_data:
    s += " " + word

a thousand times a day, and *never* learn that this is Bad Code, because you
never profile it with more than a few thousand words and so never discover
that it's O(n**2). Eventually when it gets released into the real world,
somebody reports that it takes eight hours to process 100MB of words, and
then *some other guy* re-writes your code to use s = " ".join(words), and
you remain in blissful ignorance, happily writing your bad code every
single time.



> I think I'm paraphrasing Richard Feynman here, but the 
> only way to truly understand something is to do it.

An amazingly inappropriate quote for a *theoretical* physicist to have said.

Whether Feynman did or didn't say that, it's clearly untrue: many people do
without understanding. Many people can cook, some people are expert cooks,
but few people understand precisely what takes place when you cook food.
People can catch and throw balls, and have little or no understanding of
gravity, air-resistance, and the mechanics of their own bodies.

In fact... just before you hit Delete on this post, how about you explain
*how* you make your finger reach out and press the Delete key? You probably
move bits of your body a million times a day, and the chances are very high
that until now, you've never once noticed that you have no idea how you do
it. I think that simple fact blows out of the water the concept that doing
implies understanding.


> Obviously a bit of guided learning is a major boon, but you can't be
> practice.

I didn't say that practice was useless. Arguably, it may even be necessary
to be a good programmer. (Although less so for an unsurprising language
like Python, where it is very common to write code which works correctly
the first time.) But practice is clearly not *sufficient* to be a good
programmer. 



-- 
Steven