I wrote How to quickly become effective when joining a new company ages ago. It's about how to learn in an environment where:
- You are trying to get stuff done and learning is your secondary objective
- There is vastly more to learn than you can reasonably learn before you are expected to start producing useful output.
The strategy described is I think useful outside of that scope, but I suspect there are better strategies when those are not your precise constraints.
I've been using a Read/Code/Bike/Repeat learning strategy a lot recently.
How does this work?
- Read a paper.
- Write some code based on the paper. It probably won't work.
- Go for a bike ride in which I'm forcibly isolated from the internet (checking your phone while on a bike is hazardous to your health!) and have to think about it in isolation. Probably figure out some useful insights as a result.
- Go back to step 1.
And basically repeating this process until I feel satisfied with my understanding of things.
Obviously this doesn't require an actual bike ride. Anything which disconnects you from external influences will do, but I think the exercise element might actually be a helpful part of it.
I agree that isolation is most important but exercise helps when learning new material. My wife suggested the increased oxygen uptake might have something to do with it; I'm guessing it's more (as in recitation or a lecture) that the exercise demands enough attention that one must concentrate somewhat to actively go over the material, but not so much attention that one's mind can't wander and find new connections.
The problem is that in general it’s really hard to write books for the “expert” because every expert is different. If you’re writing a book for use as a reference manual that’s fine because you can just make it a bunch of self-contained sections, but if you want to write something intended to be read from cover to cover I think the best you can really do is write something targeted at beginners in increasingly specific niches.
It may be difficult to write books for the expert, but I believe it's relatively easy to write for the expert.
When writing for the beginner or intermediate, pedagogy is as, or more, important than content. One has to arrange and explain to convey novel ideas. When writing for an expert, one can simply describe at a high level (eg non food-porn cookbooks, jazz fake books, etc.) with the confidence that the expert brings in enough outside context both to gloss over any repetition of what they do already know, and to figure out (after possibly closer study and external cross-reference) even compressed descriptions of what they don't already know.
From the standpoint of novelty for programmers, I find the math or hardware recommendation the best so far in the original lobste.rs thread. One of the more productive concepts I've run across over the years is that there's a generalized distributive law, in that hardware tends to decompose computations as a sum of products, while software tends to decompose as a product of sums.
As to specific recommendations which retain a distinctly programming focus: Algebra of Programming (Bird & de Moor, 1997), A Programming Language (Iverson, 1962), and Transaction Processing (Gray & Reuter, 1992) are books which have caused me (as someone who started in the late structured/early oo era) to think about the informatics of programs in a more general sense than just the mechanics of programming.
Anyone have something similar, from this century? (CTM I find an excellent reference, but not particularly mind-bending) Tanenbaum once did a gates-to-OS survey book that I found mind-bending in high school; I'm guessing Nand2Tetris would be this century's equivalent, but both would frankly be beginner's books.
Upon reflection; I'd guess the limited demand (and even more limited supply of authors?) for expert books means that correspondence and papers are a more likely format than book-length for encountering ideas which are both novel and good.
Today anglophones will say "it's greek to me" to indicate something is incomprehensible.
Back in the days when people studied greek, they might have been able to make the same statement, but indicate "this might appear incomprehensible at first glance, but if we concentrate a bit, we can likely puzzle it out..."
DRMacIver's suggestion on how to read a mathematics textbook recently reminded me of Grothendieck's "rising sea": reading maths front-to-back reminds me of his brute force "hammer and chisel" approach, while finding interesting results and then poking around, examining their supports, has much more the feel of gradually increasing one's knowledge, to the point where the material to be learned can be "opened by hand like a ripe avocado".
IOW: attempting to bulk load the totally ordered pages of a maths book thrashes my intellectual cache, but specific branches of the underlying partial order are often short enough streams to fit.
Prenons par exemple la tâche de démontrer un théorème qui reste hypothétique (à quoi, pour certains, semblerait se réduire le travail mathématique). Je vois deux approches extrêmes pour s’y prendre. L’une est celle du marteau et du burin, quand le problème posé est vu comme une grosse noix, dure et lisse, dont il s’agit d’atteindre l’intérieur, la chair nourricière protégée par la coque. Le principe est simple : on pose le tranchant du burin contre la coque, et on tape fort. Au besoin, on recommence en plusieurs endroits différents, jusqu’à ce que la coque se casse — et on est content. Cette approche est surtout tentante quand la coque présente des aspérités ou protubérances, par où « la prendre ». Dans certains cas, de tels « bouts » par où prendre la noix sautent aux yeux, dans d’autres cas, il faut la retourner attentivement dans tous les sens, la prospecter avec soin, avant de trouver un point d’attaque. Le cas le plus difficile est celui où la coque est d’une rotondité et d’une dureté parfaite et uniforme. On a beau taper fort, le tranchant du burin patine et égratigne à peine la surface — on finit par se lasser à la tâche. Parfois quand même on finit par y arriver, à force de muscle et d’endurance.
Je pourrais illustrer la deuxième approche, en gardant l’image de la noix qu’il s’agit d’ouvrir. La première parabole qui m’est venue à l’esprit tantôt, c’est qu’on plonge la noix dans un liquide émollient, de l’eau simplement pourquoi pas, de temps en temps on frotte pour qu’elle pénètre mieux, pour le reste on laisse faire le temps. La coque s’assouplit au fil des semaines et des mois - quand le temps est mûr, une pression de la main suffit, la coque s’ouvre comme celle d’un avocat mûr à point ! Ou encore, on laisse mûrir la noix sous le soleil et sous la pluie et peut-être aussi sous les gelées de l’hiver. Quand le temps est mûr c’est une pousse délicate sortie de la substantifique chair qui aura percé la coque, comme en se jouant - ou pour mieux dire, la coque se sera ouverte d’elle-même, pour lui laisser passage.
L’image qui m’était venue il y a quelques semaines était différente encore, la chose inconnue qu’il s’agit de connaître m’apparaissait comme quelque étendue de terre ou de marnes compactes, réticente à se laisser pénétrer. On peut s’y mettre avec des pioches ou des barres à mine ou même des marteaux-piqueurs : c’est la première approche, celle du « burin » (avec ou sans marteau). L’autre est celle de la mer. La mer s’avance insensiblement et sans bruit, rien ne semble se casser rien ne bouge l’eau est si loin on l’entend à peine. . . Pourtant elle finit par entourer la substance rétive, celle-ci peu à peu devient une presqu’île, puis une île, puis un îlot, qui finit par être submergé à son tour, comme s’il s’était finalement dissous dans l’océan s’étendant à perte de vue...
Le lecteur qui serait tant soit peu familier avec certains de mes travaux n’aura aucune difficulté à reconnaître lequel de ces deux modes d’approche est « le mien ».
Récoltes et Semailles, § 18.2.6.4. La mer qui monte...
Kay waxes Hegelian here, but I wonder if there's a knowledge component as well: when one builds tools properly at level N, one learns which parts of a problem are best addressed at that level, and which should be handled elsewhere, but that learning involves an opportunity cost, and if that time could have been spent learning something more directly useful to one's project, it's better to use existant tooling, no matter how suboptimal.
... in programming there is a wide-spread 1st order theory that one shouldn't build one's own tools, languages, and especially operating systems. This is true—an incredible amount of time and energy has gone down these ratholes. On the 2nd hand, if you can build your own tools, languages and operating systems, then you absolutely should because the leverage that can be obtained (and often the time not wasted in trying to fix other people's not quite right tools) can be incredible.
— Alan Kay, VPRI Memo M-2004-001 6
WRT learning by going from results to definitions (dually to the traditional presentation?), TIL that at least one department of a breakaway technical college somewhere in the fens characterizes their courses by giving samples of the sorts of questions one ought to be capable of answering by the end of the course.