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 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.
Compression : finding patterns :: forest : trees.
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.
So, extrapolating it further despite my lack of personal experience – perhaps, Linus?
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.
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.
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.
> ..."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.
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." !!
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.
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.
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
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.
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.
It was a real eye opener for me.
https://www.coursera.org/learn/learning-how-to-learn
It's taught by Barbara Oakley, and the content of her book "A Mind For Numbers" is complementary to "Make It Stick."
> 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.
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:
import { drawDragon } from 'drawing'
<other imports..>
function(screen) {
screen.render(drawDragon.new('red'))
}
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 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.
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:
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.
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.
That will make it easier for readers to understand and retain information from programming books?
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.
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.
> 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_...
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.
But if you type them in, and study each line as you go, not proceeding until you understand what that line is doing and why it's there, a working example can be very helpful.
=> Is the author protesting against the use of auto-completion/Intellisense feature of most of the modern IDEs ?
He was imitating a style he liked, trying to acquire to ability to write like that. Using the method in programming seems different, in that it's not the particular writer's unique style you're trying to acquire, but other things.
This makes sorting through the political noise on HN worth it.
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.