
How do you learn? - abstractbill
After reading a codinghorror article I came across this in a comment:<p><i>Good programmers also figure out their best method of self-learning. I'm one of the oddballs that reads the entire manual.</i><p>That struck me as interesting.  I know I learn in what's probably quite an unusual way.  I'd be interested to know how other people here learn.<p>I teach myself new stuff in a <i>very</i> exploratory way.  For each of the new languages I've learned since starting at justin.tv I've spent probably five or ten minutes learning the syntax.  Then I jump in and start writing a real program that needs to be released within a week or so.  I usually start by writing a "hello world" program, and just add stuff to that until it does what I want (of course, as I learn new tricks I frequently <i>remove</i> a bunch of stuff).  If the language has a REPL I use it constantly.  If not, I fake it by just printing expressions in my program, and working in a tight loop of editing and running the program again and again to see how the output changes.<p>I rarely use a reference at this stage unless it's to achieve something concrete.  For example, I find myself googling things like "actionscript string search", but only <i>after</i> trying a couple of likely-seeming things myself (i.e. I'll actually just write things like trace("foobar".find("bar")) and trace("foobar".index("bar")), etc until the compiler stops whining or I run out of things to try).<p>Funnily enough, after I've written a real program that works, and I feel like I understand the language a bit, <i>then</i> I go back and read the reference books thoroughly.  It doesn't work the other way for me - I need to have had the exploratory phase and built up some context so that I can read the books properly (and it's fun to read the books at that point and remember how I "discovered" each feature that's discussed).
======
wallflower
I was trying to learn Salsa dancing by watching videos on the train. That
really didn't work and in fact was counter-productive. Weekly lessons here and
there helped but I really didn't start climbing up the pretty-steep Salsa
learning curve until I started messing up on the dance floor dancing with
random women. You can't simulate experience and the hardest thing was getting
started (and continuing). I think you learn by taking on new experiences (if
you do the same thing at work every day, you're bored and not learning).

Programming is similar. We make mistakes and brute-force our way through. We
start to recognize patterns. That's experience. It's a lot easier however
(even though it's all in the head) to do fail in something if it's only you
and the compiler/runtime (who cares if it doesn't work right away, you know it
will) - when other people are involved, it's a lot harder (fear of what people
think)

~~~
jamesbritt
> Weekly lessons here and there helped but I really didn't start climbing up
> the pretty-steep Salsa learning curve until I started messing up on the
> dance floor dancing with random women.

I wonder if the adrenaline and stress makes a big difference. For example,
I've been trying to improve my German for roughly forever, trying assorted
books and CDs and such, but the best results have come from going to a weekly
class.

Even without (much) studying I learn all sorts of things, and I think it's
because I'm put on the spot to read things, conjugated verbs, make up
sentences, and so on.

All of the real-time pressure (though, really, it's fun overall) seems to make
a big impression on my brain.

Now I need to try speaking German to random women. :)

~~~
wumi
A friend once said it to me best

desire > ability

There's obviously no better way to learn then to immerse yourself in the
culture, but you'd be surprised how many friends come back from a year abroad
and have minimal gains.

to learn a language, try every time you meet someone in German, or even using
online dictionary, spend 30 minutes talking/ asking questions/ writing down
how to say that.

review it every day for at least an hour

learning a language takes a ton of diligence, and I've found that I often
forgot what I learned if I didn't repeat it every single day for a good bit of
time

soon, your mind will begin to think in the language ( a scary thought for me,
a mono-lingual speaker at birth)

~~~
ced
In my experience (and my teacher's), vocabulary is the biggest obstacle to
understanding and being understood. I'm learning Turkish now, and I'm trying
to do 40 words/day. It turns out, in the languages I know, you can usually
follow

Subject + verb infinitive + object

and people will understand. Of course, grammar is important, but I hate it
when I have to say "he is very good" instead of "he is quite good" because I
don't know the right word.

I've heard that you need 3000 words to be reasonably comfortable in a
language. With 40 words/day, that's still 3 months, which should be enough to
pick up grammar if you actually talk to people and study a bit on the side.

------
axod
I agree (Probably because I grew up with abstractbill hacking on the same home
computers ;) ).

Tip the lego out and play around with the interesting gears and see what you
can do. Throw away the manuals that tell you how to build exactly the same car
that everyone else is building - obviously skim through them, or look at them
every now and then to see how things can fit together. Sure find out from
somewhere how a differential gearbox works, then play around trying to build
one.

I like to have _the_ manual for reference - 'The definitive javascript', or
the ARM7 manuals or whatever reference is needed, and sometimes dip into those
in the bath or before bed. But 'learn the language' books don't seem to make
much sense to me.

Exploring is so much more fun than "designing using approved methodologies
like everyone else is, using the same framework/libraries as everyone else
is". IMHO you're likely to end up with a far better result as well.

I just don't understand people who don't have that tight feedback loop. People
who write a program from scratch in one or two hits, then execute it. That's
like recording yourself playing a piano concerto with earplugs in, then
listening back to see if it sounded ok. Better to have the feedback earlier so
you can adjust.

~~~
abstractbill
Your analogies are improving - these ones are _much_ better than the one about
a car with a wooden chassis ;-)

~~~
curi
Be nice.

~~~
abstractbill
I'm his brother - it's my job to take the piss ;-)

