He doesn't really mention that the reason chess players and musicians can take more with each glance at a position/page is that they see in chunks, not individual elements - that comes from learning the patterns, e.g. in chess "short-castled white king with pawn on h3", in music "C7 chord with melody on the 7th" etc. It's just like adding more layers to a neural network, each layer building things from the elements of the previous one. Or like us reading a page of writing - we don't have to look at each letter like a beginner reader, and barely at some individual words. I guess looking at a C for-loop is like that for someone who's seen 1000s. Apparently chess masters don't look at more positions and moves than a beginner; they just see so much more, and intuitively only look at the best moves in a position (mostly anyway).

Learning to improvise jazz seems different to Franklin's method, in that you don't listen to a jazz great's solo, put it aside and later try to reconstruct it; you have to play it exactly, writing it out if necessary, and play it over and over until it starts to become intuitive; until the muscles learn it. And that must be done with many different solos. And copying just one person just makes you a clone of them. I guess learning programming doesn't have that essential element of imitating the styles of individual great programmers, although maybe for some people it does.

I think a good learning trick that's an intermediate point between the two approaches he discusses (copying the sample code vs. closing the book and write the code yourself) is to write a different program based on what you can see in the sample code. That's how I learn tech myself--I already have some other project in mind, so I rarely sit down to build 'sample' apps with any sincerity. I try sample code to the extent needed to run it without errors, then integrate patterns from it into some other code I was meaning to write in the first place.

To use the Benjamin Franklin analogy, it would be like Franklin having the articles he was seeking to understand open before him, but adding new paragraphs in between the original text, or re-purposing the article into a speech.

This is a very common pedagogical approach of course--hence the cliche phrase 'left as an exercise for the reader.' The subtlety is that this is usually a hypothetical exercise on top of an already hypothetical problem, whereas if I have my own project in mind, I am far more motivated to figure things out.

Most programming books do not let you pause to reflect. They just go on and on. Consider Fluent Python by Luis Ramalho. If you read through the book, you will not get much out of it. However, if after each chapter, you try to come up with a practical application of the concepts discussed, then you will have a better chance at building a mental model around the topics. The code presented is just a solution to a problem. You need to come up with more problems. Basically, don't be a passive learner. Be an active learner.

If you enjoyed the Franklin quote in this article, check out his autobiography. It is a gold mine of "life hacks", demonstrated via accounts of Franklin's remarkable life. It seems to be one of the original American self-help books :)

I'm actually not entirely sure how I learned how to program (I'm self-taught); I doubt it was just "one magic thing", but I am a big believer in the "learning-by-doing" approach for this kind of stuff.

If I recall, I think the thing that made everything stick was me reading through one of those "Sams: Teach Yourself C in blah days", then downloading Code::Blocks and making a very simple OpenGL application involving bouncing boxes (which happened to coincide with the physics class I was taking). I remember using that book for reference for when my code wasn't compiling, but I found it difficult to derive "some example where I calculate a Fibonacci sequence" to "making cool stuff like a game" without just ditching the book and trying it.

tl;dr, I somewhat agree with this article. You have to figure this stuff out for yourself to really "understand" it and become a good programmer. It's a language, after all. You don't just learn French by reading one intro-to-french book.

> Let’s face it, programming books suck.

While I agree that there are a lot of bad books out there, I don't agree that programming books suck in general. I very much prefer a well structured book over one of those chaotic tutorials that leave me with more questions than answers. Especially for languages where the "why" matters a lot more than the "how".

> It’s a lot like the way you may have already been doing it, just with more learning.

Maybe that's the reason why I disagree. Indeed, they way I read a book is by putting its content into practice.

Until a few weeks ago I had never bought a programming book, instead electing to learn on the job. I've noticed that since I'm not a novice programmer anymore, by far the most efficient way to learn is to use the method in the article. I've been working through K&R C and have been doing exactly what the article says--read the code, understand how it works, then write it. When it breaks, go back and learn why. After a few exercises, you'll find yourself adding your own flair and style, which is essential for your growth as a programmer. Plus, it's a much more fulfilling feeling of accomplishment when you can create something from scratch, rather than copy-pasting.

Books present information in various ways. Some books have questions that you can answer yourself to teach yourself how to do things. It looks like this author would be a fan of Learn C the Hard way by Zed Shaw. But, if you are buying a book to learn how to do something coming in with some kind of goal is more instructive than reading a book and regurgitating the answers. The author has a good idea on how to make the tutorials in a book into questions but at the end of the day you will teach yourself only what it is in the book.

My technique: I read the book till I get stuck and start back at page one till I get stuck again. I'm a little stubborn I guess.

Different Program Books Make Different Goals. My favorite are that there is a higher point to be made. My favorite books of this type have been made by Matthias Felleisen.

Little Schemer helped me to understand the though process more than learning a specific language.

How to Design Programs was super dense but it took me through the process of actually designing programs in a logical manner.

http://www.ccs.neu.edu/home/matthias/HtDP2e/

My favorite domain specific book has been: Hands-On Programming with R. It also was more about here is a logical problem and this is a way to solve it. http://shop.oreilly.com/product/0636920028574.do

