How do you learn?
54 comments
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)
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)
> 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. :)
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. :)
I was stuck in a German harbour alone for around 2 weeks two years ago, as my boat's engine had failed and needed repairs. Since I had nothing better to do I decided that I would try to learn as much German as possible. So I basically just started talking to strangers...
After two weeks I could actually survive through a conversation. When I started I knew no German at all.
After two weeks I could actually survive through a conversation. When I started I knew no German at all.
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)
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)
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.
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.
You spoke at birth?
The salsa dancing parallel reminds me of learning to snowboard - I signed up for a week long trip through a group at my school and took lessons the first day on the mountain. Before embarking, I had read a bunch of articles on how to snowboard and tried to commit all the information to memory. So I got out there and tried to apply my knowledge to little avail. At the end of 5 days, my knees made the nurse in our group cringe. I was absolutely battered head to toe. Then I went home and read as much as I could find over the next year and went back. Much to my amazement, things came together; I was suddenly and surprisingly decent.
I think this same kind of learning process applies to anything that you really have to understand to get good at. Many things have two levels of understanding: most people can drive, but who really understands how the transmission works? Those are the people that are able to truly control a vehicle, and they probably drive manuals.
I think this same kind of learning process applies to anything that you really have to understand to get good at. Many things have two levels of understanding: most people can drive, but who really understands how the transmission works? Those are the people that are able to truly control a vehicle, and they probably drive manuals.
I learned to dance salsa a couple of years ago with my ex-girlfriend, it just takes a lot of practice, and is much better if you have a good teacher.
Some alcohol might help too :P.
Learning is not hard, unless you're studying something that you don't like, for example years in school when I started studying Logic it was a real pain. Later when I started learning statistics I figured out that logic is awesome, and is the basis of many many things.
Learning is not hard, unless you're studying something that you don't like, for example years in school when I started studying Logic it was a real pain. Later when I started learning statistics I figured out that logic is awesome, and is the basis of many many things.
We learn more through our mistakes than our successes. And now there's research to prove it:
http://www.sciam.com/article.cfm?id=mom-was-right
Sorry about the paywall, but you can get the gist from the summary.
http://www.sciam.com/article.cfm?id=mom-was-right
Sorry about the paywall, but you can get the gist from the summary.
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.
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.
Your analogies are improving - these ones are much better than the one about a car with a wooden chassis ;-)
Be nice.
I'm his brother - it's my job to take the piss ;-)
I was serious though actually - these analogies do ring true for me.
I was serious though actually - these analogies do ring true for me.
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.
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.
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.
"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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
> 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.
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.
> K&R is the essence of a great language book: it's short.
s/book//
s/book//
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.
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.
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...
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...
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.
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.
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.
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.
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.
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.
Hah!
You make it sound so familiar with I'm passing through. I love Flex and it's potentials!
You make it sound so familiar with I'm passing through. I love Flex and it's potentials!
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.
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.
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.
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.
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.
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).
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).
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...
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.
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
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
That's easy: Learning Python 3rd Ed. by Mark Lutz.
nope, www.diveintopython.org
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.
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.
There are probably other good ways to learn as well. I find that working on a problem you have (or have implemented before in a different language) is a good way to pick things up quickly.
I agree, resolving problems, most of the time is where you start to learn; but eventually all roads will lead to the ofcicial source/reference.
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.
" 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
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.
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.
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.
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.
I say your limb breaks ... although I like your thought pattern
I'll say this, if you've had a teacher , don't they teach you the way they see it?
Reading a book does nothing to force you to think or understand something the way someone else does: why else can you watch the movie of a book you've already read and say "I imagined that differently"
Reading has been used for learning for thousands of years, if only as a tool for greater discussion
I'll say this, if you've had a teacher , don't they teach you the way they see it?
Reading a book does nothing to force you to think or understand something the way someone else does: why else can you watch the movie of a book you've already read and say "I imagined that differently"
Reading has been used for learning for thousands of years, if only as a tool for greater discussion
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.
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.
> 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.
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.
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.
Good programmers also figure out their best method of self-learning. I'm one of the oddballs that reads the entire manual.
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.
I teach myself new stuff in a very 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 remove 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.
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 after 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).
Funnily enough, after I've written a real program that works, and I feel like I understand the language a bit, then 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).