Several of my peers recently asked how I’ve become knowledgeable about technology. I remember the first time I was asked: I was taken aback and didn’t know how to respond. Even dispensing with modesty, I never thought that I was ahead of any of my peers in this area, given how pervasive technology, and technologists, have become.

I continue to assert strongly that my domain specific knowledge isn’t nearly atypical but in fact is often below par. This is especially true in comparison to the people with whom I surround myself. Though, I have noticed that there are a lot of people here at Columbia who want to know more about technology but don’t really know how to do it. Most people think that an education in computer science will get you there, but learning how to learn aside (which itself is infinitely important), most of the stuff I’ve learned that is practical came from outside of the classroom.

I’ve since been reflecting on what I’ve done to further myself toward becoming a “master of the universe” (a technical term that means to be a domain expert). I’m definitely not there yet and I still have a lot to learn, but the fact is that I am continuing to learn. I force myself to learn. Taking into consideration peers of mine who are even better than I am as well as present and past mentors, here are some suggestions for becoming more aware and knowledgeable about technology. By no means is this authoritative or even deeply experienced advice. I’d be interested to look back at this list in a few years and see what I’d change myself.

Personal anecdote #1. I first interacted with my future uber-boss, Joe, at a panel discussion where I asked him a question. I followed up with him in an email after the talk with a few more questions, asking for references to learn more about his domain of expertise. He saw an opportunity and asked me to lunch to talk about my interests. We seemed to click well and have similar goals, and the rest is history.

Personal anecdote #2. I was walking around near the South Street Seaport one day when I saw this tractor trailer that had the APC logo on it and a satellite on top. I walked around it and noticed the telecomm hookups it had. This was not your average bigrig. Even knowing what the company does, I didn’t really get why it had a truck parked in the Financial District. I told an executive-looking guy who shortly emerged from the truck who I am and asked what it was. He said, “You’re interested in this,” brought me inside, and introduced me to the chief engineer of this mobile datacenter project (a precursor even to Project Blackbox) whom I chatted with for a quite a while. It was a fun afternoon being able to geek out in a random location.

Read lots of dead-tree (meaning with physical pages) books. The first time though, just skim for overarching ideas and skip the details. Gain understanding on what a Linux bottom-half is, but don’t worry about knowing the source file they should be in. Figure out how a right outer join differs from an inner join, but don’t worry about knowing the implementation-level details of a B*-tree. Once you do this type of skimming, you should be conversational in a technology, you should be able to have a decent conversation with an expert in the field and show him that you know a thing or two. Then, if the book or subject interests you, read for the details. Master the book, read every word, and experiment with what you’ve learned between chapters. Don’t read dozens of chapters at a time or it won’t sink in.

I often visualize the domains of knowledge I’ve come into contact with; this visualization takes the form of a long one-sided corridor with lots of doors. The topics I know most about are rooms that are brightly illuminated whose doors are removed and the topics that I know only exist are doors with labels. Whenever I start I new project, I think about this. I think about which doors I’ll have to open to explore in order to finish the project.

Read lots of periodicals. Once you have a foundation in a particular domain or technology, periodicals are the best way of keeping on top of the goings on of that topic. This is how professionals stay professionals. Start with an accessible magazine, like Linux Journal, which doesn’t focus too much on any one thing. Once you get an understanding of the area, you can select something more specific like scientific or technology-specific journals and conferences. Included in periodicals should be electronic sources like Slashdot (for a 10,000ft view; please don’t read the comments and definitely don’t post any), wikis, and blogs.

Get a good RSS reader. Once you amass all of these sources of information, it’s far too cumbersome to visit each of these websites. Let the RSS reader do the heavy lifting for you by retrieving articles and presenting them in one place. Set it to poll only every few hours, or else you’ll spend all day reading the news.

Read a few papers. Scientific papers are how information is transferred from the guy who first thought of it to guys who can think about it more. They represent fresh knowledge, available to use to your advantage. Some of the ideas presented in papers are absolutely infeasible, but others are gold. Papers can be boring and hard to read, but give it enough practice and you’ll be read for what matters. Papers are great topics for discussion groups (see below).

(For the record, I regularly read Usenix’s :login, Linux Journal, ACM Queue, IBM’s Journal of Research and Development, Intel’s Technology Journal. There are lots of blogs I normally read. I also frequent the proceedings of various conferences, like VLDB, SIGIR, and LISA; I really like reading these papers on the subway.)

So read a lot. But, amidst reading, don’t forget to practice and investigate what you’ve read first hand. Look at code from professionals. Write some code, either toy code or a patch (see next two points). Run some queries. Do something.

(Jeff Atwood just published an extremely similar article to this one. He links to another similarly good piece by Rob Walling. If this pertained to you, read those too.)