Choose a good book. Read a chapter or two before breakfast. Run all the code examples in your head (probably not needed, just my OCD -- same thing with being reluctant to trust calculations without redoing them myself).
Ask HN: How do you read programming books?
11–20 of 84 posts
Re: Ask HN: How do you read programming books?
#121) Make sure you're reading a quality book. Sturgeon's Law[1] is true -- 90% of everything is crap including programming books. Check amazon reviews, forum recommendations for consensus of quality books. (E.g. many of OReilly "Head First" series of books have cute cartoons but they actually don't have quality content.) 2) Most programming authors do not write about tradeoffs . They write about language syntax or libr…
Head First book author here -- I wrote Head First C#, Head First PMP, and Head First Agile (and three other, non-Head First O'Reilly books) -- and I wanted to push back on your first point. We work really, really hard to include quality content. But I understand why people sometimes make the point that you made; I did the same thing myself at first.
It's easy to dismiss one of our Head First books as less-than-serious if you're not used to the format. There are a lot of pictures. There's a LOT of whitespace. There's redundancy; we'll say the same thing more than once. And most of all, when we do our job right they're not boring -- which, to many people, reads as non-serious. But we find that when people approach Head First books with an open mind, they find that it's actually a really effective way to get a lot of information into your brain quickly and easily.
We also know that while a lot of people love the informal and highly visual format, some people just can't stand it. There are some people who just want a dense, concise, terse book that they can absorb all at once. Readers like that just won't like Head First books. That's why every Head First book starts with an introduction that says who the book is for and who it's not for. Coincidentally, my coauthor, Jenny Greene, and I just did an interview on Dave Prior's "Drunken PM" podcast, and the first question he asks us is about this "Who this book isn't for" section: https://www.projectmanagement.com/blog-post/34188/Head-First...
Short, shameful confession: I had a similar reaction to yours when I first saw Head First Design Patterns; I dismissed it out of hand, ostensibly because there were some less-common design patterns from GoF that it didn't cover, but really because I just didn't "get" the format. A year later, when our editor at O'Reilly floated the idea of writing Head First PMP, I went back to it and really read it, this time with a much more open mind (for example, I actually did all of the code exercises instead of just reading them). I realized why I'd made my earlier mistake in dismissing the book -- and gained a lot of respect for how much work Eric Freeman, Elisabeth Robson, Kathy Sierra, and Burt Bates had put into it. They were really careful about what they chose to cover, and covered those topics really thoroughly. They give you several different chances to "get" each concept, showing it to you from different angles so that you really absorb the full context. They put a lot of care into managing the pace of the book so it's a steady stream of learning and not a flood. They repeated things that needed repeating. And it all works. Really, really well.
I thought I'd understood design patterns pretty well before I really read Head First Design Patterns. afterwards, I was actually better at using them in code in real life. When I'm not writing books or training teams, I'm writing code both professionally with teams and as outside of work. The incredible quality of the content in their book helped me understand design patterns better.
Jenny and I strive to bring the same care to our Head First books. I think we've done a pretty good job of including quality content that's worth our readers' time; I hope they agree.
Re: Ask HN: How do you read programming books?
#13Lately I've been just reading and reading and reading without actually trying any coding. Mainly I've been reading about functional programming, languages I haven't used before, etc. The way I got into programming was through constantly trying to build things, without much formal education. I think once you have a certain amount of real word experience it's important to sometimes take a step back and just try to learn about new things without the distraction or pressure of trying to build something right away. This all depends on a person's point in their career and goals though of course.
Re: Ask HN: How do you read programming books?
#14Build 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.
Re: Ask HN: How do you read programming books?
#151) Make sure you're reading a quality book. Sturgeon's Law[1] is true -- 90% of everything is crap including programming books. Check amazon reviews, forum recommendations for consensus of quality books. (E.g. many of OReilly "Head First" series of books have cute cartoons but they actually don't have quality content.) 2) Most programming authors do not write about tradeoffs . They write about language syntax or libr…
Head First book author here -- I wrote Head First C#, Head First PMP, and Head First Agile (and three other, non-Head First O'Reilly books) -- and I wanted to push back on your first point. We work really, really hard to include quality content. But I understand why people sometimes make the point that you made; I did the same thing myself at first. It's easy to dismiss one of our Head First books as less-than-seriou…
Long time reader of Head First series here. I have finished :
- HF Software Development
- HF Design Pattern
- HF Java
- HF Android Development
I have no complaints. Really, thank you for making those books. They helped me a lot. I think you couldn't have every reader to agree that your book is good because each person has their own taste, but to be fair, yours do a good job in delivering quality content in many aspects under a friendly narrative.
Re: Ask HN: How do you read programming books?
#161) Make sure you're reading a quality book. Sturgeon's Law[1] is true -- 90% of everything is crap including programming books. Check amazon reviews, forum recommendations for consensus of quality books. (E.g. many of OReilly "Head First" series of books have cute cartoons but they actually don't have quality content.) 2) Most programming authors do not write about tradeoffs . They write about language syntax or libr…
Head First book author here -- I wrote Head First C#, Head First PMP, and Head First Agile (and three other, non-Head First O'Reilly books) -- and I wanted to push back on your first point. We work really, really hard to include quality content. But I understand why people sometimes make the point that you made; I did the same thing myself at first. It's easy to dismiss one of our Head First books as less-than-seriou…
Head First books were a great help back when I was starting with programming. I was a teenager and not as comfortable with English as I am now.
Books like Head First Java and Head First Web Design helped me a great deal. I don't know if I would read them as my first option nowadays, but they definitively have their use and are great at what they aim at.
Re: Ask HN: How do you read programming books?
#171) Make sure you're reading a quality book. Sturgeon's Law[1] is true -- 90% of everything is crap including programming books. Check amazon reviews, forum recommendations for consensus of quality books. (E.g. many of OReilly "Head First" series of books have cute cartoons but they actually don't have quality content.) 2) Most programming authors do not write about tradeoffs . They write about language syntax or libr…
Head First book author here -- I wrote Head First C#, Head First PMP, and Head First Agile (and three other, non-Head First O'Reilly books) -- and I wanted to push back on your first point. We work really, really hard to include quality content. But I understand why people sometimes make the point that you made; I did the same thing myself at first. It's easy to dismiss one of our Head First books as less-than-seriou…
>There are a lot of pictures. [...] highly visual format,
Thank you for your response. To clarify, I'm not an elitist that rejects cartoons and informal style. For example, I think the "Calculus for Dummies"[1] with the cartoons is a good math book.
I'm also not really not talking about the visual "clutter" that others complain about either.
Cartoons are fine but I prefer that the drawings/illustrations really impart knowledge or insight rather than "decorate" a book's page like wallpaper.
For example, I looked at "Head First Networking"[2]. Using Amazon's "Look inside" feature to browse some pages:
- page 1: the clipart of the man and woman and the thought bubbles do not reward the user with quality knowledge in relation to the space they take up
- page 19: the clipart of the tourist with the arrows and thought bubble does not actually teach a networking concept
My point is: just because a book has cartoons & unserious style doesn't mean it has good presentation of teaching. It might be a suboptimal book that just happened to use cartoons.
Another way to put it: Comics can be a very powerful way to illustrate concepts but their power is underutilized in the Head First books. The cartoons are often "jokes" instead of teaching.
>which, to many people, reads as non-serious
Similar to cartoons, I have similar complaints about "conversational style" that many authors think helps with pedagogy but it really doesn't. (You can explain things terribly while using a conversational tone, and likewise, explain things clearly with a serious tone.) I'll save that criticism of that for another essay.
[1] https://www.amazon.com/Calculus-Dummies-Lifestyle-Mark-Ryan/...
[2] https://www.amazon.com/Head-First-Networking-Brain-Friendly-...
Re: Ask HN: How do you read programming books?
#18Lately I've been just reading and reading and reading without actually trying any coding. Mainly I've been reading about functional programming, languages I haven't used before, etc. The way I got into programming was through constantly trying to build things, without much formal education. I think once you have a certain amount of real word experience it's important to sometimes take a step back and just try to lear…
I'm in sort of the same place, I'm in a reading frenzy to build up a vocabulary and learn category theory, functional concepts, etc.. While this is good I know I ought to spend some time practicing algorithms or building toys to really make what I'm learning intuitive.
Re: Ask HN: How do you read programming books?
#191) Make sure you're reading a quality book. Sturgeon's Law[1] is true -- 90% of everything is crap including programming books. Check amazon reviews, forum recommendations for consensus of quality books. (E.g. many of OReilly "Head First" series of books have cute cartoons but they actually don't have quality content.) 2) Most programming authors do not write about tradeoffs . They write about language syntax or libr…
Completely disagree on the "Headfirst books" comment.
All the head first books I have read (Java, Design Patterns, Android, C, Ruby) have very high quality content. I have read great books on all these subjects along HFs. i.e. The Design Patterns Smalltalk Companion, K&R, etc. The HF books really help visualize and actually enjoy the subjects, they also have great exercises that help to cement the concepts one has just learned. If any of the HF authors read this, thanks for these books, they have help us a great deal.
Re: Ask HN: How do you read programming books?
#201) Make sure you're reading a quality book. Sturgeon's Law[1] is true -- 90% of everything is crap including programming books. Check amazon reviews, forum recommendations for consensus of quality books. (E.g. many of OReilly "Head First" series of books have cute cartoons but they actually don't have quality content.) 2) Most programming authors do not write about tradeoffs . They write about language syntax or libr…
Head First book author here -- I wrote Head First C#, Head First PMP, and Head First Agile (and three other, non-Head First O'Reilly books) -- and I wanted to push back on your first point. We work really, really hard to include quality content. But I understand why people sometimes make the point that you made; I did the same thing myself at first. It's easy to dismiss one of our Head First books as less-than-seriou…
My first contact with programming at all was through Head First C#! :) Thanks for that! Although I ended up becoming a front-end web developer, it was a great first contact!