I was serious though actually - these analogies do ring true for me.

~~~
icky
> I'm his brother

He ain't heavy? ;-)

------
Xichekolas
I learn by modifying.

I think just about every language I have mastered has been because I started
learning it by hacking on someone else's code. (mastered = know well enough to
implement projects from scratch with ease) I would say I 'know' probably a
dozen or more languages enough to read/write useful code, but have only
mastered maybe five... and all of those because I spent a lot of time dealing
with existing code, so I learned by toying with it. Sadly if I don't use
something for quite a while (like Scheme, which I used to live and breathe,
but haven't used in probably three years), I become pretty rusty with it, but
I suspect this is normal.

My current languages of choice are probably Ruby, JS, and Arc (for the fun
factor). I actually learned ruby because I didn't like Rails, and tried for a
while to write my own framework, before discovering Merb and tinkering with it
instead. JS always scared me for some reason, but I finally picked it up
because I wanted to use jQuery and ended up tracking down bugs in their UI
stuff. Arc I am learning currently, just by playing with stuff submitted by
others.

So in short, I learn by modifying other code, and eventually get comfortable
enough that I can just write from scratch. I actually like the book examples,
because they put the finished code online. I don't even bother reading the
chapter where they explain the code... I just load it up and start tinkering
and learn from that.

~~~
xirium
Leveraging existing code is an undervalued skill. It gives satisfaction when
you're learning. It also gives immediate benefit to the programmer and other
users.

"Hello world" is great for set-up of your development environment, but after
learning a few basic structures, you'd get great benefit from just wading into
an open source project. Should you learn more theory before you get
overwhelmed by the size of a codebase? No. Nowadays, many paid programmers are
unaware of recursion and quicksorts but it doesn't stop them earning very good
salaries.

~~~
Xichekolas
As far as learning languages go, I agree, knowing how to write a quicksort
doesn't help you learn Language X. When people talk about learning languages,
I assume they mean learning the syntax/idioms. For that, it makes sense to
look at a lot of existing code (to me at least).

When it comes to actually implementing something substantial (once you are
past the tinkering and learning stage), I find it sad that so many programmers
can actually get away with _not_ knowing basic things like recursion and how a
quicksort works (and I have worked with quite a few like this in the past).

I had a guy argue with me that his sort (which was basically a selection
sort), was faster than the quicksort/mergesort I was suggesting because "it is
fewer lines of code and therefore fewer machine operations". Apparently to
him, being able to read and understand it faster meant the computer would
likewise do less work. Sadly, he was my boss, and I knew then I should be
moving on.

Most languages today will do mundane things like sorting for you, but I still
argue that knowing why Tail Recursion is the preferred way to recurse and how
nesting loops can get out of control are vital to do anything useful. I would
rather interviews ask theoretical questions like this instead of silly "can
you regurgitate the syntax to do Y in Language X?" questions.

------
benmathes
Like many other people here I learn in an evolutionary manner. I dive in, get
something working, reflect, notice pattern(s), try and get more working,
recurse. However, I tend to like to seed my evolutionary exploring with some
canonical knowledge first.

For example: When I was learning Perl, I first read about "make repetitive
tasks easy", "good text processing", and then got hacking. When I was learning
Lisp I read about macros, recursion, list-processing, and then got hacking.

------
pistoriusp
I was a PHP developer for six years. I also learned by writing "real world"
applications, except I almost always kept my browser open using the manual as
a reference.

Then I found Python and Django. Now I just kinda type... 7/10 times I'll get
it right, which is a great feeling! I also read a lot, and often find little
gems in books that I wouldn't have picked up as quickly by tinkering.

------
mwmanning
This is almost exactly the way I learn. After years of doing it the
"traditional" way (ex. reading an entire book on a language), I realized that
I was mostly wasting my time. The only way to really learn is to try to solve
a real problem that you will benefit from directly. Book exercises are boring
and will ruin your motivation.

I think the idea of staying in a tight edit/test loop is good too. I tend to
make lots of typographical/syntax errors that can be a nightmare to debug if
you're having to scan many lines of newly written code. If you're only writing
a few lines at a time and then testing, finding errors is much faster.

~~~
mechanical_fish
_Book exercises are boring and will ruin your motivation._

I would agree with you about 95% of the computer books on the market. But, if
you find the shortest and least pedantic books, they can be really helpful.

Greenspun had a fun rant about how book publishers insist on producing
gigantic doorstopper books in the style of _Learn Blub in 21 Days_ \-- 850
pages, only about 150 of which are actually useful, and the rest of which
consist of tedious examples and filler material and stdlib documentation which
you'd much rather just look up online when you actually need it. He argued
that, e.g., Cooper's _About Face_ was a good 125-page book trapped in the body
of a 600-page book.

Of course, I've already admitted on this thread that I haven't really read
K&R, so I can't speak from experience, but I've heard it said that K&R is the
essence of a great language book: it's _short_. It doesn't feel the need to
seem heavy in order to seem important.

~~~
xirium
> _Learn Blub in 21 Days_

I find these books really objectionable. They propagate bad practice and
minimal understanding. Furthermore, the type of people who need to _Learn Blub
in 21 Days_ are in headless chicken mode - they've got less than 21 days and
they don't RTFM.

Another objection is the cookie-cutter approach to the teaching which may work
for some but frustrates if you want to understand underlaying rules. If I had
21 days to learn French, then I'd start with the grammar. This phrase-book
approach to programming gives you 20% of the benefit after exerting 80% of the
effort. The 80-20 rule is suppused to work the other way. You're supposed to
get 80% of the benefit from 20% of the effort.

> K&R

I read some of the first edition of K&R and I found it enlightening because
they'd written it for the benefit of other C compiler writers. Furthermore,
the first edition is a snapshot during development and they're quite candid
about unfinished features. It also gives tips on programming style. Ignore
these tips and you'll discover the cost later.

------
mechanical_fish
My style is different, of course. :) I tend to learn new things by reading, or
at least skimming, the best book I can find, first. I like having an overall
perspective on the scene before getting into the weeds.

