Nifty - a much larger number of much smaller pies.

Linuxfest Northwest is going well. We're tucked away in the back room of a back building, and Iain and I had to scramble last-minute to cover some things we hadn't prepared to talk about.

I was quickly reminded that I'm much better at facilitating conversations than I am at making presentations; I don't like "performing," but I do like talking to people and hearing what they have to say (and usually to prime the pump I have to give some background info anyhow, so I end up doing a much more relaxed mini-presentation and not realizing it). I'm therefore scrapping all my talks tomorrow and having everyone get out of the classroom rows and gather around to toss about ideas instead.

How will this scale if I become a professor and get assigned to teach a 300-person lecture class? I don't know. Not very well, most likely. One thing I'd love to do someday is take an acting course or two because I have rather significant amounts of stage fright (I am a very shy introvert - most people don't know how much it exhausts me to be "social" and talk to folks I've never met before). Stage fright makes me talk fast, babble, and not think coherently. I need to feel connected to my audience to be comfortable - actually, I need to think of them as dialog partners rather than "An Audience."

Talking with some folks after the conference today, I was also reminded of my strange dance between software and hardware. Well, not so strange; many electrical engineers have gone into software before. Thing is, I keep wanting to "go back" to hardware even as I move deeper into software, just as I want to "go back" to engineering even as I get more involved with education. I itch for the tactility of making things, but know I'll have a richer experience if I come at both from an oblique angle.

For the hardware/software dance, I usually explain it as a desire to learn good software (particularly open-source) development practices, both the effable (tools used, procedures...) and the ineffable (unspoken community norms and attitudes picked up via osmosis). From my limited experience with hardware development, hardware folks could learn a lot from software folks about good tools and processes for making stuff. I haven't learned enough of it myself to nicely articulate exactly what they could learn - ask me in another few years and I'll probably have a better answer. So there's the "I'd like to learn from this field and bring it to the other one" aspect, but there are other parts to the equation as well.

The overromanticized bit is that there's something nice about code that stands between the solid grubbiness of engineering implementations of Real Stuff and the the gleaming asympotic mental fit of theory. There's a tantalizing hint that here is fantasy made flesh, castles springing up when you as much as exhale ("paste!" "buildout!"), mental constructs manifested with as little manual labor as possible, and where mastery implies the power to appear as if you make things just by thinking. A few magic words, a twiddle of fingers, and BAM. The world outside your screen changes. That's harder to do with stuff that requires physical manipulation and creation of objects. It takes longer.

It's also easier for me to participate. In a distributed, text-based world, I have no input processing problems whatsoever. (All right, I'm working on the languages thing - but let's assume this text is in English.) No straining to hear, no delayed reactions brought on by trying to figure out what someone said. I feel like my quality of thought is higher in this medium because I can devote my concentration to thinking about the conversation at hand and the work to be done rather than deciphering the blurred sounds that come from other people's mouths. I'm working on finding a hardware community that works this way - there are several groups I'm starting to like, but I need to make something to check out how well the new theoretical system of collaboration-with-people I'd like to use will work with hardware.

For the education/engineering dance, I usually explain it as "I want to learn how engineers learn before I learn to be an engineer again." I'm fascinated by the process by which makers are made, mostly because it's still foreign to me, like how a second language you learn as an adult never feels quite the same as your native tongue, no matter how fluent you may become. I can forgive my slowness in going along the "conventional" route of learning engineering (a route I couldn't traverse fast in any case) by making my slow journey "worth something" by observing it and writing it down and trying to study the journey itself while I'm taking it.

At least these are the stories I tell myself now. They may change in the future; they usually do as new interpretations present themselves.

Oh. I was quite tempted by a book on getting started with kernel development (and another on device driver development) today, along with a thick sysadmin reference. 20% off. These are all things I'd love to learn, but I know I shouldn't spend money now, nor get books to haul back to Boston, nor bite off more projects because I've got plenty to chew already - but I really ought to find a way to take these things on as an assignment at some point... One thing I never have a hard time coming from a place of abundance for is things I'm fascinated by and want to learn and do.