31–40 of 84 posts
There are two kinds of programming books. Some are technical references covering a specific technology (usually a tool, library, or framework); I generally find these to have a short shelf-life and to be lower in quality. New versions of software can quickly result in their obsolescence, and sometimes the examples and precise details are not accurate even when published. However, I have found such books to be _essent…
There are two kinds of programming books. Some are technical references covering a specific technology (usually a tool, library, or framework); I generally find these to have a short shelf-life and to be lower in quality. New versions of software can quickly result in their obsolescence, and sometimes the examples and precise details are not accurate even when published. However, I have found such books to be _essent…
Spot on ; we might need a name for this second category of books ("technology-agnostic"?). These are the books I want to search for in a bookstore ... without getting polluted by the unlimited variations of "Teach Yourself in 7 days" or "Learn with ".
Sometimes, though, you just really need help coming up to speed on a bunch of accidental syntax and incantations to get the job done.
They sit on the shelf gathering dust until I eventually make a project needing some of the knowledge contained within. I then dust it off, scour the index for references to, say, "lock-free multithreaded programming", and read as many sections as I can about that, and as many supplementary chapters as are needed.
A few years back, in my teenage years, I read a programming book about compilers cover to cover, I don't remember much about the contents, just one or two lexing techniques and something about directed acryllic graphs.
Back then, when I would get a book on a subject I was familiar with, lets say C#, I would skip to the chapters I felt I needed more understanding of or what interested me at the time. (technique #1)
If it's a brand new technology, I'll read the intro chapters that go over the basic stuff (technique #2) to help me get accustomed to the syntax and nuances of the technology, then apply technique #1 (which could be the rest of the book for new stuff).
Build a mental map of where to find things, and then refer back for details as needed: 1. Skim the whole book. The goal here is to learn basic concepts, keywords, and the structure of the book. 2. Start coding, refer back to the book as I encounter things I don't understand. This works better with paper books, because it's easier to remember where I saw something ("upper corner of left-hand page next to diagram, towa…
More on skimming: Start with table of contents (topology) then index (vocabulary) if present. Read summary of each chapter, starting at back of the book, working to front of book. Based on that survey, deep dive into new/interesting (to you!) chapters in order of priority. Reference earlier chapters as needed.
I get at least two, preferably three data sources on the same subject. Read them all in Parallel and take notes. Getting multiple perspectives is critical.
What works for me is two well-made textbooks and a Youtube series, iTunes university, etc course.
““In almost all textbooks, even the best, this principle is presented so that it is impossible to understand.” (K. Jacobi, Lectures on Dynamics, 1842-1843). I have not chosen to break with tradition.”
–V. I. Arnold, Mathematical Methods of Classical Mechanics [5], footnote, p. 246