For Scheme, I read SICP, of course. For Java and C++, Bruce Eckel. For Ruby,
_Why followed by the Pickaxe. For Emacs, I read _Learning Emacs_ , a very good
book. I even learned Perl from a book, although not the Camel book, which is
torture to read -- I used Randal Schwartz's _Learning Perl_ , which was very
good. I learned CSS by reading Eric Meyer's O'Reilly book, pretty much cover
to cover, as well as Dan Cederholm's book. I learned SQL (and Tcl as well)
from Greenspun's books (e.g. _SQL for Web Nerds_ ) which weren't really
dedicated and pedantic SQL tutorials but were, in a way, much more useful.

Of course, I'm the guy who got bored with BASIC as a kid and decided to teach
himself Pascal. So I read a few books on Pascal. Unfortunately, we didn't own
a computer at the time, and the library didn't have a Pascal compiler, so I
didn't get to compile a Pascal program until two years later. So maybe I just
got into that habit early and never really lost it.

Of course, you can't actually learn a language from a book. You have to
practice a lot to get the syntax and the semantics and the idioms into your
fingers. So it's just a question of whether you do the reading first, or
second.

There are quite a few exceptions to my usual rule. I know a bunch of C, but I
never read a really _good_ C programming book. Of course, that means I get to
look _forward_ to K&R, which is nice. :) I probably learned as much Perl from
randomly hacking as I did from _Learning Perl_. I still haven't gotten far
through _Mastering Regular Expressions_ , though I've used them for years. I
have yet to find a really great book on PHP (to everyone's astonishment, I'm
sure) -- the O'Reilly book is okay, but I keep getting bored. And for some
reason I cannot make myself read any docs for jQuery. It's so _sensible_ that
I can't concentrate on the docs; it feels like a language that I already know!

