Nothing "makes" you learn anything!

So, buy lots of "nothing"!  : )

--
Regards,
Casey

I see the smiley...

It depends on what you are looking for.  For the subjects the OP mentions, I
don't think that resources other than books are any real use at all.

That is /terrible/ advice.  If Saif were addressing a class of post-graduate
students then it would have made some sense (especially as they would probably
be too poor to pay for books, so saying "don't" would be a good way to grab
their attention).  But for a well-established field like basic CS algorithms
and design techniques, the valuable stuff was worked out decades ago (more than
half a century in many cases), and the relevant stuff simply won't be /in/ the
"latest research papers and journals".

Also, the papers -- except for the occasional review paper -- don't even
attempt
to give a balanced overview of a field (or subfield).  So even if you are
working in one of the areas where the important stuff is still under active
research (and there are plenty of those); the working programmer who just wants
to get a job done this week rather than make a multi-year study of the
available papers, will find it very difficult to "navigate" the field to find
the results which are /actually/ relevant to the job at hand.

   -- chris

What I liked about the beginning MySQL book was that they started by
talking about normalization.  I had that in my college text books (long
since sold back) but it was nice to see someone try to start from first
principles.

Good point about non-standard extensions, that could trip somebody up.

And yes, you have to specify the engine, be the default one is pretty bad.

[me:]

I think that must be it.  Of course, you start to gain experience the minute
you first even think about how to write your very first program; and every time
you write a line of code, or read a line of someone else's code, you are
gaining experience and putting in the practise.

Naturally, if you are in a position to write moderately substantial programs
(ones big enough that you can see design /options/ and think about which is
best and why) then you'll learn faster.  Similarly if you work with existing
designs (good designs, that is ;-)

(As an aside, why do so many shops insist on putting beginner programmers --
ones without a practised design sense -- onto maintenance work ?  When (a)
their lack of design intuition will mean they are likely to miss the existing
design (and thus fail to follow it in their replacement code), and (b) it is
putting then in a poor position to /gain/ a design intuition.  It seems dumb to
me -- maintenance is a /skill/ and if a person can't at least design and write
new code (under some supervision) then s/he is likely to make an unholy mess of
changing existing code.)

   -- chris