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.
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 :)
He just had a very Feynman-like way (or Feynman had a Franklin-like way) of seeing the world. He sees confirmation bias, the dangers of saying yes, the power of positive thinking, failure as a teaching tool, the power of a nebulous "them", habit chaining ...
But my favorite quote/section is on his 13th virtue, humility. Frankling was told by a friend to stop being so proud, and so he introduced a habit of always being extra modest when espousing his opinions, adding "I imagine" and "perhaps" instead of "undoubtedly" and "certainly." Anyway, he goes on to say while it wasn't a total success, he felt he'd been pretty successful in habituating that modesty for 50 years, but pride is a hard thing to subdue, "for even if I had completely overcome it, I would probably be proud of my humility." !!
He ruled up a book with virtues—the ones he wanted to improve in—down the side of the page, the days along the top, and drew black dots at the end of each day next to each virtue he'd lapsed in. And tried to have less black dots with every day.
That was the most valuable thing I got from that book. I tried it once, decades ago.
He also wrote this epitaph for himself in his 20s:
The Body of
B. Franklin, Printer;
Like the Cover of an old Book,
Its Contents torn out,
And stript of its Lettering and Gilding,
Lies here, Food for Worms.
But the Work shall not be wholly lost:
For it will, as he believ’d, appear once more,
In a new & more perfect Edition,
Corrected and amended
By the Author.
And also essays on farting and choosing a mistress.
That's actually super smart. I usually try to log my habits/daily things to do (write in journal, exercise, spend at least an hour reading a book etc.) but doing it for virtues sounds like a good idea. What did you get from doing it? Why'd you stop?
That looks nice, but I wish there was an option to view it as simply formatted HTML too. There's something nice about just being able to click the link and have it there.
"I grew convinc'd that Truth, Sincerity and Integrity in Dealings between Man and Man, were of the utmost Importance to the Felicity of Life." I live my life according this. I've regretted many mistakes along the way. I have never regretted telling the truth. I might withhold the truth. I might knowingly let people assume things, but that is their own fault. I will not lie. The problem after reading this in high school is that I became a lover of truth which I later learned is a philosopher.
Technically I believe a philosopher is a lover of wisdom, rather than just truth. But I guess you could rightly argue that truth is a subset of wisdom... :)
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...
I admit that even simple articles often have nuance that many would benefit from better exposure. Yet, a limited attention span would seem to be eclipsed simply by have better options in the vast sea of material not yet seen.
In a world where you have a massive backlog of good content, yes. Unfortunately, I struggle to find content which is both high quality and easy to learn from. Do you have suggestions?
That is a fair statement. I suspect that this poses challenges on a number of levels, including what areas on finds of interest and how they prefer to be engaged.
Between work, family, and school my opportunities to indulge are more limited than I would prefer. Recently I had an opportunity to listen to old lectures by Prof Malan (I understand that newer version of these lectures are now available on edx.org). When I am in the mood for something tied to current events, I enjoy taking time to read Krebs (krebsonsecurity.com) or catch up on conference presentations that I missed (still working my way through the material from ShmooCon).
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.
Q. Who are the great programmers, with inimitable or at least unmistakable and unique styles? Is there such a thing, as happens with music improvisers, composers, artists, writers?
The analogy between music and programming holds at this stage. I can guarantee you all the musicians in this band [0] had their own distinctive style to some degree or another and would have even loved to have been paid to perform it but the fact is most professional musicians come in and have to be subservient to the style of the bandleader. And it's no different for coding.
Well, in jazz, you have your own individual style, people hire you because they like it. Sure, in different settings you adapt, but you still sound like yourself. It's the same with classical soloists. The ones that are famous, are famous because they don't sound like anyone else. Just a lot like themselves. Same with singers (rock, jazz, classical) - all well-known singers are very recognisable, and a lot of them have weird, unusual voices.
Also, I find it strange, this talking as if programming and music don't exist in the world outside a setting of just having to do what the leader wants. I guess particularly because I've been programming and playing music all my life, almost all of the time doing exactly what I wanted every second. (Only music professionally)
Following the same style guide as your coworkers isn't the same as writing code exactly the same way your coworkers do. I suggest following the style of a bandleader works in the same way. Individuals still have a voice - think of all the great players who made a name in various Big Band orchestras - but the style is still unmistakably that of the band and not exclusively the individual. Unless you're Melkor or something.
Sure, sure. We should differentiate the styles of the individual players, and the style of the group; two different things. I found it depressing, that suggestion earlier in the thread that one's style is always totally suppressed by the team you're on. Maybe I misunderstood; maybe that's stretching the analogy too far.
Although... when I was about 20 I went to see a fellow musician in their day job, programming in a company, finance/accounting-type stuff. It seemed so totally depressing I decided I never wanted to do programming professionally.
I guess there is the average, rank-and-file performer in the arts, like a 3rd violin in an orchestra, or player in a musical show, singer in a choir, (or my friend) where individuality is not required, just professionalism. That's like craft[0]. And then the music-as-art thing, like classical soloists, jazz groups, singers where the important thing is to sound like yourself (and to sound good!)
[0] I'm thinking craft in the sense Collingwood uses it in Principles of Art - craft (as opposed to art) is when you know beforehand exactly what final result you're aiming for and what steps to follow to get there.
IMHO every programer has a unique style to some extent, you just need to spend enough time looking at their code to start recognising those specific patterns. For some of my friends I can always guess that code is theirs by the way they name variables, how they structure the logic and other small details. So I guess you can just pick any elegant programming solution and try to replicate the logic on your own, and then compare it and see what they did differently.
A lot of people would disagree but I would nominate Arthur Whitney of k/q/j/apl fame; others on my list are Bill Spitzak of FLTK, Salvatore sanfillipo (antirez), Richard Stillman (who hasn’t written a lot of code recently, but did write the original Emacs, GCC and a lot more)
I would look to the great applications that you use everyday. Open source applications are a great resource here. One of the reasons I like GitHub is I can peruse great software and learn how they work. The great programmers quickly come to the top when you study their work.
I find that "great programming" is less about the style of the code itself. That part is craftsmanship, which beginners do poorly, but once you learn it, you've learned it. Expert coders may have differing styles, but it mostly just looks like "good style". Like how two expert carpenters might make slightly different style of chairs, and you can tell that both are made really well, but neither style is distinctive enough that it will blow you away.
No, true "artistry" in code I find comes less from style in code and more from architecture. Like, when you first learn about the unix pipeline, and realize how all these tiny programs are composable, and it blows your fucking mind? Or when you're faced with a huge codebase, framework or engine, and you start to explore how it works, and you realize how smartly designed everything is, and how easy it is to do stuff in it? (it doesn't happen often, but when it does, it's wonderful)
So, less emphasis "neat/readable organization symbols in a particular file" (though it's still important) and more emphasis "neatly organized abstractions enabling broad application"?
I often find folks who prefer langs like C, or at least have a lot of experience with it, are better at that than Ruby/JS/Python folks who haven't used much else.
Another advantage musicians practiced in reading sheet music have (assuming they're also practiced in the general play of their instrument) is that music falls into various scales and modes. Learning and practicing the scales and modes in different ways and patterns allows musicians to have a wide set of skills that can be quickly applied to most music.
Note that there are different sets of patterns. Jazz and classical music are different enough that you can be good at one but bad at the other. There are rhythms an chords in each that would never make sense in the other. Of course plenty of musicians are good at both, but it requires more effort.
Another big difference is that the chess players and musicians he mentions are already experts. If you are learning a new language, you probably don't know the syntax, and maybe even don't have a clue about the programming paradigm.
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.
I think that this Franklin method is basically how I learned. Jazz solos are not generally random; they are based on particular chords and/or scales/modes. The best improvisers tend to be good composers in general, and improvising is composing real-time. Get a good handle on what chord/mode to center you're composing around, and construct a jazz solo likewise.
not generally? "not random", surely. And even if humans try to play randomly they couldn't.
>based on particular chords
Whether the notes used in a section are from the set of all 12, or a particular subset, is nearly, dare I say, orthogonal to the level of randomness. And even playing not based on particular chords can be highly random-sounding or not at all.
I didn't understand your last sentence at all; at least, what do you mean, likewise? Or the first half really.
I did not mean "random" in a literal mathematical sense. If I have absolutely no idea (or purposefully ignore) what the chord progression of a tune is, I could just start playing notes. It might sound good, it might not. It might sound dissonant in a pleasing way. But that playing would not be based on a theoretical understanding of the chord progression; it would be, in some sense, random -- unplanned, escaping traditional theoretical analysis.
You could play any note on any chord, and it might be what you intended. Let's say the chord is C major. You could play a C, for the root. Or G, for the 5th. Or Db, for a flat 9. Or F#, for a sharp 11. Indeed, any of the 12 notes would be fair game, and you could name what they are from a music theory standpoint.
Trying to bring this back around to the Franklin method of learning: what one might do here is listen to a jazz solo, and first transcribe (or obtain a copy of) the chord progression. Instead of trying to copy the solo itself, you can hear that the soloist often played motifs emphasizing the dominant 9th and 11th over minor chords, and the major 7th and major 6th over major chords. You could then make up your own solo with the same emphasis. It would not be the exact same solo, but it would (or could) have a similar sonic color to it.
When I studied jazz piano at university, I was actually taught a very similar technique to the one described in the aritcle. You're right in that we would learn to memorize transcriptions of great players, but there was also a step where we might deconstruct there techniques and apply our own approach to them.
For example, I might see that John Coltrane used a certain scale or lick at a certain point in a song. I then might make a note in my music 'Use X scale here' as an exercise while improvising.
The effect is similar to what the author is describing - chunking broad ideas and implementing them ourselves as practice.
It's been said about many things that they can't be taught, only learnt. (e.g. Botvinnik—founder of the "Russian school of chess"—said it about chess, I say it about jazz, Oakeshott's Rationality in Politics is about that)
Is that true of programming also?
Maybe that's what the article's saying—you have to learn for yourself. Well, there are typically a lot of Exercises in maths books because that's how you learn that stuff, by seeing for yourself, working things out, not from just being told it.
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?
"Tensorflow: This is the finest Google codebase I ‘ve studied. Great design, very high quality code, and easy to understand how everything fit together."
Tensorflow is the worst code you can learn from a library design perspective.
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.
Yeah, it's strange to me that a book should try to force a person to come up with their own activities. Perhaps they should suggest it strongly, but so should a good how-to-learn class, saving all that ink on all those pages from saying the same thing.
In the case of "Fluent Python", the author fairly explicitly calls out it is not for rote learning of the basic language:
> ..."if you read it too early in your Python journey, it may give you the impression that every Python script should leverage special methods and metaprogramming tricks."
But if you are familiar with a lot of the concepts and the basic syntax of Python, its wonderful. I never understood how all the magic methods in Python worked (and how nice they were) until I read that book.
I haven't finished it, but because of it am now able to write and read Python much, much better.
On one hand, I am glad to say I have been practicing the given advice for many years. On the other, I am intimidated at the notion that others learn anything useful without doing so.
Different learning styles are appropriate for different learners, stages of learning, and lesson types. What's important is that you found a learning style that works for you and that you can build on.
> 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.
While this is definitely what I do, for some reason, I always believe I'm not doing things "they way you're supposed to", so I almost never argue when articles don't mention doing things the way I'm doing them.
Yeah, I've never typed any of the code examples of programming books.. I just read it to understand the concepts. Often I can go really fast when most of it is familiar, but when something catch my attention I work hard to decipher and understand it. if I can't, I'll re-read the chapter or search online.
As a side note, it would be great to have more programming books written like this. I.e. We assume you already know language X so here are the differences and why; focusing mainly on specific code examples and gotchas of the new language.
By semi-pseudocode, I mean that I'm okay with not having the program in its full completeness with the less important part being abstracted away, but for the concepts that are being explained to be detailed, thorough and well documented.
As a fun exercise, one could take a big programming book and trim it down to a 1/10th (or more). There are so many useless sections. Most great devs are good at skipping through the bullshit.. why not just remove that part entirely!
Reason is probably monetary or politic. I.e. can sell to a larger audience by being more beginner friendly and/or need to have a certain amount of page and follow a template to be published.
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.
thanks for this! I had trouble going through some programming courses, and going in parallel with the teacher. But I never made the connection - to just watch it first and try to reproduce it on my own after. Simple and brilliant advice!
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.
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 is also why a smart code-completion tool can guess a long sequence of code from the first couple lines. With a better mental representation, understanding code is simply less work. "
=> Is the author protesting against the use of auto-completion/Intellisense feature of most of the modern IDEs ?
IMHO it's very good, and decreases the typing time ONLY if you understand the code, and you know what it's doing. Too often I have seen programmers with a strange approach: "I don't need to know, I don't need to think because I have my IDE".
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.
One of my go-to projects for learning a new language is implementing Conway's Game of Life (while trying my best to follow the idioms of the language).
I feel that project is easy enough to not get terribly frustrating, but not entirely trivial, forcing you to think a bit about how you are going to structure it.
What I like about languages with REPLs is that I can just copy-paste stuff and then muck about at various points of execution to get an idea of how things work, or prod at the different parts.
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.
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
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.
> I found it easier to learn when I had something I wanted to build in mind
I don't understand how you can learn this stuff in any other way. I think it's a little bit like learning a musical instrument. One can read lots of stuff about guitars and music theory and how to play the guitar, but none of that matters until you pick up an actual guitar.
104 comments
[ 3.9 ms ] story [ 164 ms ] threadBut my favorite quote/section is on his 13th virtue, humility. Frankling was told by a friend to stop being so proud, and so he introduced a habit of always being extra modest when espousing his opinions, adding "I imagine" and "perhaps" instead of "undoubtedly" and "certainly." Anyway, he goes on to say while it wasn't a total success, he felt he'd been pretty successful in habituating that modesty for 50 years, but pride is a hard thing to subdue, "for even if I had completely overcome it, I would probably be proud of my humility." !!
That was the most valuable thing I got from that book. I tried it once, decades ago.
The Body of B. Franklin, Printer; Like the Cover of an old Book, Its Contents torn out, And stript of its Lettering and Gilding, Lies here, Food for Worms. But the Work shall not be wholly lost: For it will, as he believ’d, appear once more, In a new & more perfect Edition, Corrected and amended By the Author.
And also essays on farting and choosing a mistress.
Between work, family, and school my opportunities to indulge are more limited than I would prefer. Recently I had an opportunity to listen to old lectures by Prof Malan (I understand that newer version of these lectures are now available on edx.org). When I am in the mood for something tied to current events, I enjoy taking time to read Krebs (krebsonsecurity.com) or catch up on conference presentations that I missed (still working my way through the material from ShmooCon).
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.
So, extrapolating it further despite my lack of personal experience – perhaps, Linus?
[0] https://www.youtube.com/watch?v=hNbsnBZOwqE
Also, I find it strange, this talking as if programming and music don't exist in the world outside a setting of just having to do what the leader wants. I guess particularly because I've been programming and playing music all my life, almost all of the time doing exactly what I wanted every second. (Only music professionally)
Although... when I was about 20 I went to see a fellow musician in their day job, programming in a company, finance/accounting-type stuff. It seemed so totally depressing I decided I never wanted to do programming professionally.
I guess there is the average, rank-and-file performer in the arts, like a 3rd violin in an orchestra, or player in a musical show, singer in a choir, (or my friend) where individuality is not required, just professionalism. That's like craft[0]. And then the music-as-art thing, like classical soloists, jazz groups, singers where the important thing is to sound like yourself (and to sound good!)
[0] I'm thinking craft in the sense Collingwood uses it in Principles of Art - craft (as opposed to art) is when you know beforehand exactly what final result you're aiming for and what steps to follow to get there.
No, true "artistry" in code I find comes less from style in code and more from architecture. Like, when you first learn about the unix pipeline, and realize how all these tiny programs are composable, and it blows your fucking mind? Or when you're faced with a huge codebase, framework or engine, and you start to explore how it works, and you realize how smartly designed everything is, and how easy it is to do stuff in it? (it doesn't happen often, but when it does, it's wonderful)
That's what great programmers do.
I often find folks who prefer langs like C, or at least have a lot of experience with it, are better at that than Ruby/JS/Python folks who haven't used much else.
Also, in pg's essay Great Hackers he says that no-one knows who the best programmers are; you have to work with them to know just how good they are.
http://www.paulgraham.com/gh.html
I think that this Franklin method is basically how I learned. Jazz solos are not generally random; they are based on particular chords and/or scales/modes. The best improvisers tend to be good composers in general, and improvising is composing real-time. Get a good handle on what chord/mode to center you're composing around, and construct a jazz solo likewise.
not generally? "not random", surely. And even if humans try to play randomly they couldn't.
>based on particular chords
Whether the notes used in a section are from the set of all 12, or a particular subset, is nearly, dare I say, orthogonal to the level of randomness. And even playing not based on particular chords can be highly random-sounding or not at all.
I didn't understand your last sentence at all; at least, what do you mean, likewise? Or the first half really.
You could play any note on any chord, and it might be what you intended. Let's say the chord is C major. You could play a C, for the root. Or G, for the 5th. Or Db, for a flat 9. Or F#, for a sharp 11. Indeed, any of the 12 notes would be fair game, and you could name what they are from a music theory standpoint.
Trying to bring this back around to the Franklin method of learning: what one might do here is listen to a jazz solo, and first transcribe (or obtain a copy of) the chord progression. Instead of trying to copy the solo itself, you can hear that the soloist often played motifs emphasizing the dominant 9th and 11th over minor chords, and the major 7th and major 6th over major chords. You could then make up your own solo with the same emphasis. It would not be the exact same solo, but it would (or could) have a similar sonic color to it.
For example, I might see that John Coltrane used a certain scale or lick at a certain point in a song. I then might make a note in my music 'Use X scale here' as an exercise while improvising.
The effect is similar to what the author is describing - chunking broad ideas and implementing them ourselves as practice.
Compression : finding patterns :: forest : trees.
It's been said about many things that they can't be taught, only learnt. (e.g. Botvinnik—founder of the "Russian school of chess"—said it about chess, I say it about jazz, Oakeshott's Rationality in Politics is about that)
Is that true of programming also?
Maybe that's what the article's saying—you have to learn for yourself. Well, there are typically a lot of Exercises in maths books because that's how you learn that stuff, by seeing for yourself, working things out, not from just being told it.
A curation of good codebases by someone who studies a lot of them.
"Tensorflow: This is the finest Google codebase I ‘ve studied. Great design, very high quality code, and easy to understand how everything fit together."
Tensorflow is the worst code you can learn from a library design perspective.
https://en.m.wikipedia.org/wiki/Suzuki_method
> ..."if you read it too early in your Python journey, it may give you the impression that every Python script should leverage special methods and metaprogramming tricks."
I haven't finished it, but because of it am now able to write and read Python much, much better.
On one hand, I am glad to say I have been practicing the given advice for many years. On the other, I am intimidated at the notion that others learn anything useful without doing so.
This whole post could have been condensed to just that.
> 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.
While this is definitely what I do, for some reason, I always believe I'm not doing things "they way you're supposed to", so I almost never argue when articles don't mention doing things the way I'm doing them.
As a side note, it would be great to have more programming books written like this. I.e. We assume you already know language X so here are the differences and why; focusing mainly on specific code examples and gotchas of the new language.
I would prefer semi-pseudocode:
By semi-pseudocode, I mean that I'm okay with not having the program in its full completeness with the less important part being abstracted away, but for the concepts that are being explained to be detailed, thorough and well documented.As a fun exercise, one could take a big programming book and trim it down to a 1/10th (or more). There are so many useless sections. Most great devs are good at skipping through the bullshit.. why not just remove that part entirely!
Reason is probably monetary or politic. I.e. can sell to a larger audience by being more beginner friendly and/or need to have a certain amount of page and follow a template to be published.
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.
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
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.
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.
=> Is the author protesting against the use of auto-completion/Intellisense feature of most of the modern IDEs ?
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.
I feel that project is easy enough to not get terribly frustrating, but not entirely trivial, forcing you to think a bit about how you are going to structure it.
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
I don't understand how you can learn this stuff in any other way. I think it's a little bit like learning a musical instrument. One can read lots of stuff about guitars and music theory and how to play the guitar, but none of that matters until you pick up an actual guitar.
This makes sorting through the political noise on HN worth it.
> 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