Technology is changing things. I normally hate learning from lectures --
talking is just too slow, and you can't skim it -- so I was surprised to
discover that podcasts and screencasts about programming are actually quite
useful. There are aspects to being a good programmer that are best learned by
watching over someone's shoulder, or listening to them ramble on about their
most-favored and least-favored tools. And then, you know, there are blogs and
news.yc.

~~~
pchristensen
I love screencasts/videos to help "get" a new tool. Examples:

Ruby on Rails screencasts: <http://www.rubyonrails.org/screencasts>

SLIME movie: www.cl-user.net/asp/web-sites/slime-video

Peepcode - <http://peepcode.com/> (RoR topics)

The SICP movies (very long, ~30 hrs total) take forever but they are so rich
there's not much temptation to skim.
[http://swiss.csail.mit.edu/classes/6.001/abelson-sussman-
lec...](http://swiss.csail.mit.edu/classes/6.001/abelson-sussman-lectures/)

------
jimm
I learn by doing, like abstractbill does.

One thing I've come to understand: you only learn when you are asking
questions. Reading a book doesn't put you in the frame of mind where you're
asking questions. You are being spoon-fed information, sometimes before you
know why you need it. The information might be useful or vital, but if you
don't know you need it or why you need it then it won't stick.

------
kajecounterhack
Yeah learning by doing is good and prolly I'm guessing the most common way
people begin with programming.

Teachers can present angles you don't think of yourself though, so sometimes
its important to get other opinions whether it be from other programmers or
whatever. I know that even after programming a ton I learned a lot from a
simple intro to compsci class.

------
tjr
I too find that the best way for me to really learn a programming language is
to use it, though I do begin by reading documentation.

First, this familiarizes me with the language constructs, what is and what
isn't available, and I can build up a "mental diff" of how this new language
is or is not like other languages I already know.

Perhaps more importantly, it also gives me a clue as to if I should bother
spending my time to really learn the language well. For example, I've tinkered
with Ruby, and read some Ruby documentation. It appears to be a fine language,
but I don't see it offering me anything that I find lacking from Python or
Lisp. So I've never taken the time to become expert with Ruby.

------
yozef
Hah!

You make it sound so familiar with I'm passing through. I love Flex and it's
potentials!

------
henning
I'd love to be someone who could sit in a state of trance and consume 500
pages of boring reference manual and immediately put all of that into action.
But I'm not.

I have to have something practical, something that I want to use either
personally or at work. And at first it has to be pretty simple. If there is no
low-hanging fruit to explore I'll probably get bored and move on (i.e., fail).

I like to learn about the right way to do things in my given environment and
am terribly afraid of people with more experience than me seeing my code and
mocking it.

------
edw519
My experience has been that learning new programming languages from the manual
is not very effective. I like to read the overview (theory, executive summary,
what's different), but after that I just want to code something.

Whenever I have trouble figuring out how to do something, THEN I refer to the
documentation.

Maybe I do it this way because I have never met a language that didn't have 10
times as much stuff as I needed.

------
dgabriel
I learn by reading the FAQ, leaping into the deep end with some stupid
project, and then repeatedly harassing people who are smarter than I am.

------
Hexstream
I used to be a "read the reference manual in full first" guy, but I was cured
of that when I tried to read the whole manual for GNUS.

Also, when you use a "obscure" language like lisp the documentation is often
subpar/incomplete/obsolete/lying/whatever so sometimes the best it can bestow
is a false sense of knowledge (which fortunately is somewhat useful to get
started).

~~~
tjr
You find Lisp documentation subpar/incomplete/obsolete/lying? Maybe for a
given implementation of Lisp, but for the languages themselves, I have found
Lisp documentation to be some of the best written that I've seen...

~~~
Hexstream
I knew I should have specified I was talking about some of the librairies, not
the language itself. :|

~~~
tjr
Ah, well, carry on, then, carry on. :-)

------
ice5nake
I jump right into coding, although I don't like shells too much. I like
Googling for tutorials and using language APIs. That's probably why I like
Ruby and PHP being they are compiled at runtime. Been getting into frameworks
lately. I like it when someone else has done the heavy lifting.

------
emonk
I believe that the best way to learn is from de oficial/owners documentation
or reference; and reading a lot.

Nobody can teach or no mechanism is a good thing if you are not willing to
learn and likes it .

So... what is the best book to learn python? :D

~~~
olifante
That's easy: Learning Python 3rd Ed. by Mark Lutz.

~~~
emonk
nope, www.diveintopython.org

~~~
ardit33
nope, learning Python is much better. It is a really good book that teaches
you even what's going behind the scenes in python. Diveintopyhon is good if
you have no patience, but you probably will miss a lot things that "learning
python" explains, especially if you are new into scripting languages (I came
from Java, and some php experience).

