3 ms·

I find there's a lot of hand-waving that goes on when you initially learn something. Just the other day I was talking to a friend about learning programming. I

by cletus 15y ago

I find there's a lot of hand-waving that goes on when you initially learn something. Just the other day I was talking to a friend about learning programming. I said to him that I'm quite capable of teaching someone who knows the basics of programming more as long as there's the initial foundation to build on but I'll be damned if I know how to teach someone who doesn't know how to program at all how to program. I don't even know how I learnt to program. I was a kid at the time and I guess I basically just typed in programs from books and then played around with them. I guess this model largely follows the idea of direct instruction [1]. It's one reason I like Zed Shaw's Learn Python the Hard Way [2] because it starts by just saying "type this in... actually type it don't copy and paste it" because for beginners this approach actually works (well). One thing I find interesting is that many non-programmers I know are afraid to just start pressing buttons and messing around with stuff to get the computer to do what they want. They want to know how to do it before they start. I think this fits in with the theme of direct instruction as I've learnt the behaviour of doing something without knowing exactly what will happen. Without this willingness to try (fail) your ability to learn seems to be incredibly impeded to the point of being near-impossible (IMHO). To bring this back to understanding your tools I would say I follow this pattern: - If I can, I'll learn just enough to get by; - I'll slowly accrue new techniques and knowledge as time goes by and I use it (studying this kind of thing without needing to use it is virtually useless for me); and - For things that are most key to what I do I'll expend time and energy delving deeper into them but this applies more to languages, APIs, frameworks, platforms, etc than it does the tool. The tool is, after all, a means to an end not an end in itself. For me I've found learning tools to follow a fairly similar pattern to learning (human not computer) languages: I can try and memorize things all I want but I seem to have this base rate at which I will accumulate "instinctive" knowledge that is a function of how much I use something with very little variation up or down. YMMV. [1]: http://en.wikipedia.org/wiki/Direct_instruction http://en.wikipedia.org/wiki/Direct_instruction [2]: http://learnpythonthehardway.org/ http://learnpythonthehardway.org/

bediger 15y ago
You may be interested in "The Camel Has Two Humps": http://www.eis.mdx.ac.uk/research/PhDArea/saeed/paper1.pdf http://www.eis.mdx.ac.uk/research/PhDArea/saeed/paper1.pdf and other work by Saeed Dehnahdi: http://www.eis.mdx.ac.uk/research/PhDArea/saeed/ http://www.eis.mdx.ac.uk/research/PhDArea/saeed/ He thinks that only about a third of the populace can learn programming at all, and that may be the difference between teaching someone who knows the basics of programming vs teaching programming to a non-programmer.
- 0x12 15y ago
  That paper has done a lot of damage. I also think that if you write a paper like that, that it should include a lot of qualifiers as to what you think you've discovered and what research might be done in order to validate/disprove your findings. Broadly binning a large part of the population as far as a fairly basic ability is concerned (the ability to instruct another entity, which is the essence of programming) based on some extremely flawed tests is not the way science should be done. Try the 'test' they give to people on a population and then try this test on another population of similar size and observe the difference: move 10 to a move 20 to b move contents of b to a The fact that programmers use '=' in a way that non-programmers would never use it should not be part of any 'aptitude' test. That's just syntax and it would give anybody with even a cursory knowledge of programming a huge advantage. Even just the assumption that statements are to be executed in a particular sequence greatly affects the outcome of tests like this and you may have to specify such a thing up-front if you expect people to be on a level playing field. Note that I'm not saying that the conclusion of the paper is wrong, I simply object to the hidden assumptions behind the design of the test. Removing those assumptions would be pretty tricky thing to do with 100% accuracy, and in the end the conclusions reached in the paper might still stand (but I doubt that they would be the same in magnitude).
  - aangjie 15y ago
    ///Even just the assumption that statements are to be executed in a particular sequence greatly affects the outcome of tests like this and you may have to specify such a thing up-front if you expect people to be on a level playing field. I was guilty of forgetting this in a programming interview and gave an answer from algebra.Needless to say interview went downhill very soon.
  - william42 15y ago
    But the predictor isn't whether the testee gets these problems right. The predictor is whether the testee uses a consistent mental model for the problem--that is, someone who interprets "a=b" as "move contents of a to b" will end up programming as well as someone who does the converse, but not someone who picks and chooses without being sure.

by cletus 15y ago

bediger 15y ago

You may be interested in "The Camel Has Two Humps": http://www.eis.mdx.ac.uk/research/PhDArea/saeed/paper1.pdf http://www.eis.mdx.ac.uk/research/PhDArea/saeed/paper1.pdf and other work by Saeed Dehnahdi: http://www.eis.mdx.ac.uk/research/PhDArea/saeed/ http://www.eis.mdx.ac.uk/research/PhDArea/saeed/ He thinks that only about a third of the populace can learn programming at all, and that may be the difference between teaching someone who knows the basics of programming vs teaching programming to a non-programmer.

0x12 15y ago
That paper has done a lot of damage. I also think that if you write a paper like that, that it should include a lot of qualifiers as to what you think you've discovered and what research might be done in order to validate/disprove your findings. Broadly binning a large part of the population as far as a fairly basic ability is concerned (the ability to instruct another entity, which is the essence of programming) based on some extremely flawed tests is not the way science should be done. Try the 'test' they give to people on a population and then try this test on another population of similar size and observe the difference: move 10 to a move 20 to b move contents of b to a The fact that programmers use '=' in a way that non-programmers would never use it should not be part of any 'aptitude' test. That's just syntax and it would give anybody with even a cursory knowledge of programming a huge advantage. Even just the assumption that statements are to be executed in a particular sequence greatly affects the outcome of tests like this and you may have to specify such a thing up-front if you expect people to be on a level playing field. Note that I'm not saying that the conclusion of the paper is wrong, I simply object to the hidden assumptions behind the design of the test. Removing those assumptions would be pretty tricky thing to do with 100% accuracy, and in the end the conclusions reached in the paper might still stand (but I doubt that they would be the same in magnitude).
- aangjie 15y ago
  ///Even just the assumption that statements are to be executed in a particular sequence greatly affects the outcome of tests like this and you may have to specify such a thing up-front if you expect people to be on a level playing field. I was guilty of forgetting this in a programming interview and gave an answer from algebra.Needless to say interview went downhill very soon.
- william42 15y ago
  But the predictor isn't whether the testee gets these problems right. The predictor is whether the testee uses a consistent mental model for the problem--that is, someone who interprets "a=b" as "move contents of a to b" will end up programming as well as someone who does the converse, but not someone who picks and chooses without being sure.