What is Talent if Not Good Design for Programmers? (Talent is No Myth for Programmers)
Posted by Bob Warfield on October 31, 2007
I love the Discipline and Punishment blog, but he’s taken a left turn at Albuquerque when he talks about the Myth of Talent for Software Engineering and then goes on to say:
What is the equivalent of “capital” in programming? It’s not ‘talent’ in any meaningful sense. Rather I’d suggest it’s what most people call “good design.” What’s really paying dividends in any large project is good design simply because design adds value faster than it adds cost. Good design, purely because of its “compound interest”-like nature, is largely what drives success in software and what separates successful projects from unsuccessful projects. The many software projects that fail (really they are abandoned) inevitably do so because of bad design.
I absolutely agree that it is the design and not the languages that matter most, but how else do we measure talent among programmers if not by good design? Who do we look up to most among programmers we know? It’s the Uber Architects. These are the ones that have the good design ideas. Yeah sure there are those guys who crank out devilishly clever but unmaintable code. In the old days, they were called hackers, back before that term was a good thing. It was a term of derision. Great software engineers were the ones with great designs.
Let me provide yet one more reason why talent matters. If you really do believe it takes fewer people to write good code, and there is an overwhelming body of evidence to support that, how could you not also believe that if you have only a few slots on the team it means that talent matters even more?
In struggling to understand whether I’ve misunderstood the original post, I almost get a sense that the wrong meaning is being attributed to the word “Talent” when I see terms like “Rock Star Programmer” being thrown in as bad examples of “Talent”. There are certainly situations where the talent label is misapplied to someone who in fact, does not have the talent. Don’t blame that on the idea that talent is valuable!
I sense a little bit of tendency to feel that the design is handed to programmers, and hence that’s why design and talent are separate. That’s a bad idea! Design is a participative process under the watchful eye of the right benevolent but fascist dictators. A good dictator creates an overall framework that leaves a ton of freedom for individual programmers to express their own design sense in their corner of the world. A programmer who just wants to be handed all the design detail on a stone tablet so he can “write code” is not someone I want to hire or work with on my small teams. The guys I want will leave if they don’t get a hand in design. You will understand a design so much more fully if you participated in creating it. By the same token, I hate the idea of architects that never write a line of code because they’re too busy thinking of great architectures for someone else to build.
There is also a certain uncomfortableness with the idea that talent implies really great programmers are born and not made. Let me lay that one to rest too. I’ve hired hundreds of programmers to work on really difficult software in small teams and I have seen overwhelming evidence that great programmers, programmers with talent, are very definitely born and not made. We’ve built languages and tools of all shapes and sizes, database servers, desktop application software, web software, data mining, genetic algorithms, and a host of other stuff ranging from the mundane to the completely weird. I’ve worked with extremely famous programmers at companies like Borland, and I’ve worked with brilliant folks who are obscure. The one area I don’t have experience with is games, but I think that world believes you’re born and not made too.
Throughout those hundreds of programmers hired, only one pattern sufficed to hire more great programmers. It had nothing to do with age or education. It had nothing to do with giving them clever tests in the interview process. It had to do with whether they’d ever done at least one great thing or not, and whether they could communicate that thing well enough to expose some native design sense. I’ve seen guys with fantastic MIT or Stanford CS degrees (including graduate degrees) that could not program their way out of a paper bag. I’ve seen high school dropouts that started programming relatively late code circles around the average CS grad.
I’m sorry folks, but talent matters, talent is the ability to design software systems and algorithms, and you either got it or you ain’t.
5 Responses to “What is Talent if Not Good Design for Programmers? (Talent is No Myth for Programmers)”
You must log in to post a comment.
The Geeky Blog Updates » Blog Archive » What is Talent if Not Good Design for Programmers? (Talent is No … said
[…] Read the rest of this great post here […]
culturekiosque said
There is also a certain uncomfortableness with the idea that talent implies really great programmers are born and not made. Let me lay that one to rest too. I’ve hired hundreds of programmers to work on really difficult software in small teams and I have seen overwhelming evidence that great programmers, programmers with talent, are very definitely born and not made. We’ve built languages and tools of all shapes and sizes, database servers, desktop application software, web software, data mining, genetic algorithms, and a host of other stuff ranging from the mundane to the completely weird. I’ve worked with extremely famous programmers at companies like Borland, and I’ve worked with brilliant folks who are obscure. The one area I don’t have experience with is games, but I think that world believes you’re born and not made too.
Throughout those hundreds of programmers hired, only one pattern sufficed to hire more great programmers. It had nothing to do with age or education. It had nothing to do with giving them clever tests in the interview process. It had to do with whether they’d ever done at least one great thing or not, and whether they could communicate that thing well enough to expose some native design sense. I’ve seen guys with fantastic MIT or Stanford CS degrees (including graduate degrees) that could not program their way out of a paper bag. I’ve seen high school dropouts that started programming relatively late code circles around the average CS grad.
I’m sorry folks, but talent matters, talent is the ability to design software systems and algorithms, and you either got it or you ain’t.
Leave aside the clever test during the interview process. “If I wanted to know how many pingpong balls fit in the GooglePlane, I’d ask you, ‘cuz you Googleboys are bound to have tried it!!”
I like the idea of asking “Have you done a great thing, and can you tell us about it?” Partly because that got me my last job, not in dev but in product mangaement. Little glimmers of “wow, he really thought this through” surfaced in the interview, I showed the business cost of the problem my tecnhology solved, and the skills I’d used… certainly got me into the job. Of course, I’m not a developer any more…
What’s interesting is that in the end your article seems to reduce judging talent to “Coding circles around someone” which often isn’t the thing to do. Do you want to impress your boss with “1000 parts, every one of them unique, but it still fires?” or “Can be assembled ass-backwards in the dark with half its parts missing and bullets whizzing over your head and runs still fine?” The second one sounds reliable, under gruesome conditions, that’s the skill I’d want.
smoothspan said
Culturekiosque, welcome.
RE: “What’s interesting is that in the end your article seems to reduce judging talent to “Coding circles around someone” which often isn’t the thing to do.”
I think a second reading will uncover this passage, which specifically addresses the problem you mention:
“Yeah sure there are those guys who crank out devilishly clever but unmaintable code. In the old days, they were called hackers, back before that term was a good thing. It was a term of derision. Great software engineers were the ones with great designs.”
Talent, as I’ve said, is about good design. No software engineer will view good design as your example of 1000 unique parts.
The tricky thing about good design is that if you have no good designers who are empowered, you can’t spot it, you can’t hire for it, and you won’t build it accidentally. This is why seriously turning around a botched architecture is very very hard to do. The fish rots from the head and companies have to get someone with great design sense into a position of authority to make the difference.
See my post “Practical Experience With Never Rewriting Software” for more:
http://smoothspan.wordpress.com/2007/10/29/practical-experiences-with-never-rewriting-software/
culturekiosque said
smoothspan said
“It tends to produce smaller, not larger, systems, with fewer moving parts.”
Now we’re on the same page. Couldn’t agree more!
Cheers,
BW