Tommy Nicholas recently wrote a blog post advocating typing rather than copying-and-pasting code samples. I thought this was the most interesting paragraph from the post:
When Hunter S. Thompson was working as a copy boy at Time Magazine in 1959, he spent his spare time typing out the entire Great Gatsby by F. Scott Fitzgerald and A Farewell to Arms by Ernest Hemingway in order to better understand what it feels like to write a great book. To be able to feel the author’s turns in logic and storytelling weren’t possible from reading the books alone, you had to feel what it feels like to actually create the thing. And so I have found it to be with coding.
Joe Armstrong had similar advice:
Forget about the tools … buy a decent book and type in the programs by hand. One at a time thinking as you go. After 30 years you will get the hang of this and be a good programmer.
Typing code may be like riding a bicycle. I’m surprised how much more detail I see the first time I ride my bicycle over a road I’ve driven on, mostly because I’m moving slower but also because there’s an additional muscular dimension to the experience.
Another advantage to typing example code is that you’ll make mistakes, just as you will in real work. This will give you the opportunity to see what happens and to learn debugging, even though you may not appreciate the opportunity.
That’s exactly the philosophy behind “Learn Python the hard way”
http://learnpythonthehardway.org/
“You must type each of these exercises in, manually. If you copy and paste, you might as well just not even do them. The point of these exercises is to train your hands, your brain, and your mind in how to read, write, and see code. If you copy-paste, you are cheating yourself out of the effectiveness of the lessons.”
It’s not typing per se, but thinking about what you’re doing. You can achieve the same by carefully reading selected code, and reasoning about it. Having to type it just prevents the temptation to start skipping parts.
The same applies to lecture notes. You can attend a lecture and mecanically copy what was said and not understand anything or try to rewrite in your words what was said and discover things you didn’t pay attention to.
Typing in examples works when you look at a code sample, understand what it does, close that sample and write it on your own. If you’re looking at the code sample for every character you type, you’re just copy pasting it again.
A related exercise is changing the indentation or style of the code. It get’s your fingers dirty and gives you something to do, and in the process of making sure the code works after your changes you learn a lot about what the code is doing.
Of course, once you have completed this exercise, it’s probably best to throw out your changes. If you have something of value to contribute to the original code base, it’s probably best to adhere to the original style.
That said, I also suspect, that some of the importance people have placed on stylistic issues has to do with how much they have learned using this kind of process (except attributing the consequences to the style they have selected rather than the process of making many minute changes to someone else’s code).
In fact, why type code when you can write it? By hand, that is. (You can forego on the whole parchment and quill paper thing, though.) The great advantage of handwriting code is that there’s no backspace key, so you automatically force yourself to think harder about the code and you keep an audit trail of “misthinkings” at the same time.
I did not know the Hunter S. Thompson story. Very interesting. Maybe that is an antidote for writer’s block: just start typing someone else’s book until you feel like writing your own. Same goes for programming, modulo specific set knowledge and installation requirements.
Whenever I reuse someone else’s code, I occasionally find myself refactoring it and adjusting the coding style to match mine. During that process, I learn a lot more about how the code works than if I just plug it in and pray. This isn’t quite the “type it in to learn to be a good programmer” process you describe, but then I’ve already put in my 30 years.
One thing I do with sample code is change it. That is change it functionally. I choose a salient point in the code and change its behavior to prove to myself that I really understand what the code is doing and possibly explore the lesson of the code a little more deeply.
I agree 100%. Anytime I am trying to learn a new language or coding style I always type the examples and follow the logic line by line. I thought I was the only one that had to “Spoon Feed” the info into his brain. LOL
The more you experience the learning of knowledge, the deeper the knowledge will be.
Agreed, and you also learn about how to deal with your own personal tendencies/deficiencies. What I mean is, spelling mistakes, indentation different from code samples, do you mix up single/plural tense for variables, how you debug, maybe you like to focus on something slightly different from the example and it really changes the outcome?
Thanks for the blog.
Nothing wrong with copy pasting but the NEXT step is to change, break and fix the code. Alter bits and pieces, add traces etc. After a while you WILL understand the code well enough to use it as a basis for a new project.
Copy pasting saves time. Time you may not have. If you do not know debugging techniques then maybe you are in the wrong career.
It depends on context, such as where the code came from, how you intend to use it, etc. Some code is worth studying carefully and some is not.
I heard someone say on Twitter that he’d no more paste random found code into production than he’d eat chewing gum he found on the street. :)
When I was a mainframe programmer in the 70’s I used to get yelled at by my boss because I keypunched my own programs. He thought I should have be writing them out longhand on coder sheets to give to the keypuncher staff.
I told him I didn’t want to deal with their typos in addition to my programming errors. Many times as I would be typing in my programs I would suddenly realize it had no chance of working and I’d wonder what I had been smoking to even write like that.
Typing in the code certainly makes you think about it more.
I agree with the respondents who say that blind retyping is no better than copy-and-paste. The intent must be to put the brain in gear, rather than performing finger exercises. Rather than retyping, I prefer to run other people’s code in my head. This leads to questions like: What is he doing here? Why doesn’t he simply do XXX? Can this be simplified? Then I get onto the more long term important questions: What ingenious devices has he used that I can add to my tool box? What caused me to stumble and struggle – and was the pain worth it (nothing worth learning comes cheaply)? What awful things have I seen that I will studiciously avoid in the future? Even the bad bits are a learning opportunity; the good bits are like gold nuggets – worth hours of panning through muddy water to find.
P.S. Of course ‘he’ could be a ‘she’.