True to the unpopular predictions of my friend Haim Levendel 20 years ago, computing has become a commodity industry. Computer and software merchandising isn't much different in 2011 than it was for dish soap in 1960. Both academia and industry know this, and we have been through one or two decades of The Great Dumbing Down.
We’ve come a long way from Diderot, who held that all the world’s knowledge could be captured in a single, although encyclopedic, book. The data on the Internet grows tenfold annually. We simply can’t know everything any more. We have three choices:
- Be a Jack of all trades and a master of none.
- Strive for breadth
- Strive for depth, and leave the breadth issue to team diversity (as I discussed in “Build on your Strengths” some seven installments ago).
If you’ve been reading my previous contributions, you’ll know by now that I value exploration outside one’s comfort zone. Innovation is crucial to most engineering endeavors, and most innovation comes from linking otherwise disparate ideas. This is popularly recognized in research and by the literature; for example, see Johnson’s “Where Good Ideas Come From.” If you have broad foundations, you’ll be better as an individual at working through general problems.
However, we’re still stuck with the fact that we can’t know everything, while success generally depends on a grounding of deep knowledge. Teams sometimes feel safety in numbers independent of experience, but endeavors launched with these assumptions usually end in failure — many failed startups that went forward without business acumen stand testimony to this.
Speaking practically, you need a combination of breadth and depth. My main message here is: Start by striving for depth, because starting conditions are crucial. My secondary message is: Let experience be your guide.
How deep should you go? I’m a depth person. I subscribe to the old saw that the best way to learn a programming language is by writing a compiler for it. I have to admit that I have much empathy for, and was perhaps inspired by, the classic novel "Zen and the Art of Motorcycle Maintenance." Pirsig takes us into a vision of the relationship between rider and machine that starts just as an intellectual toy: How, exactly, do the adjustable shock absorbers work? The relationship becomes more personal with long-term experience. I know that if I shift at this many RPM I can avoid carbon fouling on my spark plug. Eventually the senses shift from monitoring the tachometer needle to recognizing just the right whine and roar in the engine. You need thousands of miles of experience to get a feel for such things.
Let’s say that I was serious about learning object-oriented programming. With Java as my learning tool, I could learn enough to carry on cocktail party conversations and write code for most common environments on Earth. Most contemporary academia adopts such a commodity approach. But if I instead sought a deep learning experience, I would choose Smalltalk, forced to make the paradigm shift instead of being sidetracked by populist compromises. Or, with a good mentor and Ruby or Python in hand, I could better appreciate Kay’s original object vision of programming instead of missing the point in a forest of classes. Then, with experience, I could approach Pirsig’s ideal and know the human experience of OO programming.
As I wrote in Re-making Yourself, fundamentals are crucial. If you want to learn a concept, start deep and narrow to first master the basics. Then the real application and learning can start — with adaptation and experience.