Friday, January 7, 2011

Whence programming greatness?
In programming -- probably in almost any creative field (Oh; how radical! Programming is creative! It's not just a modern form of manufacturing!?) -- technology is kinda important, so is that ethereal thing known as methodology. But towering over them in importance is people-ology. In fact, my primary itch in running a consulting firm is trying to dig into that idea, with implications such as "I'll take the best people, and mediocre programming tools and languages, you take the cool tools and languages and average people, and I Will Kick Your Bottom" (and spend less money). I spend a large part of my thinking time trying to develop answers to the following four questions:
  1. What are we trying to build? It's such an obvious question, I think sometimes we forget to ask it. Just what does an excellent person look like at any given stage in their development? What does their work product -- code, writing, effect on others -- look like?
  2. What are the pre-requisites? I reckon that some of the things that make for a superb programmer must already be in place at a young age. If you don't have those, I can't give them to you. (Nor would you want me to, since they're probably fairly basic aspects of character.) This is getting into the "10,000 hours of deliberate practice" stuff. But I need more detail. As Geoff Colvin explains in Talent Is Overrated: What Really Separates World-Class Performers from Everybody Else, 10,000 hours is merely the penultimate rung (the final one being the attainment of greatness itself) in a multi-rung ladder to performance. Achieving 10K hours itself, depends on passion. Passion, in turn, depends on a degree of confidence that the goal being sought is achievable (otherwise no one is going to go through the pain and suffering of the 10K hours in the first place). And even confidence isn't the bottom line. 
  3. What are proxies for (potential) greatness? The best way I know to see if someone is, or could become, really good is to work with them for at least a year -- longer if they're just fresh from university -- and see what they produce. But an internship is measured in only weeks or months, and those are only useful for youngsters. If I'm hiring an allegedly experienced person,  using a normal selection process -- interviews and stuff -- then my time is going to be measured in only hours or days. Now it may be that there's no good answer here other than the "work with them for a year and see" approach. But even if that's true, I'd still like some early indicators -- things I can spot in some kind of interview process -- that I may be onto a good thing. And just asking some cute puzzles is not, I think, enough.
  4. How do we amplify? So, we've agreed on what we're building, we know what a candidate has to bring to the table, and we've figured out a way of spotting it. Trouble is, the difference between a bright-but-inexperienced youngster (or even an experienced person but from a non-consulting job) on the one hand, and a battle-hardened Verilab consultant on the other is very large. So what do we do to turn potential into actual? Well, if "training" -- at least in the usual sense we mean it in Europe and North America -- is much more than about 10% of this answer, I'll be surprised. For various reasons, the education systems of said continents are substantially clueless when it comes to the challenge of taking high-potential technical youngsters, and turning them into high-actual technical professionals (in the best but rarely intended sense of that last word). Fixing that is probably the single best way to improve new product development the world over.
At first sight I guess those are statements of the blindingly obvious. But, as Feynman probably never said, "if you think you understand how to build greatness, you don't understand how to build greatness".

No comments:

Post a Comment