Oh, I almost forgot the OTHER things that make learning difficult today:
-
Volatile development tools and APIs that mutate & become obsolete faster than they can be documented and learned.
-
The âfrictionâ imposed by ebooks and âonlineâ documentation.
Back in the Commodore 64 era, documentation started out âOKâ, and only got better over time, because for all intents and purposes it was a nonmoving target. AFAIK, Commodore Basic (shipped with the c64, and an option to use with the c128 in c64 mode) literally never changed from the day the first c64 rolled off Commodoreâs assembly line until the day the final c64-compatible computer capable of running in âc64 modeâ did.
Sure, the c128 had a better BASIC that wasnât compatible with c64 BASIC, but AFAIK, even THAT was a nonmoving target⊠it existed on the c128âs final production day exactly the same way it did on its first.
Over time, the c64/c128 got BETTER development tools, but the old ones continued to work exactly the same way THEY did. Old versions had bugs that got fixed, new features were added, and LATER models of the computer ITSELF might have had problems with really old software, but it was basically UNHEARD OF for a program that worked on your computer, with a set of hardware you had for it, at some point in the past, to suddenly and spontaneously quit working in the future.
The Amiga was volatile compared to the c64/c128 (the jump from 1.3 to 1.4/2.0 broke a LOT of stuff), but it was downright STABLE compared to a platform like Android (where new updates come out at semi-random every few weeks that can and do break things that worked 15 minutes earlier).
The problem is particularly acute with Android. For the past few years, Iâve been wanting to learn how to use Jetpackâs new features, but finding documentation that wasnât confusingly broken was nearly impossible. Following Androidâs changes is hard enough when you ALREADY understand a particular advanced topic⊠trying to debug a program when you arenât sure whether a problem is due to a mistake YOU made, a typo in the documentation/tutorial, a change made by Google after the documentation youâre looking at was made, or some combination of all three, is immensely frustrating.
Iâm immensely thankful not only that Michael Fazio wrote a great book about it, but also that I got lucky enough to discover and begin reading it within weeks of its first printing, and before Google had time to inevitably wreck it by their next upcoming wave of major changes a month or two from now.
Which brings me to point #2⊠Android is so volatile, eBooks are almost the only form of documentation that can be kept up to date⊠but for technical documentation, eBooks really, *really * SUCK, for a whole laundry list of reasons:
-
Like software, technical books have âdesign patternsâ of their own. One of the major ones is, âDiagram or overview on one page, explanation and details on the facing pageâ. Ebooks, especially those made to aggressively re-flow text, completely wreck this pattern. Even when the author/publisher is able to design the eBook to properly put it on one page, or even to make sure it goes on a right-side page with the essential left-side-page content on the page before it, most eBook readers only allow you to view one page at a time, so the whole design pattern goes down the toilet.
-
Most ebook reader hardware is SLOW, and thereâs WAY too much reliance on âgesturesâ to navigate instead of nice, tactile buttons that are themselves engineered to have just enough resistance to avoid unintentional triggering by casual touches.
The big problem with relying upon gestures alone is that they introduce lag and latency. The moment you touch a capacitive touchscreen with your thumb, it has no idea what your intent is⊠it has to study how the touch changes for at least a few hundred milliseconds to tell the difference between a swipe, a mash, a tap, etc. That latency introduces âcognitive loadâ. Itâs not merely frustrating⊠itâs actively harmful to your ability to learn from text.
When you read something, the memory begins to fade from short-term memory almost immediately unless something reinforces it quickly. If itâs a diagram with explanations on the facing page, your eyes can dart over, and the text and diagram can reinforce each other. If youâre reading an ebook and it takes semi-conscious effort to trigger a page-flip & takes a second or more, you donât just suffer from the memory fading and becoming corrupted during the 700-1500ms it takes for the new page to appear⊠thereâs also a HUGE cognitive jolt required when you have to take in the new page, establish landmarks, zone in on the explanation youâre looking for, read it, and connect what youâve just read with the diagram you saw 2-3 seconds ago.
Put another way, itâs not your imagination that itâs harder to learn something completely new and complicated from an ebook than from a traditional book. It IS, and by now thereâs an entire body of academic papers that have begun to explore the toll ebooks take on the learning process.
Online documentation takes a bad situation and makes it worse, because most online tutorial sites are set up to maximize ad exposure, which means limiting the amount of âcontentâ you can see at any one time (without being exposed to more ads), and more often than not, introducing an element of time-gating to slow you down and make sure youâre exposed to the advertising long enough for the siteâs creator to get paid for the ad exposure. Take everything I wrote about the cognitive load imposed by ebooks, and jack it up by at least an order of magnitude. Then, make it even worse, because at least books donât contain ads whose literal goal is to forcibly grab your attention and break your train of thought.
(continued in next post)