The books he is talking about were not originally about instruction in a language. They were great reference books in the days before Stack Overflow, or even before the web had so much info on it. Now, if you want to argue that they are outdated, I may buy that... but saying that the entire series is unhelpful just because it doesn't match their/a better learning style.... seems like a big misunderstanding.

I think this article is interesting but it's really only skirting around the edges of the topic of "learning programming" or patterns or a new language or whatever. A good programming book is written from a an understanding of what programming is: Puzzle solving.

A lot of people think programming is a creative work--and it is to some extent--but if you've ever looked at a block of code and thought to yourself, "this could be written better"--you should realize that, "coding better" is really an exploratory action. You won't know if it's better until you actually run it or someone else reads it and agrees that it is easier to read, makes more sense, etc.

Writing software is fundamentally an act of discovery. If anything has proven this it's the recent Spectre and Meltdown vulnerabilities. Yes, we're 99% sure how our code will perform while in operation but we can never be absolutely 100% certain. Because the CPU, the memory, the chipsets, and other hardware are really just exceptionally reliable laboratory equipment and our experiments (software) have been shown to work precisely as expected almost all the time.

A good programming book will provide plenty of code examples but when it comes time for the reader to practice what they've learned a truly great book will provide the reader with puzzles to solve.

I've been trying to help one of my friends learn basic coding skills, and the method we used was similar. First, there would be a problem we wanted to solve, I would walk through with him to the solution, and write the code as we speak. By the time we were done, I'd let him study the code for a bit, delete everything, and wanted him to rewrite it.

James Koppel (author of the blog) helped me saw the whole thing from another perspective, and I also loved that he has a high Signal-to-Noise ratio.

I've been reading the Norton Edition of Franklin's autobiography and some of the excerpts in the back of the book are pretty amazing. A lot of them pretty vicious European responses to Franklin's approaches, especially his list of virtues. For instance D.H. Lawrence:

http://xroads.virginia.edu/~hyper/lawrence/dhlch02.htm

For those who are looking for ways to improve on how we learn, I recommend the book "Make it stick": http://www.makeitstick.net/

It was a real eye opener for me.

> Traditionally, there are two ways to study a page like this:

> 1. Type out every line of code

> 2. Copy+paste the code from their website, maybe play around and make small changes

Um... wut? How about:

3. Read the code. Think.

If you're reading programming books as practice, and think you're supposed to copy the code examples to learn, you're doing it wrong. If you need eval() to figure out what's going on, you need to spend more time practicing the basics, then step up to the book.

    import { drawDragon } from 'drawing'
    <other imports..>

    function(screen) {
      screen.render(drawDragon.new('red'))
    }

One of the best examinations of learning, especially with structured media as described in the article, actually comes from a video game: The Witness.

A summary of how it does it and why it is so good can be found in this 10 minute demo from creator Jonathan Blow:

https://www.youtube.com/watch?v=rDSrYiheVow

This guy is nuts. Basically every article I look at I wind up reading multiple times and get new information each time. If I had the attention span to keep reading them I would probably keep learning too...

This is a pretty common learning technique, one that's been validated in cognitive psychology and cognitive neuroscience research, and one that in grad school (in a different field) I would teach to undergrads that were struggling in the classes I TA'ed. I only wished I had learned it as an undergrad.

For more conceptual learnings, I would instead write questions that capture the main ideas of some subsection or whatnot, then at the end of the chapter, close the book, answer the questions, and summarize the questions. Then go back and check the answers. It takes longer, but active recall helps memory encoding.

This is a great technique to learning. I taught myself how to code after college and found doing my own version of this helpful. The only slight difference in the technique I used was I found it easier to learn when I had something I wanted to build in mind. This helped both in both direction, what to learn, as well as forcing me replicate code for my own use, like the Ben Franklin technique. Hope others find it useful too.

Perhaps, instead of reading Programming books, people should master the core tenets of programming first such as OO from such books as "clean code", "Code complete".

That will make it easier for readers to understand and retain information from programming books?

This is basically how I'd been telling people to learn from programming tutorial videos for years:

Do the exercise with the video. Do it again, only referencing the video when necessary. If you used the video a lot, do it a third time.

If it doesn't stick after a third time, it probably isn't going to without more tutorials, so go ahead and continue on. I'm betting most people get enough out of the second time, though, especially after doing this a few times and getting the hang of it.

And it's more or less what I've always done, though maybe not exactly following those steps.

This sounds like an excellent idea. However, what about choice of material? We pick a musical piece to learn because we enjoy the tune and how it sounds. How should a beginner choose which code to memorise?

> Read your programming book as normal. When you get to a code sample, read it over

> Then close the book.

> Then try to type it up.

According to a passage in "The Autobiography of Benjamin Franklin" (1791) regarding re-typing from "The Spectator"

https://en.wikipedia.org/wiki/The_Autobiography_of_Benjamin_...

EBook: http://www.gutenberg.org/ebooks/148

Of course, the same method can be applied to reading other people's code. Actually, that's analogous to what Franklin did. He tried to capture the essence of a finished work of which he approved.

Using a phrase-book in such a manner wouldn't be beneficial. And programming language books are much like phrase-books: guides to syntax.

Other kinds of programming books, in the category "Do X with Y programming language" are best avoided. They tend to look like phone-books. It is best to decouple X from Y.

Sounds pretty similar to SQ3R. https://en.wikipedia.org/wiki/SQ3R