Reading To Learn Tech?
-
I'm reading a book right now (Real-World Cryptography - Manning Publisher[^]). In chapter 3 it provided a code example of how to generate a MAC (Message Authentication Code) using Rust. It didn't give the crates (import libraries) that were required. :| (I'm slow, I need everything.) Also, the example was two functions for generating and then reading the MAC but there was no example of the input (I'm slow, I need everything). Which brings me to my point. Do you notice that books get you so far into a subject (about 1 - 3 chapters) and then they get so far out there that you cannot move on further? You're just stuck. The author has left me behind. (I'm slow, I need everything.) So I have a lot of books that I read first 3 chapters & then fall into oblivion. (I'm slow, I need everything.) Well, that is my experience. Does that happen to you?
Yep, been there. I think during my career (now over!) there's only been 3 books that I really worked through: 1) Z-80 Microcomputer Handbook (published in 1978, when I built my first computer). 2) Starting Forth 3) Understanding Digital Signal Processing All the other tech books I've purchased just provided bits and pieces, basically just filling in specific blanks.
-
I'm reading a book right now (Real-World Cryptography - Manning Publisher[^]). In chapter 3 it provided a code example of how to generate a MAC (Message Authentication Code) using Rust. It didn't give the crates (import libraries) that were required. :| (I'm slow, I need everything.) Also, the example was two functions for generating and then reading the MAC but there was no example of the input (I'm slow, I need everything). Which brings me to my point. Do you notice that books get you so far into a subject (about 1 - 3 chapters) and then they get so far out there that you cannot move on further? You're just stuck. The author has left me behind. (I'm slow, I need everything.) So I have a lot of books that I read first 3 chapters & then fall into oblivion. (I'm slow, I need everything.) Well, that is my experience. Does that happen to you?
-
Yep, been there. I think during my career (now over!) there's only been 3 books that I really worked through: 1) Z-80 Microcomputer Handbook (published in 1978, when I built my first computer). 2) Starting Forth 3) Understanding Digital Signal Processing All the other tech books I've purchased just provided bits and pieces, basically just filling in specific blanks.
My knock-down, number-one, all-time stranded-on-a-dessert-island favorite book is... Programming Windows 3.1 [^] by Charles Petzold (only $99 right now at amazon :laugh: ) It was a complete and thorough software development training guide. I wonder if "kids these days" would even read a tome like that?? Now all they want is "what's the javascript that makes this do that?" :laugh:
-
My knock-down, number-one, all-time stranded-on-a-dessert-island favorite book is... Programming Windows 3.1 [^] by Charles Petzold (only $99 right now at amazon :laugh: ) It was a complete and thorough software development training guide. I wonder if "kids these days" would even read a tome like that?? Now all they want is "what's the javascript that makes this do that?" :laugh:
I was deep into embedded programming by the time the Petzold book came out so I only did a little bit of it. It was a good book, but not real relevant to what I was programming for. On the Windows side I mostly did RAD (VB, Delphi, C++ Builder) programs for test equipment.
-
In a sense, maybe relish it. Be persistent and figure it out. You'll learn things the example wasn't ever going to otherwise teach you. Many folks learned to do this before StackOverflow (or even Google) existed. Different people have the different modes of doing their best learning. I think that it is inherent to the craft that learning to dig is maybe, in essence, learning to do. That said, hiding all the shovels is understandable but disconcerting. OTOH, rooms full of shovels are almost as bad and maybe worse.
Perhaps the answer is that when you find too few or too many shovels, find another resource for learning. Use the shovel count as a gauge of the adequacy of the resource - and this number will vary by individual, some want all the shovels up front to study, some will want only the needed few for that point in the process. Personally, I like having all the shovels up front. I want to look at all the examples and all the dependencies all in one heap, and I may skip the explanations and directions in favor of spending more time with the actual code. For that reason, I avoid books on coding and though I enjoy a good tutorial vid - a code-along - I don't learn nearly as well as when I can just see code samples aplenty.
-
I'm reading a book right now (Real-World Cryptography - Manning Publisher[^]). In chapter 3 it provided a code example of how to generate a MAC (Message Authentication Code) using Rust. It didn't give the crates (import libraries) that were required. :| (I'm slow, I need everything.) Also, the example was two functions for generating and then reading the MAC but there was no example of the input (I'm slow, I need everything). Which brings me to my point. Do you notice that books get you so far into a subject (about 1 - 3 chapters) and then they get so far out there that you cannot move on further? You're just stuck. The author has left me behind. (I'm slow, I need everything.) So I have a lot of books that I read first 3 chapters & then fall into oblivion. (I'm slow, I need everything.) Well, that is my experience. Does that happen to you?
This is extremely common and is caused by the fact that almost no authors use "test readers". When I thought I was done writing my C++ book intended to be suitable for people with no previous programming background, I found a test reader to read it. I basically had to rewrite the entire book because as an expert, I couldn't understand how much she didn't already know. The result? I got fan mail from readers, for a technical book. Why doesn't anyone else do this? I don't know with certainty but I can guess: it's a LOT of work. Another issue is that you need someone who can tell you in detail what she doesn't understand. This is not a common ability.
-
This is extremely common and is caused by the fact that almost no authors use "test readers". When I thought I was done writing my C++ book intended to be suitable for people with no previous programming background, I found a test reader to read it. I basically had to rewrite the entire book because as an expert, I couldn't understand how much she didn't already know. The result? I got fan mail from readers, for a technical book. Why doesn't anyone else do this? I don't know with certainty but I can guess: it's a LOT of work. Another issue is that you need someone who can tell you in detail what she doesn't understand. This is not a common ability.
-
Great post! Is your book available on Amazon? Thanks for sharing that great story & I agree with you about it being a lot of work. I think that is why Charles Petzold's books were so long (and so great).
Thanks! Yes, although it is out of print there are used ones available on Amazon at a reasonable price, or you could get the Kindle edition (not recommended because the formatting isn't that good): https://www.amazon.com/Dialog-Programming-Standard-Library-ebook/dp/B000ZJP35S[^]
-
Thanks! Yes, although it is out of print there are used ones available on Amazon at a reasonable price, or you could get the Kindle edition (not recommended because the formatting isn't that good): https://www.amazon.com/Dialog-Programming-Standard-Library-ebook/dp/B000ZJP35S[^]
Very interesting. Fantastic introduction by Eric S. Raymond (a world-class author himself). Also, interesting that you explained that you thought the reader would read the chapters multiple times. I have always had to do that (started out in 1992 with C++ for Dummies and wore that book out). I would read 1st 3 chapters, give up for a while. Start again, read 1st 5 chapters. Give up. Start again, read 1st 5 chapters again. Give up. Start again, read 1st 6f chapters. Give up. etc. I always felt like an idiot.
-
Very interesting. Fantastic introduction by Eric S. Raymond (a world-class author himself). Also, interesting that you explained that you thought the reader would read the chapters multiple times. I have always had to do that (started out in 1992 with C++ for Dummies and wore that book out). I would read 1st 3 chapters, give up for a while. Start again, read 1st 5 chapters. Give up. Start again, read 1st 5 chapters again. Give up. Start again, read 1st 6f chapters. Give up. etc. I always felt like an idiot.