Hi everyone! I’ve been reading Chris’s excellent “Metaprogramming Elixir” and “Designing for Scalability with Erlang/OTP”. It got me wondering, how long does it typically take you to read a technical book? How do you read (e.g. one sitting, a chapter at a time, alongside a computer, etc.)? Do you have a project or something you wish to accomplish before you start?
2 Likes
In the past I would usually read a couple chapters at a time and make notes/bookmarks to reference or lookup later. My last book I decided to code along with the information being presented. I usually do about a chapter, maybe less depending on complexity. What I found is coding reinforces my learning exponentially and while its slower, I absorb much more information.
I think it really depends on what your trying to accomplish and the time you have to dedicate to a book. I am always looking at how I could apply information to an existing project or something in the future.
Mine has changed…
When I was learning Ruby (my first programming language) I made hand written notes of all the books I read as I was reading them - and then I would go over my notes before each reading session. I found this really worked well for me because this ‘repeats and reinforces’ things as well as keeps stuff fresh in your mind (even when you have to take breaks). The downside is it takes quite a bit more time (I think it took me about 6 to 8 months to learn Ruby - but still, even that is pretty awesome when you think about what you know at the end of it). Part of the reason I did this was because I wasn’t just new to Ruby, I was new to testing, to MVC, to web frameworks etc and so there was less crossover in the books I was reading - each book was either more advanced than the last or a slightly different topic.
I started doing the same with Elixir, but realised I didn’t need to - because we have so many fantastic Elixir books and quite a few go over the same material. This is awesome - because it meant I didn’t need to write notes anymore 
To make further use of this, I’ve been reading books concurrently - so the language bits of book 1 first, then the same in book 2 - this not only helps ‘repeat and reinforce’ what we read, but it also gives you two different perspectives on the same topic, which is extremely helpful. See my two reviews here for more info on how I’ve been doing this:
I also do not follow along the examples in these books because at this stage all I am interested in getting an overview of what’s possible - I can pick up the details and ‘muscle memory’ when I start building stuff… but the important thing is knowing enough about a language so you know what you can do with it.
I definitely recommend this approach 
it may seem more time-consuming than say reading the docs/guides and getting stuck in, but I genuinely believe it will help you become more proficient more easily and in less time overall.
1 Like
Overall, AstonJ’s experience has been pretty similar to mine.
If I had to sum up my current approach in a nutshell, it would be, “deliberate practice + reps”. Everything else seems to revolve around that.
Actually, I am getting more out of videos than books lately. In some respects, the signal-to-noise ratio is better, since there can be a lot of superfluous material used to fill out pages. For really critical concepts or mechanisms, or simply material that I really want to master, I’ll often transcribe lectures and code along, so I end up with both working code and a set of searchable notes.
1 Like
I need to read a book about five to six times because I noticed that each would deepen my knowledge and I would have more context for the unknowns.
My “reading style” typically varies with what I hope to get out of my “read through” at that particular point in time.
Simply “reading” a book usually just ends up being a survey of the knowledge contained therein - essentially I’m hoping that just enough will stick so that when the time comes, I’ll remember that I have already come across something relevant and remember where I came across it, so that I can revisit and review it in more detail.
“Working through” a book is a totally different and more time consuming affair. For example with Designing for Scalability with Erlang/OTP I immediately coded along in Elixir; used GenServer instead of gen_server, gen_statem instead of gen_fsm; GenEvent instead of gen_event (immediately followed by going through Replacing GenEvent by a Supervisor + GenServer), etc.
Also “working through” involves looking for “second opinions” in other books or on the web - this is especially true for books in early access/beta as some of the explanations may not be as refined as they could be.
Typically I keep notes for early access/beta content - that is just so I can make a more coherent statement when it comes to giving feedback. For a released book I only keep notes if I intend to write a review.
Sometimes I’ll compile some of the content into notes to become part of a technology cheatsheet - when task switching between database, backend stuff in various languages, frontend stuff with various frameworks/libraries and OS admin, I find it’s helpful to have a reminder of “how do I do this again?” when a particular activity hasn’t been reinforced for about a couple of months or so …
1 Like
I agree, and usually I don’t find it appealing (I’d rather ‘code’ stuff that interests me - i.e apps I want to create myself). However I am currently doing Pragdave’s course and I AM following along… because he insists
