Agile Careers

 

Jim ("Cope") Coplien is an old C++ shark who now integrates the technological and human sides of the software business as an author, coach, trainer, and executive consultant. He is one of the founders of the software pattern discipline, and his organizational patterns work is one of the foundations of both Scrum and XP. He currently works for Gertrud & Cope, is based in Denmark, and is a partner in the Scrum Foundation. He has authored or co-authored many books, including the recently released Wiley title, Lean Architecture for Agile Software Development. When he grows up, he wants to be an anthropologist. 

Log in to register a comment.

Subscribe here.

Blogs Blogs
« Back

The Difference between Theory and Practice

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.

Comments
Trackback URL:

Really informative and well written post. I agree with you--one has to make a compromise about breadth and depth and your view of having a deep understanding about your core competency and having a working knowledge of the closely related fields is spot on. Zen and the Art of Motorcycle Maintenance is one of my favorite books too. And you last paragraph, I couldn't agree more. Great stuff. Read all your previous posts.

Posted on 6/17/11 8:24 AM.

The real message of "Zen and the Art of MotorcycleMaintenance" is, for the protagonist, to find himself, rather than to understand the motorbyke. And yes, to understand a language the best thing to do is to write its compiler but no, Diderot was right. We can understand everything reading the first chapter of the Bible which explains, by metaphore, how civilization was born and knowing the principles of Freud's main ideas. So you understand society, people and, with a little more effort, yourself.
You mai find me at http://www.amemetisse.net, or you may find my thoughts in "Il tantra dell'ingegnere", Altromondo Editore, 2009. Sorry! Both my blog and my book, for the moment, are in Italian! But I'd be pleased to email in English with anyone interested.

Posted on 6/19/11 11:48 PM.

Staying employed in this industry is a three dimensional problem: staying broad enough so that your skills are not limited to one company: maintaining adequate depth in a marketable area so that you are not viewed as a newbie (assuming you seek a more senior position): and appearing to be the right demographic so that interviewers and potential bosses are not put off.

Posted on 7/12/11 12:55 PM.