(A post in my “Role Models” series…)

When you’re a twenty-something computer geek, the pace of the software industry doesn’t worry you much. You’re full of energy and enthusiasm for your chosen career, and you’re confident you’ll quickly absorb whatever wasn’t covered during college.

Add a decade or so, and you may see the world a bit differently.

Expertise and Moving Targets

Is mastery possible when your instrument keeps changing? Photo credit: Wikimedia Commons

The rate at which new technologies burst on the scene, acquire mindshare, and demand the attention of engineers can be overwhelming. A journeyman’s knowledge on a given subject may be obsolete long before it matures into mastery. Gartner’s hype cycle can make your head hurt.

If you aspire to excellence, the dawning realization that you will never learn it all (you can’t be perfect on breadth), and that even in a narrower problem domain where you might specialize, flux will erode your skills (you can’t be perfect on depth) might cause some angst.

Maybe you’ve read Malcom Gladwell’s Outliers. Yo Yo Ma put in 10,000 hours to become great at the cello; what are you supposed to do if your instrument changes every year or two?

My friend Julie has an answer.

Learning to Learn

I first met I’ve blogged about before). Julie had much more experience than I did; she taught me abstract factories and dependency injection, loose coupling, declarative programming, streams, unit testing, XP, and many other key concepts.

At first I thought Julie just plucked these ideas out of an impressive mental archive. She had rich and varied experience, and she seemed to know so much.

As I came to know her better, however, I realized that knowledge was not her great talent. Sure, she knows a lot — but more importantly, she learns a lot. The XP she taught me — that came from a book by Kent Beck that she’d just finished. The loose coupling? Scott Meyers, Effective C++. Again, recent reading. Fancy template techniques? Alexandrescu, Modern C++ Design, just barely published.

Julie was constantly, steadily learning. She subscribed to the C++ User’s Journal. She played around with new boost libraries. When she got an assignment to improve the build system, she tinkered with Perl, then decided she wanted to learn Python and threw herself into the effort with gusto. One weekend, she wrote a Python module to manage advancement in her foosball tournament; within a month or two, she was teaching the rest of us. She was always adding new books to her bookshelf. She went to conferences. When we had to have support for LDM and dynamic disks in our disk management layer, Julie volunteered, studied the relevant specs, and quickly rolled out library extensions.

What I learned from Julie’s example is that a superb software engineer isn’t so much an expert on a technology; a superb software engineer is an expert student of technology.

Learn to learn. In the long run, the engineer who’s mastered that skill will deliver far more business value than a narrow subject matter expert. And she or he will have a lot more fun surfing the turbulence of the tech industry.

Thanks for the lesson, Julie.

Action Item

Identify a few habits you could form to help you learn more, more often, and more easily. (Check out this post for some ideas.) Start working on them.