(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
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 Julie Jones when I was in my early 30’s. We worked together on the “new engine” initiative at PowerQuest (a pivotal experience 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.
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.
16 thoughts on “Julie Jones: Learn voraciously.”
Thanks for the great ideas that you are sharing. I will be putting them into effect for myself.
Quite by accident, I just came across this post from Andrei Alexandrescu (C++ guru and major proponent of the D programming language), in which he argues that learning how to learn is the most important skill for any technophile: http://www.informit.com/articles/article.aspx?p=1945828
I have this stupid idea for a startup: gather three to six people together, to learn Common Lisp and mathematics, and then make things up as we go from there. So, in a way, I would like to be in the business of learning!
In some ways, I’m not so interested in learning, as I am in discovering new things. Some of it may be written down, because it’s been done by others; some of it may be done for the first time (or one of the first times, if you have no idea that someone else discovered the idea before you, yet independently of you). Indeed, Alan Kay once said, “The best way to predict the future is to invent it.”
Of course, ultimately, discovery is just an extension of learning!
Sounds like a fun dream, Alphy. I agree that discovery is exciting. Maybe that’s why I like software as a career field; it gives me a fertile field to learn and experiment.
Love the Alan Kay quote; it’s both true and profound.
Greetings! Very useful advice within this post! It’s the little changes which will make the most significant changes. Many thanks for sharing!
I agree. Needing to keep learning might seem like a big item on a to-do list, but it can (and should) be done here a little, there a little. My post with tips for tech learners was an attempt to capture some small habits with big benefits.
This is wonderful advice and one we can all apply. Thanks for sharing and for following my blog. Bendiciones ; )