I’m finishing up a book about learning desktop Linux.
One of the challenges of teaching people to use desktop Linux is that immersion is really the best method. I learned Linux by throwing Linux on my laptop and living with it.
Most people learn operating systems this way. People buy a computer with either OS X or Windows. OS X users might switch to Windows and eventually learn the Windows way of doing things. Windows users might switch to Macs and eventually learn to use OS X. And if someone can’t adjust, she’ll switch back. The challenge of Linux is that it has such a small market share. It’s not on people’s radar in that same way other operating systems are. Plus, there isn’t as much hardware that ships with it. So learning Linux is also about installing Linux, and also, to a certain extent, getting Linux working on hardware. That can make it challenging to get people to take the plunge into Linux.
With all of this in mind, I created a technical book that’s really a guide to helping people immerse themselves in Linux. It’s about learning specific things, like how to use the command line, but it’s also about helping the reader to think about how she likes to work, since for me, the great strength of Linux is its customizability.
This attempt to defer to the reader and have them bring in their own experiences is unusual in technical books. Technical books are traditionally the voice-of-god model: an expert filling a novice’s assumed-to-be-empty head with knowledge.
This vessel-filling strategy never felt right to me. I’m an academic librarian at a community college. I teach. While I would never in a million years consider myself Frierian, apparently I am. Paulo Freire was an influential educator whose most famous work is Pedagogy of the Oppressed. There is no way I can do the book justice, but my personal takeaway has always been that education (and by extension, many technical books) are too often built on the assumption students and readers come to lessons and books completely devoid of prior knowledge and experience. As Freire said, when writers and educators make that assumption:
“Education thus becomes an act of depositing, in which the students are the depositories and the teacher is the depositor. Instead of communicating, the teacher issues communiques and makes deposits which the students patiently receive, memorize and repeat.”
I wanted to communicate with my readers, which meant seeing them as engagement partners, not empty vessels:
“Knowledge emerges only through invention and re-invention, through the restless, impatient, continuing, hopeful inquiry human beings pursue in the world, with the world, and with each other.”
In terms of teaching Linux, this meant presenting options to the reader, but not always having a “right” way to accomplish a task. For instance, if you want to copy a bunch of files, you can do it via the command line or through the file manager. Both methods are valid. Both have advantages given the situation. But I’m trusting the reader to make sense of how to apply what they’re learning. They learn the skills and then reflect on how to deploy those skills.
People learn by doing, but they also learn by reflecting. Technical books tend to focus on the former, but not necessarily on the latter. Reflection is an important part of learning any technical framework, but it’s especially important with desktop Linux which might be used in a much more personal way than a programming language (plus, desktop Linux doesn’t have a compiler to tell you if what you’re doing is correct).
Richard Stallman, a programmer whose work was used to help build Linux (and like Freire, the owner of an amazing beard), has a surprisingly similar take on how people truly learn (emphasis mine):
“Free software encourages everyone to learn. The free software community rejects the ‘priesthood of technology,’ which keeps the general public in ignorance of how technology works; we encourage students of any age and situation to read the source code and learn as much as they want to know.”
The tension of writing a technical book is making it specific enough so that the reader learns a skill (my worst nightmare was writing the equivalent of Bittman Haikus), but open enough so that the reader learns how to think about and deploy the skills learned in a way that feels natural and self-directed.
Linux is perfect for this approach because it provides so many different ways to solve the problems of desktop computing with very few incorrect answers. After a month of using Linux every day for everything from writing, to surfing the web, to watching movies, a new user will find herself comfortable using the new operating system, but perhaps just as importantly, will have a sense of how she wants to use her system, rather than how she was told to use it.
Learning Linux by immersion is useful because it gives the user the opportunity to solve problems, from the mundane (“What is a codec?”) to the profound (“What do I want my desktop to look like?”). A good technical book doesn’t just show the reader how to solve those kinds of problems, but also lets the reader reflect on why they’re important problems to solve. When the reader internalizes the why of a problem, the how becomes a lot easier.