Tech Books Second

I heard a joke the other day (on .NET Rocks). Something to the effect of “you know what make good door stops? Old JavaScript books.” The point of this joke is that the JavaScript language changes really fast, which is true, but the joke got me thinking. What are technical books good for at all?

People certainly write plenty of them, and publish plenty of them, and, free markets being what they are, I can only conclude that this means that people buy plenty of them. But what good are they? I mean, we can lookup syntax on StackOverflow and just muddle through other people’s code samples on the internet to learn programming, right?

Learn Fast By Alternation

I think that technical books are supremely helpful, but that you have to use them second. Here’s a good example: I did some self-teaching mostly in Java and Python, did an internship in C#, and now work mostly in C#. About 4 months into the C# job, I picked up a copy of C# in Depth by Jon Skeet. It was a wonderful experience. I had enough context to understand what was being written, and I found that I progressed quickly.

The same thing happened again with git. I started using git for side projects about a year ago, and had some fun and some confusion, which I gather is a typical experience for people starting out with git. I was figuring some things out, developing some side projects that were version controlled on Github, and then I started reading Pro Git. The same thing happened. I had enough experience and enough context that the book made sense quickly, and was prompty helpful. Therefore, I am going to propose a bit of general advice for using technical books:

Read technical books second, after you’ve muddled through a bit.

I think this rule really might just a be a special case of watching your input/output ratios. In other words, if you start by reading a technical book right away, your input/output ratios will be all out of whack; you’ll be way too input-rich to retain anything. But if you muddle through for a while, you’ll have a backlog of questions. Then when you read, some of your questions will be answered, so you’ll remember what you read. After you’ve read, go back to writing more code for a little while; you’ll have a backlog of things you read about but want to try. Your code will improve from trying new things, and you’ll retain the reading better because of the practice. Repeat.

Look Up Syntax Elsewhere

There are many good reasons to by a technical book, but a desk reference for the syntax of <insert language here> is not one of them. Online searching, StackOverflow, and StackOverflow’s new documentation section are much better suited for that.

Also, since we know we’re not using our technical books as reference books to look up documentation, we will make different decisions about which technical books to purchase at all. For example, if you see a book called A Pocket Reference to Haskell Syntax, you may want to keep looking; pocket references are slow, non-scaling Google. Instead, I recommend looking for books that you choose based on the quality of thought and writing. My favorites recently have been Jon Skeet’s book, mentioned above, and Steve Krug’s Don’t Make Me Think, Revisited. These books are quite different from one another, but they have one thing in common: You see useful human thought if you read them. Don’t buy a book so you can look up the order of arguments for some formatting function on page 634; get a book with large chunks of useful human thought in them instead.

I think choosing technical books that are well-written is also particularly important. I’ve always found that if I read the same author a lot, I’ll begin to sound like him, if only a little bit. Unconscious imitation is a major part of human language. Therefore, I really recommend only reading books that are a joy to read; forcing your head through garbage technical prose will only increase the odds that you’ll write garbage technical prose of your own one day, and the information you get will be harder to remember than if you’d read good books.

Fundamentally, I think human brains enjoy learning, and books that really take your imagination (and take your whole afternoon) are just more fun to read. In a sense, how fun a book is to read can be a decent measure of how quickly you’re learning from the book. (Of course, this can have false positives. Tom Clancy is pretty fun to read, but he’s not going to teach you Python very fast.)

So, do yourself a favor. If you’ve been muddling through a language for a little while, perhaps even having taken your first bite of the elephent, ask around and find a really solid, well-written, interesting book on the technology you’re trying to use, and pick up a copy. Once you’ve done enough muddling that your brain is thirsty for some input, I think you’ll find it very rewarding and enjoyable. And if you find a particularly good one, post it in the comments!

Till next week, happy learning,



Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s