My efforts to write about learning Silverlight in Seven Days are filled with omissions and gaps. While each Silverlight "day" really does constitute one day’s worth of studying, they haven’t been contiguous days. One large gap is due to a trip I had to make to Washington D.C. to settle personal affairs. Others were job related since, like most of you, I have to maintain my day job even as I’m expending effort to learn new technology in my off time — which, however, will eventually feed back into my day job. Which invites the obvious question of whether learning technology is really work time or private time. I tend to think of it as private time, since I enjoy it immensely and grow personally by doing it. All the same — and I believe this is not the case in most IT shops — my day job is actually forward looking about this sort of thing, and allows me to spend part of my day learning all the new acronyms coming out of Redmond — in some sense paying me to do something I love. But an equally valid way of looking at it is that I am working to keep my IT shop informed about the best solutions for its upcoming projects, and the reward for the investment of time and energy I make in learning these technologies are ultimately reaped by my company. I am, in effect, investing my company’s time wisely.
Should we choose to look at the matter in this way, then it is important that the time spent on learning technology be used optimally. This is hampered by the fact that information about things like WCF, WPF, WF (the initial "W" is typically truncated, I assume, because it evokes notions of profession wrestling) and Silverlight are poorly disseminated. Half of the effort spent on learning new tech involves tracking down the proper resources, weeding out the unhelpful books that misstate what they can offer and the ones that are just poorly written or misinformed, and finding the correct location for the online resources — including source code — that one needs. Scott Galloway has a great post about this problem over on his blog: http://www.mostlylucid.net/.
The other half is spent actually engorging all the information that is available. There is a scene from Johnny Mnemonic, that peculiar 1995 Keanu Reeves sci-fi vehicle, in which Keanu uploads 300 megabytes of data into his cerebral cortex. In order to prepare for it, he puts a bite guard in his mouth, clamps down and, with evident consternation on his face, yells out "hit me." This is how I feel whenever I prepare myself to sit down with a tech book.
A tech book is not a friendly beast. You cannot curl up with it in bed. You never giggle over a clever turn of phrase and beg your partner to allow you to read her a passage aloud. Instead, it is a big heap of bound paper, generally printed in large type in an apparent attempt to make it seem weightier than it has any right to be, which you have to plow through in a Sisyphusian effort to reach the end. In truth, no one ever gets to the end of one of these things because we all get bogged down in the details. This is natural enough, because the presentation is typically all about the details after the initial chapter, and the initial chapter tends to alternate between vagueness and hello world samples to the point that it just can’t be taken very seriously. But then we get lost in the details. There is so much we don’t understand in reading through these tech books that we become frantic over the thought that we might be missing something important — the key that unlocks all the material we are trying to absorb. The reading process becomes slower and more onerous until finally external affairs draw us back into the life-world or we throw our tech book to the wall where, with luck, it shatters into a million pieces and we never have to pick up reading again where we left off.
Scott Hanselman touches on this point in his post: Books: We Need More So What, Now What, And What For And Less Just What, though it might just as easily have been titled, "Why Tech Books Suck". The essential problem with tech books is that they never work out the inherent paradox of all learning: one cannot learn the whole without understanding the parts; one cannot know the parts without understanding the whole. In contemporary exegetics, this known as the hermeneutic circle.
Aristotle says in his Poetics that tragedies such as Oedipus Rex and Electra are higher and more philosophical than historical works because they aspire to truth, whereas histories merely offer details. I think it is this desire to know the "truth" of a technology — its purpose, its potential, it’s meaning — from a medium so poorly suited to this task, the tech book, that typically leaves us feeling so frustrated and so drained. We get bogged down in details because tech authors get bogged down in details, and it is the exceptional writer who knows how to navigate the hermeneutic circle in order to provide us with a usable tech book — the criterion for usability, in this case, being merely not making us want to throw it across the room.
The quality of tech books is out of our control, however, so we must turn to the quality of reading tech books. Here are my suggestions for how to get the most out of a tech book, so that as little time is wasted on them as possible:
1. Read Online — I use Safari Books Online for my tech education, as well as MSDN and various tech blogs. This tends to make my eyes bleed, but it has the distinct advantage of not lulling me into the illusion that tech books are like other books. Once I start treating tech books like other books, I find that I fall into the habits I’ve acquired for reading fiction and even most non-fiction. I look for a plot and my mind tries to work itself towards a narrative climax that never actually transpires. Tech books don’t have plots. They just are. If you rip out the chapters and put them together in a different sequence, it generally doesn’t matter. Tech books are heaps, not paths. Reading online helps me to avoid this confusion — though it obviously isn’t for everyone.
2. Plan to Re-read — if you set out on a new book knowing that you will re-read it, then you won’t get so bogged down in the details. You can always go back and pick up what you missed later. I generally read a tech book three times. The first time I just skim through the chapter headings so I know what the book is going to cover and what I feel confident about skipping entirely. This can be done in a few minutes. On the second read, I just skim the whole book. I don’t try to do any coding exercises. I just get a good grasp of the principles involved, and the various materials I will need to understand. The goal is simply to get to the end of the book, not to understand it in its entirety. This can be done in a few hours. The third read is used to go back and pick up the important stuff. From the second read, I know that there are things I don’t understand, and hopefully I will have formed an opinion of what is important in the book and what is drivel. In the third read, if a third read is even necessary, I pick up the important bits.
3. Give Yourself Permission to Skip — The fear of missing something important is a paralyzing fear. You have to give yourself permission to skip things when you are reading a tech book. Remember, a lot of the things in a tech book are just filler. The author felt he had to push something in that is actually irrelevant, or the publisher has established a page count for him that he must fulfill. Not everything in a tech book is important. Marshall McLuhan developed a habit of reading only the right hand pages of any non-fiction book (he would read a non-fiction book in its entirety, however). The way he explained it, a lot of non-fiction is just filler, and by his estimation, only 10% or so of any non-fiction book was actually worth knowing — and that was if it was a good book. An intelligent person can fill in the gaps as he goes along. More importantly, the way your mind fills in these interstitial gaps actually helps it to retain information better. The mind learns not by simply replicating what it finds in a book, like some copying machine, but rather by trying to reconstruct and build things in the imagination. In rhetoric, this is sometimes called an enthememe, or a logical argument with gaps. The ancient orators discovered that by not completing a logical argument, but rather by letting an audience piece it out for themselves, they were better able to convince the audience of the rightness of their conclusions. Laying things out for people leaves them unconvinced. Making them work things out for themselves gives them possession of the information, and allows them to make it their own.
4. Talk About What You Learn — Reading a book is useless if you can’t retain what you’ve learned. The best way to retain the information in a tech book is to use it. Unfortunately we aren’t always afforded opportunities to use what we know. We do, however, always have outlets to talk about what we know, and the process of talking not only forms new neural pathways in our brains, thus increasing retention, but allows us to correct our mistakes and misconceptions. Talking to other developers working on the same technology is optimal. If that is not possible, however, blogging or writing to newsgroups can serve the same function. They keep the technology ever in your mind, and you can add on to it or take away from it as you go along.
All of this may be pretty obvious, but then one would think that figuring out how to write better tech books should also be pretty obvious — and it isn’t. Learning new technologies is generally considered one of the "soft" problems of IT. By now, however, we have all had enough industry experience with reading tech books that it is clear this is not the case, and it is probably time to throw tech books onto the mound with all of the other "hard" problems of IT, like how to retain good people and how to complete a project on time.
