Wanting to be something vs. wanting to do something

Julia Evan’s article on becoming a kernel hacker reminds me of the the early 90s, when earnest young hackers dutifully ftp’d down the latest Linux kernel patch file and excitedly ran make config to see what new stuff had been added, the rebooted immediately to check out the new uname sweetness.

Rarely was there any real reason for this other than bragging rights on IRC, although occasionally there would be some excitement when a previously unsupported sound card showed up as supported. Mostly it was just enthusiasm, for running one’s own server, making one’s own choices about how the machine would be maintained. We’d all been living under the unspeakable tyranny of root on the university shared UNIX machine, so this kind of freedom was a big deal.

The credits file did not go unnoticed, and the names contained in it were (at least to me) like stars on baseball cards; Ted Ts’o, Alan Cox, Dave Miller. These guys were my heroes, hard-hacking, hard-flaming intellectual monsters. These guys weren’t writing software, they were writing a freaking kernel. No libc for these guys, just a compiler and a bunch of registers and interrupts and all that good stuff. Hard core.

This was in 1993, and although my secret wish was to hack on the kernel myself, I didn’t dare commit the embarrassment of asking on the Linux kernel list the obvious question of “how can I become a kernel hacker”, although it got asked weekly at least by shameless newbies. It is still being asked today.

The problem I encountered is that, every time I opened up the editor to “hack on the kernel”, I was faced with the immediate and overwhelming problem of “what am I going to hack?”. I could start by fixing some typos, although I’m not really sure what I would do with the patch once I figured out how to generate it in the right format. I could try to find some bugs and fix those. There wasn’t kernel Bugzilla at the time though, so it was tricky to find them. I could add a new driver for some unsupported piece of hardware, only, I didn’t really have any money to buy unsupported hardware, and I didn’t have the foggiest clue how one would go about writing a driver for a piece of hardware.

I never really got off the ground as a kernel hacker, until one sweet day years later, when I was working as a system administrator for the university. I had installed (probably Redhat) Linux on a re-purposed server that had a DEC FDDI card in it. Somebody had ported the driver written by Matt Thomas, who did a bunch of drivers for some of the Tulip and various other DEC DEFPA/DEFEA Ethernet/fddi cards, to Linux. I went to build a piece of software, Samba I think, on this machine, but it crashed immediately on start-up with a segfault. After spending a few hours trying to figure out gdb, I managed to find that one of the structs that contained the hardware address for the NIC was the wrong length in the kernel header (Ethernet uses a 48-bit MAC but FDDI was something else).

I was a kernel hacker! I fixed it, and it worked, and I excitedly sent off my one-line patch to anyone and everyone. I got word back from the driver maintainer that he’d gotten the same patch from a few other people and that he would get it into the next kernel revision. Eventually, need have necessitated hacking on the kernel, but I wasn’t special; at least three or four other people had found the same need.

Over the years I have wanted to be all kinds of things. A musician, a kernel hacker, a crack C programmer, a Erlang programmer, a builder of fine musical instruments, an amateur radio licensee, a system administrator, a manager of software developers, a mixing engineer. I’ve lost count of the things in which I have held short-term avocational interest.

Now that I’m older, I’ve had an opportunity to work with at least one instance of a genuine professional example of each one of these jobs that I’ve lusted over. One thing has been true for every single one of them; none of them, not a single one, wound up in that position intentionally. In other words, the kind of lust that I had to “be” a certain kind of person did not get a single one of those people into the perhaps enviable jobs they were in. I remember reading Robert Love’s story about how he got started working on Linux; he’s probably an exception to my rule, but he was also self-motivated in an extraordinary way.

What puts them there, in general, is need. At my last job we had a team of guys whose jobs were to write code (some open-sourced, mostly not) that ran in kernel modules. Over the years these guys had gone from writing C, to writing IP routing code in C, to eventually being called up to have some of the routing code run in kernel-space, etc. They’d been thrown into the trenches by need.

It’s a gradual transition built upon layers and layers of accumulated skill. The reason that people like Alan Cox and Ted Ts’o show up in the kernel credits file is that they have invested a lifetime of study and effort in the design and operation of microprocessors, so transitioning to a relatively big Linux kernel was a natural step, not necessarily a first step.

It is folly to give young people advice about how to be something, because you cannot become something by will alone. We become things in response to need, not solely as a consequence of desire. Many of the things I’ve wanted to be, like a Erlang programmer, I eventually got the opportunity to become, but only after paying my dues. Programmers are in a kind of partnership with the people who pay them; my employer is willing to take a risk on paying me while I am learning a new language and not producing, but only because I’ve demonstrated a skill for learning new languages. It’s a good tradeoff for each of us.

Although we have to be careful to protect these wishes in young people, I think we also have a duty to disambiguate to young people that prestige is usually the product of an enormous volume of work. If a young person wants “to be a kernel hacker” but doesn’t know how to run an assembler, how can he or she know whether kernel hacking is something enjoyable? Perhaps writing a few small programs in x86 assembly is a better way to test the waters than struggling to read the LKML. It’s harmless enough to give some token advice, but finding a way to help these kids capitalize on their enthusiasm working on fundamentals would be better.