Because talent is no excuse for arrogance.
Among my real-world attributes is a surprising (to me) baseball fandom, and an allegiance for the Arizona Diamondbacks in particular. I excuse this by telling myself that baseball competence is an exercise in the balance between indvidual achievement and teamwork, from which any software developer could learn. Yeah. That sounds good. (One of these days, I'll get around to reading Jeff Angus' Management by Baseball; it hasn't made it to the top of my pile, yet.)
Anyway, I was recently watching a baseball game in which rookie pitcher Clay Zavada was shown heading to the bullpen... carrying a bright pink My Little Pony backpack — diametrically opposed to the image you (or at least I) have for a macho 6'1" guy with a 1.69 ERA and an impressive mustache. That's because new ball players are always given the yucky jobs, such as carrying the snacks and drinks out to the bull pen (which apparently was what was in the backpack), explained the TV color analyst (and hall-of-famer) Tom Candiotti. The vaguely embarrassing scenario was entirely deliberate and completely traditional. Because, he said (indirectly) guys come up from the minor leagues hyperaware of their talent, which can lead to just a teeny bit of arrogance. The hazing process isn't necessarily mean, but it does serve to put the new guys in their place. Candiotti didn't use the expression, but I think "pecking order" might apply here.
This got me thinking about the nature of talent, arrogance, and apprenticeship in the software industry as compared to other industries. (Perhaps this is not a good thing; can't I just sit still and watch a baseball game? Look, you'd need a distraction too, if your team lost a game in which they had a 7-0 lead.) For example, one great thing about being a junior writer in the computer press is that the editor-writer relationship is inherently a mentoring relationship. Someone is actively correcting your text, teaching you to polish whatever raw talent you have, and giving advice on how to improve yourself. A junior writer may not listen, and not every editor does improve your prose, but the mentoring opportunity is built into the process. (I like to think that I did listen, as an apprentice, and thus I am forever grateful to the editors who took the time to tell me when I screwed up.)
As the pink pony backpack demonstrates, the baseball community also has its own established way of teaching the youngsters that they not are the be-all and end-all of talent. And certainly baseball and other sports have a long tradition of coaching: individuals whose role is help players improve their skills. But I don't think that software development necessarily has this process built-in. It's entirely too easy for a programmer to keep that unearned "I am the best!" attitude for way too long. And the code will always show it, not the least of which is in the "WTF?" rate for others reading the rookie's code.
One of the first steps in teaching someone is ensuring that they listen, and that means they believe they have something to learn. None are so sure of themselves as are the young. As Mark Twain wrote, "When I was a boy of fourteen, my father was so ignorant I could hardly stand to have the old man around. But when I got to be twenty-one, I was astonished at how much the old man had learned in seven years."
Have you ever ever met someone who knew more about computing or any other topic (in his own mind) than does a recent college graduate? It's necessary to remove that patina of talented-beginner arrogance in order to ensure that the person learns that she doesn't know everything (a common malady that irritates the people around her) and perhaps more important, so that she can begin to translate "talent" into ability and skill.
But the software development community doesn't have anything like that baseball hazing experience, and it has even less an established way to arrange mentoring relationships. Some companies do encourage mentoring, others hire interns (though I've privately been worrying that fewer interns actually get mentoring rather than just a pile of boring stuff nobody else wants to do), and some development processes (such as code reviews) can serve this role. But are they common enough? A motivated developer can always find a community of people to help her acquire new technical or business skills—but do you really think that arrogant beginner would reach for that?
However, I don't pretend to be clued-in on this. Tell me: how does your team teach the rookies the social and technical skills they need to know? Does it involve pink pony backpacks?
You should follow me on twitter.