I sort of agree with this. I got my start typing listings from Microhobby[1] into a ZX Spectrum... I was around 5, so I guess a big chunk of my early learning was by osmosis!
Right now, somewhere on the web, someone is writing a blog post about how we should not type things out by hand, why it is a waste of time, how the nature of programming is changing, how the calculator meant that we no longer had to do long division and other contrary points.
Even if you're not literally typing things by hand, having an attitude of "I won't use this code until I understand what each keyword is actually doing" is very useful. As the article says - learn what each word in "public static void main( String[] args )" actually means.
This is the primary reason why old-style Visual Studio Windows programming really freaked me out: you start with a massive template, full of complex-looking code, and you're expected to just ignore it and write your own code in the little marked-out areas. I really like the new approach in C# using partial classes: all you have in your source file is your own code, and it's really easy to see how that maps to the UI that you're building. The rest is under the surface and can be treated as library code.
Someone close to me has been learning to program (self-taught), and this is what I've tried to impress the most, the path to being an intermediate level programmer definitely cuts right through understanding as much as is reasonable about the effects the text you type have.
I think it's also hard for this advice to help certain beginners if they don't know where to stop when they start going for knowledge about what's happening... It's so easy to start looking up keywords and all of a sudden end up being bombarded with terms you understand even less.
If they don't know where to stop, then how they can learn where to stop? The only way, I think, is making errors. It's nothing bad in taking a glimpse of something too difficult to understand. Even failed attempts to understand something too difficult is not bad. The only risk is the loss of motivation because of failure.
So generally I would say that they learn where to stop (or never see the depths of the endless pit that is knowledge in the first place) with the help of a good teacher or textbook.
A textbook that tells you just what you need to know, and just enough of what's happening under the covers to let you think you understand, and solidify what you're learning
I'm a big fan of typing new code. My most recent example was while learning Webpack. You could pick from oodles of pre-existing configuration, but it's meaningless if you just copy and paste it in to your editor.
I normally type something out and then if I can't come up with a moderately reasonable assumption about what it does, then I'll pull up the docs and read about it.
I find that typing things out by hand organizes my brain to focusing on one thing at a time. If I read over a code snippet, I tend to sort of gloss over it; typing it out slows down the thought process a bit so that I can focus on some of the nuance.
This makes a lot of sense. I don't think cut/paste makes anything stick in the head (no pun on "paste"). Maybe this is how my old-fart mind works (I go back to the punched-card days) but I've found that my millennial students also learn more by typing. It's a bit like studying ... using a highlighter can be better than just reading, but to really grasp difficult material, it's important to write things down in your own words/equations.
Integrating multiple senses into the creation of a memory enables better recall later. Which improves understanding as the material being recalled is, well, more easily brought to the fore.
Handwritten notes (even if not reviewed) provide a physical (touch of the paper, movement of the hand) sense to the auditory/visual experience of the lecture. Paper books bring, again, a physical (smell, touch, movement) sense to the act of reading. I've held the same iPad for dozens of books. But I've only held one copy of TaoCP or A Wizard of Earthsea. The hardback covers, the library card, the feel of the worn pages, the smell of the paper, all come together in the mind to create a stronger memory when recalled. This, in turn, is tied to the memory of the contents themselves and so I can recall them with greater ease than from an ebook. Of course an ebook or typed notes offer more than just an audio book (though the experience of a particular road trip tied to the listening will help as much as with the print book) or a lecture with no note taking.
I don't remember which one, but one of the plethora of "teach yourself to code!" guides floating around the web has all of their code snippets as images, so every time you used one of their example programs, you had to type it in by hand. It was horribly annoying (so I stopped,) but it was a deliberate choice to try and force understanding.
Up next week: "The Lost Art Of Rote Memorization".
You see, when I was studying for an amateur radio license, I had a realization. Memorizing page after page of meaningless numbers and acronyms could actually instill a sense of curiousity about what those numbers and acronyms meant. What is a sideband and why does it single? Who is a Hertz? Why would I want to limit third-order distortion to below 0.1% of the principal frequency? You see, nobody had ever told me that it might be good to be curious about the thing I'm doing!
Sorry, this is meaningless drivel. Yes, you should know what the keywords do in a function declaration, but once you are aware of what 'static' means then typing it yet one more time does not help you whatsoever in the least. Yes, you should know know what various delimeters do in your language, but if you're not sure just go look it up, it doesn't make sense to fight it.
The reality is that there are all kinds of things that are best left in reference material. I have the Regular Expression Cheatsheet pinned right next to my desk; I could easily write a regex without it but by having a reference right there I conserve that mental bandwidth for tasks that matter. Pop quiz: which is the code for a word character, \w or \W? Is that something you want to be thinking about while you're also trying to juggle business logic for three other classes?
The same thing applies to all kinds of other things. We have documentation for a reason, memorizing the order of function arguments for a function I only use once a year is a waste of brain space. Some functions have all kinds of quirky behavior that you really need to double-check unless you use it daily - for example, anything in the C stdlib. It's not worth introducing bugs for the sake of avoiding using your IDE.
It's true that for skilled programmers, most of what we do is thinking about how to solve the problem rather than mechanically typing it in. But that's no reason to make the act of typing it in needlessly difficult. Programmers have been using intelligent assist systems for as long as we have had interactive computer systems, dating right back to vi/emacs macros.
These are a good thing: after I've encapsulated fields in getters/setters for my first five classes, the next thousand that I'm going to do over the course of the year buy me nothing, and I might as well let my IDE handle the mechanical act of declaring ten pairs of getters/setters for yet another class.
Perhaps I should've been clearer in the article, but it's aimed at people
learning to program. Absolutely, as a professional, use the tools available to be as efficient as possible. But as a newcomer, relying on tools (and copying jQuery snippets from StackOverflow) too early slows down the learning.
If you don't know what "static" means then sure, that's a good thing to learn because it's an important concept to understand how the code will behave. But a lot of programming stuff is either syntax or just convention/The Way It's Done.
Why is it static void main(argc, argv) in Java? Well, that's the way C did it. Why did C give main() function arguments, as opposed to (say) environment variables? Well, that's just the way it's done. Why is return 0 success and other values fail? Convention. Why are curly braces used to delimit code and parentheses used to delimit arguments? Because the spec authors said so.
Basically, I think most of what constitutes programming can be done without ever typing a line of code. It's the process of decomposing a large task into small, simple ones, in a way that can be processed efficiently. The rest is just notation.
Pedagogy is absolutely fine, but at the same time we all stand on the shoulders of giants. Nobody is writing their own TCP/IP stack, we all rely on "copied and pasted" code (encapsulated in a library) so that we can focus on business logic. Obviously if you don't know what you're doing you can easily cause a mess, but the physical act of typing is probably the least important part of programming. Conceptual understanding is what matters, and the random syntax and half dozen keyword modifiers you will learn by typing are not going to push you very far in conceptual understanding.
> Pop quiz: which is the character code for a word character, \w or \W?
From memory, \w. Conceptually, this is because in regular expressions, capitalization indicates negation. \w matches word characters, \W matches non-word characters, \d matches digits, \D matches non-digits, \s matches whitespace, \S matches non-whitespace.
Having a conceptual understanding helps to be able to extrapolate more information with less memorization.
I don't mean this as a refutation of your overall point; I think your point is correct, that using cheat sheets allows you to save mental bandwidth. I just think this wasn't a great example.
In my opinion, the author's goal was to make a blog post. So he searched around for something like an original thought... and he found a glimmer (merely) of a thought: that hand-typing helps you READ content better than copy&pasting does.
It's more of an observation, actually... An independently repeatable one, sure... :)
Is is indeed more of an observation, and one that's helped me learn, but I won't agree that makes it less useful :) Plenty of beginners (not all, but certainly some) jump to copy&pasting too quickly.
Automate for speed, not for lack of understanding :)
Yeah, morse is a toughie because if you get mentally stuck on a character you will fall behind and start missing even more. But just memorizing the characters isn't enough, you need to be able to mentally relate the sound on the fly. It's really more akin to a language and you need to practice at it.
Honestly what I tended to do was pick up 80% of the characters and fill in the last 20% from context, just like filling in unknown words in a sentence out of context. And much like with foreign languages I was better speaking than receiving.
Touch typing is a bit like knowing where the accelerator, break pedal and gear stick is. Its like knowing the layout of notes on a musical instrument.
Sure you can look down and see where they are. But its just that your brain on enough practice has mapped your fingers to the pattern of what you wish to do. There is very little memory involved in all this exercise.
The bad part about not having this kind of muscle memory is you have will have a whole lot of unnecessary overhead of working out things by sight and coordinating it with hand movements, which is very distracting when you have something requiring very high focus to do on hand. Especially in things like music, timing is everything. Working out things by sight is a straight no-go to even start with.
IDE makes it easy for you to work with complex navigation patterns, whether its bugs or understanding some part of your code or debugging. IDE is a tool designed to make that workflow easy for you. Its not a tool designed to make typing easy. And using tools like to these to avoid learning typing, makes it more hard in situations when you can't find your way out without typing.
> Up next week: "The Lost Art Of Rote Memorization".
Rote memorization is actually very useful; frankly, I think that its abandonment as a pedagogical tool is partially to blame for modern students' appalling lack of education.
Sometimes you gotta recite 'amo, amas, amat' over and over until you've got it right.
I understand the controversy, In my experience, both statements; 'typing it does nothing' and 'typing it is everything' are accurate. Just for different people.
In a similar way, some people don't see music until they play it, some see it before it is played. I really don't know what it is that creates the difference.
For me, doing the typing (or writing in my notebook) really connects the knowledge somewhere in my head that is harder to erase/lose than just reading or seeing it. I discovered in college that I could look at a homework problem and solve it but later in an exam couldn't bring back all the finer points of solving it, unless I had actually written down my solution. Very strange but a good thing to know about oneself.
If he ever worked with a convoluted business and data layer with about seven layers of boilerplate code that needs to be written every time a new feature is added, I doubt he'd still be singing the tune that everything must be typed. Because typing all that is a chore, not a benefit.
But that being said, when learning something new I do tend to type it out myself to help reinforce things. Same reason I handwrote my notes in college.
But I'm not going to type everything all the time. I'll get carpal tunnel, and it'd take me a lot longer to get tasks done.
At the same time, why do we tolerate excessive boilerplate in our systems? Particularly in areas where it offers no measurable improvement in the output, and probably a reduction in quality due to the increased opportunity for error.
When I was 10, I literally taught myself to program by typing out open source projects by hand, looking up the functions I didn't understand as I went.
I truly believe this is one of the best ways to learn.
This reminds me that I once made a stupid game where you type code scraped from random github repos. The goal is to predict the next character that will appear. The premise being that typing real code, and consciously trying to predict what will come next, forces you to quickly learn the syntax and style of a new programming language.
Wow that is a very clever idea! It seems like though that I would get green letters even though I had never made a guess. For example punctuation, e.g. newlines and whitespace and dots, would be green instead of red, even though I'd not typed any character at all. Awesome idea nonetheless!
Oh yes, that was a feature I added. If you don't make a guess, it automatically guesses the most likely next character. You can see in the table to the left what it's predictions are. Which is just the letters most likely to appear after the last letter seen.
Oh, okay, that makes sense, then. So it's almost like I've got a computer partner that's also "learning" the syntax with me? That's actually really clever, because it helps me by demonstrating correct characters that I wouldn't have otherwise guessed. Very cool!
It was originally intended just to be a few hints to make it a bit easier. But I thought it made sense, that if you don't make any guess at all, it might as well guess the most likely character for you, and give you a few free points.
Maybe I'm weird, but I still type things out even when I'm copying them from another place. Except, for example, string values or something in configuration data. But if it's just some code I'm learning, I type it all up. I mean, you're trying to learn it, right?
I am programming for 30+ years and I am still doing this. As mentioned in the article it's a good way to memorize stuff, but it also acts as a checklist: As I re-type each line I make sure I understand what exactly it is doing and whether that's what I want it to do. It's a good way to reduce bug count IMO.
I went through the Rust Mio guide this way, it really helped! Along with learning it better by typing it out, you can compile your code after each line and get better insight into why the code was written the way it was.
53 comments
[ 2.2 ms ] story [ 148 ms ] threadWe handed in our code to the (female) adjunct for review. Run time was expensive. Then we made our deck of run cards.
I used this "write it out by hand first " method during my entire tech career.
For me, writing it out was a really good way to learn (next to actually teaching others)
[1] http://www.microhobby.org/
This is the primary reason why old-style Visual Studio Windows programming really freaked me out: you start with a massive template, full of complex-looking code, and you're expected to just ignore it and write your own code in the little marked-out areas. I really like the new approach in C# using partial classes: all you have in your source file is your own code, and it's really easy to see how that maps to the UI that you're building. The rest is under the surface and can be treated as library code.
I think it's also hard for this advice to help certain beginners if they don't know where to stop when they start going for knowledge about what's happening... It's so easy to start looking up keywords and all of a sudden end up being bombarded with terms you understand even less.
A textbook that tells you just what you need to know, and just enough of what's happening under the covers to let you think you understand, and solidify what you're learning
I normally type something out and then if I can't come up with a moderately reasonable assumption about what it does, then I'll pull up the docs and read about it.
Handwritten notes (even if not reviewed) provide a physical (touch of the paper, movement of the hand) sense to the auditory/visual experience of the lecture. Paper books bring, again, a physical (smell, touch, movement) sense to the act of reading. I've held the same iPad for dozens of books. But I've only held one copy of TaoCP or A Wizard of Earthsea. The hardback covers, the library card, the feel of the worn pages, the smell of the paper, all come together in the mind to create a stronger memory when recalled. This, in turn, is tied to the memory of the contents themselves and so I can recall them with greater ease than from an ebook. Of course an ebook or typed notes offer more than just an audio book (though the experience of a particular road trip tied to the listening will help as much as with the print book) or a lecture with no note taking.
You see, when I was studying for an amateur radio license, I had a realization. Memorizing page after page of meaningless numbers and acronyms could actually instill a sense of curiousity about what those numbers and acronyms meant. What is a sideband and why does it single? Who is a Hertz? Why would I want to limit third-order distortion to below 0.1% of the principal frequency? You see, nobody had ever told me that it might be good to be curious about the thing I'm doing!
Sorry, this is meaningless drivel. Yes, you should know what the keywords do in a function declaration, but once you are aware of what 'static' means then typing it yet one more time does not help you whatsoever in the least. Yes, you should know know what various delimeters do in your language, but if you're not sure just go look it up, it doesn't make sense to fight it.
The reality is that there are all kinds of things that are best left in reference material. I have the Regular Expression Cheatsheet pinned right next to my desk; I could easily write a regex without it but by having a reference right there I conserve that mental bandwidth for tasks that matter. Pop quiz: which is the code for a word character, \w or \W? Is that something you want to be thinking about while you're also trying to juggle business logic for three other classes?
The same thing applies to all kinds of other things. We have documentation for a reason, memorizing the order of function arguments for a function I only use once a year is a waste of brain space. Some functions have all kinds of quirky behavior that you really need to double-check unless you use it daily - for example, anything in the C stdlib. It's not worth introducing bugs for the sake of avoiding using your IDE.
It's true that for skilled programmers, most of what we do is thinking about how to solve the problem rather than mechanically typing it in. But that's no reason to make the act of typing it in needlessly difficult. Programmers have been using intelligent assist systems for as long as we have had interactive computer systems, dating right back to vi/emacs macros.
These are a good thing: after I've encapsulated fields in getters/setters for my first five classes, the next thousand that I'm going to do over the course of the year buy me nothing, and I might as well let my IDE handle the mechanical act of declaring ten pairs of getters/setters for yet another class.
Why is it static void main(argc, argv) in Java? Well, that's the way C did it. Why did C give main() function arguments, as opposed to (say) environment variables? Well, that's just the way it's done. Why is return 0 success and other values fail? Convention. Why are curly braces used to delimit code and parentheses used to delimit arguments? Because the spec authors said so.
Basically, I think most of what constitutes programming can be done without ever typing a line of code. It's the process of decomposing a large task into small, simple ones, in a way that can be processed efficiently. The rest is just notation.
Pedagogy is absolutely fine, but at the same time we all stand on the shoulders of giants. Nobody is writing their own TCP/IP stack, we all rely on "copied and pasted" code (encapsulated in a library) so that we can focus on business logic. Obviously if you don't know what you're doing you can easily cause a mess, but the physical act of typing is probably the least important part of programming. Conceptual understanding is what matters, and the random syntax and half dozen keyword modifiers you will learn by typing are not going to push you very far in conceptual understanding.
From memory, \w. Conceptually, this is because in regular expressions, capitalization indicates negation. \w matches word characters, \W matches non-word characters, \d matches digits, \D matches non-digits, \s matches whitespace, \S matches non-whitespace.
Having a conceptual understanding helps to be able to extrapolate more information with less memorization.
I don't mean this as a refutation of your overall point; I think your point is correct, that using cheat sheets allows you to save mental bandwidth. I just think this wasn't a great example.
In my opinion, the author's goal was to make a blog post. So he searched around for something like an original thought... and he found a glimmer (merely) of a thought: that hand-typing helps you READ content better than copy&pasting does.
It's more of an observation, actually... An independently repeatable one, sure... :)
Automate for speed, not for lack of understanding :)
Honestly what I tended to do was pick up 80% of the characters and fill in the last 20% from context, just like filling in unknown words in a sentence out of context. And much like with foreign languages I was better speaking than receiving.
Sure you can look down and see where they are. But its just that your brain on enough practice has mapped your fingers to the pattern of what you wish to do. There is very little memory involved in all this exercise.
The bad part about not having this kind of muscle memory is you have will have a whole lot of unnecessary overhead of working out things by sight and coordinating it with hand movements, which is very distracting when you have something requiring very high focus to do on hand. Especially in things like music, timing is everything. Working out things by sight is a straight no-go to even start with.
IDE makes it easy for you to work with complex navigation patterns, whether its bugs or understanding some part of your code or debugging. IDE is a tool designed to make that workflow easy for you. Its not a tool designed to make typing easy. And using tools like to these to avoid learning typing, makes it more hard in situations when you can't find your way out without typing.
Rote memorization is actually very useful; frankly, I think that its abandonment as a pedagogical tool is partially to blame for modern students' appalling lack of education.
Sometimes you gotta recite 'amo, amas, amat' over and over until you've got it right.
Been a few years since a Windows machine was my daily driver, so I thought, "What does breaking command execution have to do with anything?"
In a similar way, some people don't see music until they play it, some see it before it is played. I really don't know what it is that creates the difference.
For me, doing the typing (or writing in my notebook) really connects the knowledge somewhere in my head that is harder to erase/lose than just reading or seeing it. I discovered in college that I could look at a homework problem and solve it but later in an exam couldn't bring back all the finer points of solving it, unless I had actually written down my solution. Very strange but a good thing to know about oneself.
But that being said, when learning something new I do tend to type it out myself to help reinforce things. Same reason I handwrote my notes in college.
But I'm not going to type everything all the time. I'll get carpal tunnel, and it'd take me a lot longer to get tasks done.
I truly believe this is one of the best ways to learn.
The word is most definitely "badassery"
however, a 'badassery' sounds more like a place where you would go to eat badass than a 'badassity'.
[0] http://www.mrmoneymustache.com/
http://houshalter.github.io/perplex/perplex.html
https://github.com/carllerche/mio/blob/getting-started/doc/g...