Between my MA and PhD programs, I worked briefly at a research lab that addressed artificial intelligence-type questions, mostly in the context of building training systems for corporations and government agencies. Among other projects, I worked on a program that taught negotiation, using expert feedback from Roger Fisher and the Harvard Negotiation Project. It was a great experience: I learned a lot about pedagogy, about project management (and, thanks to our client’s needs, got an all-too-personal introduction to the idea of the mythical man-month) . . . heck, I even learned some LISP!
But the most valuable thing I learned was from an officemate at ILS, Greg Downey, now the director of the School of Journalism & Mass Communication at the University of Wisconsin. Greg explained that I should consider it part of my job to try out new technology regularly, even if it didn’t seem directly connected to our work.
He wasn’t advising me to just waste time, or surf aimlessly. Instead, he argued that by experimenting with browsers, applications, plug-ins, and settings, you learn a ton about technology. You learn about interfaces, about how programs interact with one another, and you get ideas for your own work. (You also get all of the skills necessary to follow the Tech Support Flowchart.) As academics, there’s also something valuable about being a novice.
A few guidelines:
- Set boundaries. There’s a pretty clear line between “I’d like to understand a bit more about using my mobile device” and “I want to play Angry Birds Space for 4 hours.” It’s worth saying that, when I knew him, Greg was a programmer, and programmers have the greatest excuse ever for playing around.
- Force yourself to
fiddle. There’s a lot of internet folk wisdom about just how few users ever change the default settings in any application–and nobody ever learned about anything by accepting defaults. If there’s something redeemable about the most basic sort of screwing around on the internet, then you actually do need to see what happens when you change things.
- It’s ok to quit a particular experiment. There’s no reason to consider an abandoned blog a failure, or punish yourself for only using some web service irregularly. After all, it’s just an experiment.
This is the moment to acknowledge that many organizations have adopted IT policies that prevent this sort of learning-by-doing approach. After all, it’s *much* easier to lock computers down and accept a certain level of ignorance from users about the technology they use–even if that ignorance encourages risky behavior. Shared governance bodies should push back against policies that prevent users from installing software or extensions on work computers. Training and experience are better long-term solutions than overzealous prohibitions.
“Pick a new thing regularly and try it” sounds like trivial advice, but it’s a surprisingly effective way of ramping up your technical knowledge and comfort. When I started at ILS, I knew two things about computers: jack and squat. And while I obviously got some formal training there, I still think most of my practical know-how came from dedicated playing.
Photo “Congratulations your now a qualified Storm Trooper” by Flickr user Maximus_W / Creative Commons licensed BY-2.0