David's Books
I'm reaching the final corner of having training as the focal point of my occupation. After 8 years, it's with mixed feelings that I look back. I will not, for example, forget the first class I ever taught: New Horizons, Portland, Oregon, a group of 12 open faces in my direction, and smiling (almost laughing) to myself when I turned to write my name on the board. What on earth could these people learn from me?
Each night, I would go back to the hotel room and open my secret weapon: my coworker David, who'd been teaching longer, would loan me his books and I'd go back and copy his notes into my own ugly, massive, white and yellow binders. David's notes were like his thinking: a clear, concise, simple line that went straight across a concept.
On my own my thinking and expression were squiggly but with David's notes to straighten me out I'd come across without my usual spastic, tangential flair.
I'm thinking of David's books because this week I'm teaching a descendant of one of those old courses, and I remember copying everything - even his line of questioning - for explaining a concept related to file attributes as the file was moved on a file system. Only subtleties have changed since then, and as I go through the material I remember how David explained things and how I copied, copied, and copied on the road: Santa Clara, Jefferson City, Atlanta, and many other places.
I've been teaching less and less, and the further I get from it, the less capable I become in expressing myself1. I'm now used to mashing a piece of software into doing what I want, what I care about, and leaving the gaps as an inarticulate blank.
Many people think in the premise: those who can, do, those who can't, teach2. It makes those who teach on a full time basis squeamish and Napoleonic. It is assumed that they never use (in "real life") the tools they show others to use, instead they somehow hobble from class to class based on what they learn in books and their training material3. This blue collar approach to understanding training is everywhere, from HR departments to implementation folks.
But after more than two years distance from having to teach an operating system I realize that I've haven't stopped to think in a straight line and I've forgotten a lot of what David's notes taught me. I've gone from really asking myself, "what exactly is a filesystem?" to formatting, installing, Googling, and compiling, Charles Bronson style: haphazard.
People who teach technology are book people, with more theory than practice. A large part of this revolves around having conversations with hundreds of different Charles Bronsons who employ technology for problem solving's sake, rather than for understanding4. It's different when what you know must apply to many people, not just yourself.
What is often worse about technology people is that not only are we, in general, only about solving our own problems, it's a sign of stupidity to ask about the fundamentals - to think like a real engineer. During my first teaching assignment at Intel I was saved by this Emporor's New Clothes effect. Not really understanding DNS from David's notes, I opened the section (after a few minutes in the bathroom thinking I was going to vomit) by saying: "So, you all know what DNS is, right5? ... great, we don't have to go into depth here."
The trick is finding a junction between theory and practice, understanding and solving, and still managing to sleep at night. I don't believe it's an impossible mix, but it's a deliberate mental state: thinking in David's straight lines instead of escaping from real understanding with the excuse of "it works now."
Even as I move away from teaching people programming languages, I hope that I'll bother understanding exactly how
if($pal =~ /^(w+)w?(??{reverse $1})$/)...
works.
1I think the more that one "does" something, the more one begins to skip steps, make adjustments based on circumstance, and develop a slant in their approach.
2There is something to be said about "learning by doing," but there must be component of study for it to be complete in a field as cerebral as system administration or programming.
3There are scores of bad trainers, and especially when technology was "hot," a lot of people did it because it was lucrative. But to add to this, the failure of a trainer is a very public thing, unlike the failure of a software project or investment scheme (which tend to be swept, quietly, under the rug). Finally, many trainers are subject to ridiculous expectations and circumstances.
4Real understanding is an elusive concept. I'm glad some people devote themselves to pursuing it.
5I'm ashamed to say I used this ploy for other things. Take it from someone who taught for a long time - people are anxious to pretend they know something until you ask them to explain it in these terms: tell me what it is as though I'm a 13 year old.
6:56:15 PM 
|
|
