I just uncovered this book review on William E. Shotts Jr., The Linux Command Line: A Complete Introduction (No Starch Press 2012) I left as a half-done draft months ago. In it, I found a long collection of thoughts on learning programming from books and what common problems are. The book review will still follow at some point, but these are some of the examples of common problems with ‘computer books’.

The typical computer book: a long detail-rich, reference-like read

I like the Intro to the Linux commandline a lot, but also found that it was very long in pages but the content isn’t super dense. So it was a very long read and I’m always ambivalent about books which are reference-like and super-long. I am a person who likes to read and even I put off reading this book for a long time. I read a chapter every morning while having breakfast. Some chapters I just skimmed because they didn’t contain too much content. The book is absolutely fit for a complete novice. However, I think a novice might be overwhelmed with the lengthy read.

Often people who start using the shell have concrete use cases they need solved first. They can’t take months to get through these 36 chapters. And it has to be noted as well that you are by no means a masterful shell user after these 36 chapters either. The book only covers basic concepts after all.

Thoughts on ‘computer books’ for learning

Problem 1: The ‘pace’

For me personally, I found that the ‘pace’ of the book seemed to get slower and slower. Maybe it doesn’t really change but you feel like it because in the first few chapters, you are still newer to the material. Later it tended to get repetitive. Every option was explained for smaller shell programs. Which is probably not a bad thing since it doesn’t hurt to have heard about the possible options for very central shell utilities. But then again, you won’t remember them all anyway. So I’m not really sure what to think about the approach. I think it is not 100% optimal to be read as an introductory book. The level of detail and the length rather resemble an (almost) complete reference book. But you don’t read references like you read a book. (I mean, ok, I do. Quite often, actually. But I also do definitely pass as weird.)

I think this is an imbalance which is often the problem with tech books. They either want to cover everything thus the reference-like style will make it hard to read in the beginning (possibly scaring reader away who will never finish the book), but then get increasingly dull once you’ve worked through the first few chapters. Or on the other side tech books are often too difficult when you’re an actual beginner but boring once you acquired only a little bit of hands-on experience and gained understanding about the matter (or programming in general).

I haven’t really found the perfect way to solve it. I think it’ll have something to do with creating a document which is theoretical, with sufficient examples to make it practical but not too many to lessen the universality of the content being taught. The focus should be on the universal more than the exemplary because the exemplary can be covered with a simple tutorial. There needs to be a ‘more’ in a book. It needs to be more didactical and cover more universal elements. It needs to provide the bigger picture so a reader can link what they have learned with what they already knew.

Problem 2: progression

The next difficulty is progression: Like I already said, the reference-style intros have a steep learning curve in the beginning because there is no didactical reduction but afterwards, there is no progression either. There are programming books which offer a short introductory chapter to even out differences in reader’s previous knowledge to a more or less uniform, sound baseline. This is a good idea but often done only to allow the authors never to be didactical again throughout the rest of the work. I imagine they write out the contents of the book ‘for themselves’ like they would anyway and then add an intro chapter to make sure their writing is ‘accessible’. So an intro is good but not added for the right reasons. It should not be an excuse to not reflect on your didactical concept.

I don’t say it is a bad thing in general. But I’m not sure it’s great practice either. These books contradict themselves in the way that on the one hand, assume the readers’ insufficient previous knowledge (why they offer an intro in the first place), on the other hand they write for a very advanced reader (a skilled programmer). So, hm, I don’t know how to strike a good balance between those two extremes. Some books offer ‘optional’ chapters and inform reader in their preface which types of readers might be interested mainly in which chapters. Maybe this is a reasonable thing to do. It also forces the authors to write an introductory block which is quite uniform but covers all the basics and then, start clean with the actual new content of the book, on the base of the fundamentals taught before.

That way, an advanced reader can ‘butt in’ after a few chapters but will still find a consistent reading experience and a beginner is cared for as well. Optionally, a few ‘extra’ chapters can be added at the end which are geared only towards very advanced users, so they can get the same amout of information out of the book as a beginner who had ‘a chapter of their own’ in the introduction.

As a bonus, each chapter should contain a little one-page self-assessment in the style of “Read this chapter if you… know how to… and….. If not, please gather this information from chapter 1 first.” or “Read this if you want to learn XY.” That way, readers can be sure that they are in the right place. In my own experience, I often wanted to skip chapters but was afraid to miss out on something, even though I knew that these chapters were long and likely to bore the pants off of me. Maybe it would be enough to be very explicit about what the topics covered per chapter will be and which previous knowledge is expected. That way, a meaningful progression can be provided for readers with different skill levels without having to majorly include this logic in how you write the chapters themselves.

Problem 3: Owning books but never actually reading them

It is my belief that even people who actually buy computer books only very seldom read them, cover-to-cover. Because technically adept people often aren’t the biggest readers in general. So why do people write books for them which are five times as long as a ‘normal book’? I think it is because they are reference-style books.

But then again, I don’t necessarily need a physical reference book. This is not what physical books should do in my opinion. They should be reasonable sized enough that you can take them along on your commute, so you – for once – have something better to do than stare at a screen, for instance. Also this fact that computer books often aren’t easy to carry around makes me suspect they’re acutally references and nobody ever took the time to make them more didactical. Of course, there are some very hands-on ‘workshop’-style books which are well done didactically. But when I look at my bookshelf, most of them aren’t.

Problem 4: Intros too simple, references too advanced

And, for what can be said for the didactical intro books: they hardly cover anything remotely interesting for more advanced readers. So that’s not great either. Which is maybe also one of the reasons advanced readers seldom read books to learn new skills. Because these books are written, time and time again, for a complete beginner and a complete beginner only. Computer books with the goal of teaching should be more universal than that and manage, somehow, to work for beginners and more advanced users simultaneously. Like maybe using an introductory first and advanced last chapter, so everybody is cared for. Then the main middle part can be very neutral in style and everyone is happy.

I, for one, as an avid reader of programming books but not a complete novice anymore, am starting to get a bit annoyed at the fact that most ‘Intro to XY’ books are all either written with a complete programming novice or seasoned uber-expert in mind. I mean, gearning books towards novices is nice. But once you want to learn more than one programming language (and learn it using books), you will receive 500 introductions to variables. Which really is dispensable after you’ve understand the concept. That is after having it explained to you once. And the super-expert-y books are just the same in the other extreme.

I feel like a few years ago, introductory books using a language used to be named ‘Learn programming with LANGUAGE’. But now, even many more specialized books (like, for an arbitrary example, ‘learn DataViz using D3.js’) are implicitly ‘learn programming using’ but they don’t say it in the title. And the contents of ‘learn programming’ and the ‘intro to LANGUAGE’ are mixed in the same chapter and thus, need to be read together. But I can be ‘not new to programming’ but still ‘new to R’ or whatever language you want to learn. So another way to make things better would be to provide two different intro chapters: One which gives a short intro to programming with only as few as necessary examples (from the language in question) and then maybe another chapter for the language. This ‘Intro to LANGUAGE’ chapter should itself be splitted in two parts. A quickstart guide which gives you a speedy entry to the language with the main concepts you’ll need all the time. And then maybe provide a short reference-like appendix giving more details on or a listing of datatypes, reserved words, a few string functions, IO, whatever it is people feel a novice really needs to know. (Hint: They don’t. Ever.)

So, these are some of my ramblings on learning programming from books. Many of these problems might come with the sheer volumes of programming books coming out since programming really took off as a mainstream thing. Well, anyway. Hope somebody found this interesting at least 😉

Best,

the NInja