Take a week and a half of time, two hours a day, and read it. Meanwhile make
sure you practice some in your own, and then start a small real project, so
you can actually start imprinting what you learnt.

------
bfioca
Trial and error. I'm a tinkerer. I learn just enough to get me going, and then
I tinker with everything until the rest comes. Seems more efficient, but
sometimes I miss out on some fringe things.

------
matbis
" Sell all the old books, invest in new books ", " Sell all the old books,
invest in new books ", " Sell all the old books, invest in new books " >>
chant

------
sabat
I'll go out on a limb and suggest that reading something in order to learn it
will always fail: you're trying to understand something exactly the way
someone else does, and that's impossible.

Also, learning is like birth and death: there might be other people in the
room, but you do it alone. Learning is an experience, not the result of
reading something. You can understand what you read, but understanding an idea
!= learning.

~~~
bouncingsoul
Related to what you're saying, I think, is what's on the back of _The Little
Lisper_ regarding its question-and-answer presentation versus the expositional
presentation of normal textbooks:

 _Reading a conventional textbook with expositions followed by problems may
keep the reader a passive follower of the displayed line of reasoning._

What is wrong about passive reading?

 _It is not always wrong, of course. It can be quite relaxing, but passive
reading does not invite the reader to think over the twists of reasoning he
may be inclined to. This reflection is necessary in order to doff the wrong
twists and to fully appreciate the line of reasoning of the authors._

------
curi
In a general sense, all people learn in the same way, and would do well to
remember this.

In particular, learning -- creating knowledge -- consists of creating
something complex (an idea in your own head) that didn't already exist.

How complexity could come about is a famous question. The original answer was
via a designer, but that begs the question, because either the designer
already contained the complexity in question, or had to create it (somehow).

But now we have a better answer: evolution. And that is how people learn.

Evolution consists of imperfect replication and selection. In thinking terms,
what you have to do is think of lots of ideas, subject them to criticism, and
then think of (hopefully improved) variants of the surviving ideas, then more
criticism, repeat, etc

This is important to know because being open to criticism is more important
than people realize. It's generally considered a good character trait, but it
is in fact absolutely fundamental to learning anything.

~~~
dmoney
> learning -- creating knowledge -- consists of creating something complex (an
> idea in your own head) that didn't already exist

This reminds me of The Programmer's Stone:
<http://www.reciprocality.org/Reciprocality/r0/> which talks about "mapping"
and "packing" as two different ways people learn. The authors found it easy to
teach programming to those that tended toward mapping--building a mental map
of a subject rather than accumulating facts about it.

~~~
curi
kind of interesting. but i don't think the main point that people think in one
of two different ways, is correct. one reason is it's very hard to find a
person who thinks well in most areas. partial mappers are much more common
than consistent mappers.

~~~
dmoney
It's probably more useful to think of mapping/packing as skills rather than
types of people. But then you can't claim that all those evil packers are
oppressing you.

~~~
curi
That's OK, I didn't want to be a victim anyway :)

