Writing

Software, technology, sysadmin war stories, and more. Feed
Wednesday, October 12, 2011

Learning from existing programs instead of courses

On a few occasions in the past, I was asked to recommend a book on how to learn a given programming language, or Unix, or something else similarly technical. I usually don't have a good answer, and this leads to disappointment on the part of the person asking. Some of these conversations resemble this:

"You know C, right?"

"I guess."

"Which book did you read to learn it?"

"No book, not really."

"Didn't you learn it from a book in school?"

"Nah. I picked it up from reading source code and playing with it."

"Source code?"

"You know, Apache, Samba, the Linux kernel, IRC clients, those things."

"Oh."

At this point they are usually disappointed and go away. This is not my intent. I really do not have any recommendation for books for most technical subjects. I've always gotten the best results by looking at what's already out there and trying things until it lines up with whatever internal schema I may already have (or creates a new one).

There are a few notable exceptions. First of all, I got started with BASIC way back when by starting from my original VIC-20 owner's manual. At some point, it basically tells you to go out and get the Programmer's Reference Guide, so we picked one up at Toys R Us and that was that. I don't suppose anyone wants to learn about BASIC or what memory locations to frob on a VIC-20 to make colors and sounds happen, so that's of limited utility these days.

When it comes to Unix, I had to bootstrap from something. It's kind of hard to just drop into an environment unless you have some notion of what to type to get more info. For that, there was a little book which was published in 1992 called "The Internet Companion". On page 117, it has about a dozen Unix commands, including the three which mattered to me: apropos, whatis, and man.

All of my Unix knowledge came from that starting point. The trick was that you'd start reading a man page, and then it might say "See also: this(2), that(1), other_thing(5)". I kept following those pointers and discovered all sorts of interesting tools.

Incidentally, reading man pages is how I know that you can tune a file system, but you can't tunafish.