Monday, June 16, 2008

Done, and Gets Things Smart

Disclaimer: I do not speak for Google! These are my own views and opinions, and are not endorsed in any way by my employer, nor anyone else, for that matter.

Everyone knows and quotes Joel's old chestnut, "Smart, and Gets Things Done." It was a blog, then a book, and now it's an aphorism.

People quote Joel's Proverb all the time because it gives us all such a nice snuggly feeling. Why? Because to be in this industry at all, even a bottom-feeder, you have to be smart. You were probably the top kid in your elementary school class. People probably picked on you. You were the geek back when geeks weren't popular. But now "smart" is fashionable.

That's right! All those loser kneebiter jocks in high school who played varsity and got all the girls and sported their big, winning, shark-white smiles as they barely jee-parlor-fran-saysed their way through the classes you coasted through: where are they now? A bunch of sorry-ass bank managers and failed insurance salesmen and suit-wearing stiffs at big law firms working for billion-dollar conglomerates where their daddies got them VP jobs where they just have to show up and putt against the other VPs on little astroturf greens in the hallways!

That's right, los... er, well, some of them are doing OK, I guess. "But they're not as rich as Bill Gates!" That's the other big tautology-cum-aphorism we geeks like to pull out when we're feeling insecure. Notwithstanding that Bill had a rich daddy and made his money through exactly the kind of corporate shenanigans that Big Meat is using on us today, with those selfsame jocks. We like to think the more important point is that Bill, Jobs, Bezos and the other tech billionaires (all fierce, business-savvy people) were geeks, and are thus evidence of the revenge of the nerds. And hey, tech did make a lot of money in the 80s and 90s. So "smart" is sort of in fashion now.

Unfortunately, "smart" is a generic enough concept that pretty much everyone in the world thinks they're smart. This is due to the Nobel-prize-winning Dunning-Kruger Effect, which says, in effect, that people don't know when they're not smart. (Note: people have pointed out that it was an Ig-Nobel. Me == Dumbass. Fortunately, "me == dumbass" was more or less the point of the article, so I'll let it stand.)

So looking for Smart is a bit problematic, since we aren't smart enough to distinguish it from B.S. The best we can do is find people who we think are smart because they're a bit like us.

Er, what about Gets Stuff Done, then? Well, the other qualification you need to be in this industry is that you have to have produced something. Anything at all. As soon as you write your first working program, you've gotten something done. And at that point you probably think of yourself as being a pretty hot market commodity, again because of the Dunning-Kruger Effect.

So, like, what kind of people is this Smart, and Gets Things Done adage actually hiring?

I've said it before: I thought I was a top-5% (or so) programmer for the first fifteen years I was coding. (1987-2002). Every time I learned something new, I thought "Gosh, I was really dumb for not knowing that, but now I'm definitely a superstar." It took me fifteen frigging years before I realized that there might in fact still be "one or two things" left to learn, at which point I started looking outward and finally discovered how absolutely bambi-esquely thumperly incompetently clueless I really am. Fifteen years!

But hell, let's be honest here: I still think I'm smart. We all do. Sure, I've managed to figure out, at least partly, just how un-smart I am, but I've got the whole "I'm smart" thing so hardwired from when I was a kid surrounded by "dolts" who couldn't memorize things as fast as I could, or predict the teacher's punch line way in advance, or whatever questionable heuristic I was using for measuring my own smartness, that it's hard not to think that way. And of course the "dolts" were way better than me at just about everything else. And they think they're pretty smart too! Definitely above average, anyway.

Squaaaaawk

So we all think we're smart for different reasons. Mine was memorization. Smart, eh? In reality I was just a giant, uncomprehending parrot. I got my first big nasty surprise when I was in the Navy Nuclear Power School program in Orlando, Florida, and I was setting historical records for the highest scores on their exams. The courses and exams had been carefully designed over some 30 years to maximize and then test "literal retention" of the material. They gave you all the material in outline form, and made you write it in your notebook, and your test answers were graded on edit-distance from the original notes. (I'm not making this up or exaggerating in the slightest.) They had set up the ultimate parrot game, and I happily accepted. I memorized the entire notebooks word-for-word, and aced their tests.

They treated me like some sort of movie star — that is, until the Radar final lab exam in electronics school, in which we had to troubleshoot an actual working (well, technically, not-working) radar system. I failed spectacularly: I'd arguably set another historical record, because I had no idea what to do. I just stood there hemming and hawing and pooing myself for three hours. I hadn't understood a single thing I'd memorized. Hey man, I was just playing their game! But I lost. I mean, I still made it through just fine, but I lost the celebrity privileges in a big way.

Having a good memory is a serious impediment to understanding. It lets you cheat your way through life. I've never learned to read sheet music to anywhere near the level I can play (for both guitar and piano.) I have large-ish repertoires and, at least for guitar, good technique from lots of lessons, but since I could memorize the sheet music in one sitting, I never learned how to read it faster than about a measure a minute. (It's not a photographic memory - I have to work a little to commit it to memory. But it was a lot less work than learning to read the music.) And as a result, my repertoire is only a thousandth what it could be if I knew how to read.

But when you combine the Dunning-Kruger effect (which affects me just as much as it does you) with having one or two things I've been good at in the past, it's all too easy to fall into the trap of thinking of myself as "smart", even if I know better now. All you have to do, to be "smart", is have a little competency at something, anything at all, just enough to be dangerous, and then the Dunning-Kruger Effect makes you think you're God's gift to that field, discipline, or what have you.

This is why everyone loves Smart, and Gets Things Done, which Joel always writes in boldface. We love it because right from the start it has the yummy baked-in assumption that you are smart, and that you get things done. And it also tacitly assumes that you know how to identify other people with the same qualities!

But... you don't.

It sucks, but the Dunning-Kruger Effect is frighteningly universal. It's a devil's pitchfork two horrible, boldfaced prongs. First:

Incompetent people grossly overestimate their own competence

We already talked about that, right? You're a good programmer! Heck, you're a great programmer! You're "smart", so anything you don't know you can go look up if you need it! Right?

Welcome to incompetence.

The second prong is a bit longer, and has a barbed poison tip:

Incompetent people fail to recognize genuine skill in others

Both prongs are intrinsically funny when you're watching them in action in someone else, and they're incomprehensible when anyone tries to poke you with them. Not necessarily offensive, mind you: you might get offended if someone tries to imply that you're not as competent as you feel you are, but it's more likely (per the D-K effect) that you'll simply not believe them. Not even close. You're smart! They're just wrong! Gosh!

The second prong, that of the ability to recognize true competence, has major ramifications when we conduct interviews. That's what Joel was writing about in Smart and Gets Things Done, you know: conducting technical interviews.

How do you hire someone who's smarter than you? How do you tell if someone's smarter than you?

This is a problem I've thought about, over nearly twenty years of interviewing, and it appears that the answer is: you can't. You just have to get lucky.

It's easy for a candidate to sound smart. Anyone can use big jargon-y words and talk the talk like nobody's business, but I'm living, breathing proof that articulacy doesn't connote any other form of intelligence. Heck, the Markov-chain synopses of my blogs that people post in quasi-jest tend to look like I wrote them.

All too often I find myself on interview loops where the candidate knows a seemingly astounding amount about coding, computer science, software engineering, and general industry topics, but we find out at the last minute that they can't code Hello, World in any language.

This is, of course, one of the failure-patterns that Joel's Get Things Done clause is designed to catch. But interviews are conducted under pretty artificial conditions, and as a result they wind up being most effective at hiring people who are good at interviewing. This is a special breed of parrot, in a way. Interviewing isn't a particularly good predictor of performance, any more than your rank in a coding competition is a predictor of real-world performance. In fact, somewhat depressingly, there's almost no correlation whatsoever.

If interviews suck, then why do we still do them this way?

Lots of reasons. One is just history: everyone else does it that way. Companies tend to hire pretty similar HR departments, and HR tends to guide companies towards doing it the way everyone else does it. Same goes for technical management, which is all too often HR-driven as the company grows.

Another is that interviewing is already a fairly time-intrusive function for the interviewers, and it tends to be miserable for the interviewees. Trying to make the process somehow more rigorous or accurate just exacerbates these side effects.

Another is the "rite of passage" phenomenon, wherein engineers feel that if they had to go through the gauntlet, then everyone else should, too.

So for the most part, everyone does the same non-working variety of interviews, and hopes for the best.

As far as identifying good people goes, the best solution I've ever seen was at Geoworks, where you were required to do a six-month internship before you could get hired full-time. This seems to be the norm in non-tech departments at most tech companies. They often substitute "contractor" for "intern", but it works out roughly the same. Geoworks is the only company I've seen stick to their guns and make it mandatory for engineers.

However, I'm convinced that it only worked because Geoworks seeded the engineering staff with great people. The founding engineers set up a truly beautiful software engineering environment, with lots of focus on tools, mentoring, continuing education, "anarchy projects" to let off steam and encourage innovation, and a host of other goodnesses.

I've been a contractor at companies that had no good engineers at all, literally none whatsoever. A mandatory six-month internship at such companies would only serve to lower their average bar, since anybody competent would leave after the six months was up. This doesn't contradict the D/K Effect. It's easy to spot lackluster, soulless engineering organizations, and doing so doesn't imply that you're especially smart.

The "Extended Interview"

Anyway, I've often wondered where the Geoworks founders found such great engineers. The short answer is: "Berkeley", but I'm really looking for something deeper than that; namely: how did they know?

Along similar lines, I've long felt that Amazon's success was due in no small part to Bezos having seeded his tech staff with great engineers. World-class great. I don't know where or how he found them, since, again, how do you hire someone who's smarter than you? He's a brilliant guy, but his original choices (ex-Lucid folks, by and large) seem a stroke of blind luck that's hard to attribute to mere genius. I'll probably never know how it happened. Wish I did!

They weren't too big on software engineering, though, or more likely they all felt that time-to-market trumped everything else (and were correct, at least in their case), so Amazon is successful but lacks a high-quality software engineering culture. It's gotten much better over the years, of course, but it's a far cry from Geoworks. It's largely up to individual teams at Amazon to decide how much engineering to sprinkle into their coding. There's no central group (or distributed peer group) who can tell any team how to build their software. This is effectively mandated from the top, in fact.

But time-to-market is a pretty powerful business force. Maybe that's the missing link? Lucid was founded by Dick Gabriel, the "worse is better" guy, and Amazon took the "worse is better" idea (internally) to untold new extremes.

Dunno! But it sure worked for them.

Google has a process similar to the Geoworks 6-month internship idea. Geoworks's internship was a form of "extended interview", since it was obvious even in the 1980s that the classic interview format isn't a very good predictor of performance. At Google, you don't have to do an internship. However, unlike at most other companies, you're not "slotted" into a real position on the tech ladder until you've been on the job at least six months. During that time you need to prove that you can function at the level you were hired for, and if it's wrong in either direction your level is adjusted at slotting time.

The "extended interview" (in any form) is the only solution I've ever seen to the horrible dilemma, How do you hire someone smarter than you? Or even the simpler problem, How do you identify someone who's actuallySmart, and Gets Things Done? Interviews alone just don't cut it.

Let me say it more directly, for those of you who haven't taken this personally yet: you can't do what Joel is asking you to do. You're not qualified. The Smart and Gets Things Done approach to interviewing will only get you copies of yourself, and the work of Dunning and Kruger implies that if you hire someone better than you are, then it's entirely accidental.

Don't get me wrong: you should still try! Don't throw the bath and baby away. Smart and Gets Things Done is a good weeder function to filter out some of the common "epic fail" types.

But realize that this approach has a cost: it will also filter out some people who are just as good as you, if not better, or even way better, along dimensions that are entirely invisible to you due to Dunning-Kruger forces mostly beyond your control.

So there's this related interviewing/hiring heuristic that I think may better approximate the kinds of people you really want to hire: Done, and Gets Things Smart.

I'll take Joel's cue and write it in bold so you know it's important. It's not condescending or anything. Really. Let's all recite it together, to make it catchy and stuff. Maybe we should have a little ditty for it, so it sticks in our heads annoyingly, forever. I think the Happy Birthday song will do nicely:

All gentle faux-condescension aside (or as the classroom jocks would have read, "fox condesomething"), Joel's Smart, and Gets Things Done heuristic seems really obvious to everyone. It has this magical "we're all smart in this together" appeal. But sadly, for the reasons I've outlined, almost everyone interprets it to mean "Carbon Copy, of Myself". Great guidance gone astray!

The Done, and Gets Things Smart approach is also a way of finding great people, but it recognizes that the Dunning-Kruger Effect requires some countermeasures. It's modeled on the early successes I've witnessed at Geoworks, Amazon, and Google, all of whom had one thing in common: they hired brilliant seed engineers. This boldface is really addictive when you get started on it!

They all managed to continue hiring great people afterwards, but the seed engineers were the most important. I'm hoping that this is intuitively obvious in much the same way that wanting smart people who get things done is intuitively obvious.

I think you really, really want great seed engineers, and that this is a different class of engineer from the "pretty darn good" engineer we typically hire using Joel's oft-misinterpreted advice.

Seed engineers. It's key. You can apply the "I want ideal seed engineers" rule recursively to an organization, a department, a project, a team, and even your officemates. We're not just talking about startups.

Let me ask you a brutally honest question: since you began interviewing, how many of the engineers you've voted thumbs-up on (i.e. "hire!"), are engineers you'd personally hire to work with you in your first startup company? Let's say this is a hypothetical company you're going to found someday when you have just a little more financial freedom and a great idea.

I posit that most of you, willing to admit it or not, have a lower bar for your current company than you would for your own personal startup company.

The people you'd want to be in your startup are not of the Smart and Gets Things Done variety.

For your startup (or, applying the recursion, for your new project at your current company), you don't want someone who's "smart". You're not looking for "eager to learn", "picks things up quickly", "proven track record of ramping up fast".

No! Screw that. You want someone who's superhumanly godlike. Someone who can teach you a bunch of stuff. Someone you admire and wish you could emulate, not someone who you think will admire and emulate you.

You want someone who, when you give them a project to research, will come in on Monday and say: "I'm Done, and by the way I improved the existing infrastructure while I was at it."

Someone who always seems to be finishing stuff so fast it makes your head spin. That's what my Done clause means. It means they're frigging done all the time.

I met my first Done, and Gets Things Smart engineers back at Geoworks. This was looong before I had any sort of a clue that I suck as an engineer, but these folks (Andrew Wilson and Chris Thomas, if you really must know) were weird. They never seemed to be working that hard, but they were not only 10x as productive as their peers, they also managed technical feats that were quite frankly too scary for anyone else. They could (as just one trait) dive in and learn new languages and make fixes to tools that the rest of us assumed were, I dunno, stuff you'd normally pay a vendor to fix. They dove into the hairiest depths of every code base they encountered and didn't just add features and make fixes; they waved some sort of magic wand and improved the system while they were in there: they would Get Things Smart. Make the systems smarter, that is. Sort of like getting your act together, but they'd do it for your code.

I've met many more such engineers along the way. They're out there. They're better than you. They were better twenty years ago than I am today or ever will be. Maybe it's natural ability. Maybe it's luck in education or upbringing. Maybe they have a secret recipe for improving rapidly and learning utter fearlessness. I don't know. But I've met 'em, and they aren't "smart". They're abso-flutely fugging brilliant.

You can't interview these people. For starters, they're not interested; these are the people that companies hold on to as long as humanly or companyly possible. The kinds of people that companies file lawsuits over when they're recruited away.

You can only find Done, and Gets Things Smart people in two ways, and one of them I still don't understand very well.

The first way is to get real lucky and have one as a coworker or classmate. You work with them for a few years and come to realize they're just cut from a finer cloth than you and your other unwashed cohorts. You may be friends with some of them, which helps with the recruiting a little, but not necessarily. The important thing is that you recognize them, even if you don't know what makes them tick.

This is the one great hope we programmers have for fighting the Dunning-Kruger Effect, the one hope we have for getting something better than the average "just like me" Solid Plugger Joe Nobody you pick up with the Smart, and Gets Things Done approach. Our only "out" is that working side-by-side with someone will show us clearly when they vastly outclass us.

Your devious little mind will come up with all sorts of rationalizations for why they're so damn good, so you can continue to think of yourself as Smart, and Gets Things Done material. You may conclude that they're just a genetic anomaly, and it's no fair even trying to compare yourself to someone who obviously has an unfair gift from the heavens. Or you may tell yourself that they're just a domain expert in various domains that you don't "need" right now. Or you may simply choose not to think about it too much. Good Old Compartmentalization to the rescue!

But working with them directly will show you when they're better. It's the only way. You'll gradually realize that your math deficiencies aren't just something that you might need to beef up on if you ever "need to"; you'll see that virtually every problem space has a mathematical modeling component that you were blissfully unaware of until Done, and Gets Things Smart gal points it out to you and says, "There's an infinitely smarter approach, which by the way I implemented over the weekend." You stare slack-jawed for a little while, and then she says: "Here's a ball. Why don't you go bounce it?"

These people aren't just pure gold; they're golden-egg-laying geese. They are the ones you want to bring with you to your own startup. Not the Smart, and Gets Things Done, Just As Soon As I Read Up On The Subject, On The Company's Dime riff-raff like you and me. No. They're your seed engineers: the ones who will make or break your company with both their initial technical output and the engineering-culture decisions they put into place — decisions that will largely determine how the company works for the next twenty years.

I've been debating whether to say this, since it'll smack vaguely of obsequiousness, but I've realized that one of the Google seed engineers (exactly one) is almost singlehandedly responsible for the amazing quality of Google's engineering culture. And I mean both in the sense of having established it, and also in the sense of keeping the wheel spinning. I won't name the person, and for the record he almost certainly loathes me, for reasons that are my own damn fault. But I'd hire him in a heartbeat: more evidence, I think, that the Done, and Gets Things Smart folks aren't necessarily your friends. They're just people you're lucky enough to have worked with.

At first it's entirely non-obvious who's responsible for Google's culture of engineering discipline: the design docs, audited code reviews, early design reviews, readability reviews, resisting introduction of new languages, unit testing and code coverage, profiling and performance testing, etc. You know. The whole gamut of processes and tools that quality engineering organizations use to ensure that code is open, readable, documented, and generally non-shoddy work.

But if you keep an eye on the emails that go out to Google's engineering staff, over time a pattern emerges: there's one superheroic dude who's keeping us all in line.

How do you interview for such a person? You can't! Everyone will tell you they're God's Gift to engineering quality. Everyone knows how to give it impressive lip service. Heck, there are lots of people who take it way too far and try to gridlock the organization in their over-enthusiasm, when what you really want is a balanced and pragmatic approach. I'd argue that it's virtually impossible to detect these "soft skills" in a classic interview setting, except to the extent that you're hiring your own clone, which according to our thesis here, is NOT what you want. You want Done, and Gets Things Smart: done faster than you, and made your system smarter!

I'm guessing that Google's founders worked with this person in school, enough to recognize his valuable talents. Hence they used Identification Approach #1: get lucky in who you work with.

Incidentally, they hired plenty of other brilliant seed engineers who were equally responsible for Google's great technical infrastructure. I'm just using this one guy as an illustrative example. But you really want the Done, and Gets Things Smart people on every team. If you could mix in one Done, and Gets Things Smart person with every five to ten Smart, and Gets Things Done people, then you'd be in good shape, since the latter, being "smart", can hopefully learn a lot from the former.

But when you're starting a company, or an organization, or a big project, the need for Done, and Gets Things Smart seed engineers is desperate. It's dire, in the sense that if you don't get the right seed people in place, you're dooming your organization to mediocrity, if you manage to succeed at all.

And it's direst when you're in a startup, because you can't pillage people from elsewhere in your organization who you know are good. And because Done, and Gets Things Smart people are worth their weight in refined plutonium, they're probably reasonably happy in their current position.

So let's assume you're looking at the vast ocean of programmers, all of whom are self-professed superstars who've gotten lots of "stuff" done, and you want to identify not the superstars, but the super-heroes.

How do you do it? Well, Brian Dougherty of Geoworks did it somehow. Jeff Bezos did it somehow. Larry and Sergey did it somehow. I'm willing to bet good money that every successful tech company out there had some freakishly good seed engineers. But a lot of company heads who make these decisions aren't necessarily industry programmers, and they still manage to find some world-class people in all the noise. So there must be a second way to identify Done, and Gets Things Smart.

I think Identification Approach #2, and this is the one I don't understand very well, is that you "ask around". You know. You manually perform the graph build-and-traversal done by the Facebook "Smartest Friend" plug-in, where you ask everyone to name the best engineer they know, and continue doing that until it converges.

I think this might work, assuming you have lots of connections initially (lots of roots for your graph), so you don't get stuck in some slummy local minimum.

I've seen companies go to university professors and ask them who their brightest students are; that's a variant of this approach, although it usually only turns up futureDone, and Gets Things Smart engineers. Every once in a very rare while you'll get a recent college grad in this category, but I think more often they tend to be experienced enough to make Gandalf feel young again.

Because technical brilliance, seemingly superhuman productivity, and near-militaristic adherence to software discipline aren't enough. They also need leadership skills. They don't have to be great leaders; in fact in a pinch, just being bossy might work for a while, as long as they're bossing people in the right directions. But they need to have the ability to guide the organization (or new team, or whatever) in uniformly excellent directions, which requires some leadership, even if it's bad or amateurish leadership.

As much as I suspect Approach #2 may work, I think Approach #1 is probably more reliable. Take a closer look at your coworkers who are doing things that you "could learn if you ever need it". Read up on the old Dunning-Kruger Effect. I recommend it with irony dialed at 11, since personally I have yet to read more than the Wikipedia article and a few other articles here and there. I'll read it if I "need to". Psh.

Done, and Gets Things Smart

Not superstars: superheroes! People who are freakishly good at what they do. People who finish things so fast that they seem to have paranormal assistance. People who can take in any new system or design for all intents instantaneously, with no "ramp-up", and who can immediately bring insights to bear that are quite simply beyond your rustic abilities.

Those are the folks you want. I'm not going to tell you: "Don't settle for less." Far from it. You still want to hire the Smart, and Gets Things Done folks. But those folks have a long way to grow, and they probably have absolutely no idea just how far it is. So you want some Done, and Gets Things Smart people to guide them.

IMHO, the biggest enemy of geeks is not incompetence, it's arrogance. Not garden variety "I'm smarter than others" arrogance, but "I'm smarter than mostly everyone else, and I don't need to hear what you have to say, because I'm right, and you have nothing of value to say on this subject." It sabotages effective communication and learning by osmosis from coworkers. And it probably convicted Hans Rosling of Murder. :) It's amazing how many people take their anecdotal industry or academic experience and assert it as some kind of formal proof of correctness of their positions.

Probably the best advice one can receive before writing any essay or taking any position pronouncing anything :) This generates politeness, and in open source communities, I've tended to notice that those with a sense of decorum tend to Get Stuff Done and have greatest success, without requiring a singular uber coder who does everything.

How do I become DGTS? I expect much of your past advice applies, such as learning more languages (programming or otherwise) or creating my own languages. Still, I'd love to see a complete Yegge treatment of the subject "how to be Done and Gets Things Smart."

Also, what (if anything) can organizations do to develop DGTS-ism in the people they already have? They can't all be born that way (and if they are, let's research their genes, astrology or whatever), so they must develop somehow. What kind of dirt and fertilizer grows DGTS plants?

Alex: good question! The answer is, I think, "not really." The Dunning-Kruger Effect has a fourth principle that I didn't mention, which is that as your competence increases, your self-evaluation diminishes. The most competent people apparently tend to rate themselves below their skill level.

I think Paul Graham is probably a DGTSer; I mean, looking at his code in "ANSI Common Lisp" and "On Lisp", it's pretty clear that he's on a different plane of existence from me, and I've learned a ton from him. So he probably has more useful things to say about it than I do.

Cameron: Dude, how am I supposed to know? I'm in the same boat. If you find out, let me know. As far as "miserable" goes, I stay happy these days by writing code that makes me happy, even if I know it sucks on many levels. You can't please everyone, not even with coding.

Michael: the ones I've known have all worked together pretty well. That doesn't seem to happen too often, since organizations tend to spread them around to do damage control on code written by us SGTDers.

Occasionally a few will collaborate at Google, and they invent mind-blowing stuff in a matter of weeks. It's almost scary to watch.

Thanks Steve! For the laughs, but more importantly for the inspiration and motivation you've just given me.

Of course, like everyone else, I want to be a DGTS-er. I probably won't ever get there, but I figure if it's possible, then the only way is probably a combination of

1) being 'done' more often (and the only way there is to 'do' more efficiently) and

2) starting 'getting things smart' (which for me means learning and using my imagination, which means asking questions and starting from the assumption that I'm probably wrong, or at least not seeing the whole picture).

I'm suddenly filled with energy and the feeling that time is slipping away - thanks again!

Well it seems to me the smart thing to do would be to leverage the vast infrastructure we already have for selecting the smartest/most productive people in the academic world, particularly in the sciences. There over long periods of time the people who are consistantly the brightest/most productive bubble to the top. These people then evaluate the next generation.

So why not simply try to hire from graduate programs who come with good recommendations from people in their fields who are highly regarded (either by asking around or citation count)?

Of course this won't get you people for your start up who already know what they are doing but it will get you smart productive people if you can convince them to leave their field. Alternatively you could just try to use things like IQ tests as a proxy. Not perfect but perhaps better than interviews since they won't be as affected by charm.

"How do you do it? Well, Brian Dougherty of Geoworks did it somehow. Jeff Bezos did it somehow. Larry and Sergey did it somehow."

There is another possible (depressing) explanation for explaining how some tech companies identified super-heroes: blind luck. If you're right and it makes such a difference, then just stumbling on some super-heroes would give a company a huge advantage and help propel it to fame and success. In the mean-time, lots of other companies failed due to lack of super-heroes and you never heard of them.

@Steve:thx for the laughs, thx for the insights.I know for a fact that I might have missed good people back when I was interviewing people for my team. And that when I really have tried hard to hire people who think differently than I so I'd have a chance to learn from them. As for identifying DGTSers - I guess luck is the only way. Why would a networked "I know a great tech" won't fall into the "I can't recognise talent that is not similar to mine"? Is it cuz many different people with different talents would eventually point to the same guy?

@David Broderick:How can you tell the difference between an ego an a confidence? I've been using fizz-buzz variations on interviews to force people defend their ego. I'll gladly learn more on that

If you asked a DGTSer to name a person x such that x was (somebody they knew) and (somebody they would want to start a startup with), what would they say? Probabilistically speaking, their population would have a higher response rate of "nobody, i'll go it alone" than the average population, no?...Profit!

I think you sort of implied it somewhere but a huge thing that these guys accomplish is to inspire us lower lifeforms. I have only once worked with a DGTS (for 18 months) and I am still drawing on his lessons 7 years later.

Hi Steve.(add compliments for your rants here)I tend to agree with your post, but I'd like to point out a handful of things.1. what if you don't have those super heroes handy?2. what if you don't have the budget to afford them in the first place?3. not everyone is a super hero, and a passionate, timely, eager to learn, humble, disciplinate worker can contribute to the company success as much...4. ...particularly because many supermen (o women) in the same place may cause a Clash Of The Titans, while having some "average" people alongside may help spread their aura of magnificence5. being bossy (as opposed to "good leaders") can cause severe harm... see "The Asshole Method"

manrico: the DGTSers I've known are almost uniformly soft-spoken, zero-ego people who focus just as much on social harmony as they do on technical excellence. Any time you have a major clash, at least one of the individuals is a jerk. A DGTSer will either be articulate enough and persuasive enough to win everyone over, or will be generous enough to let the lesser engineer try their idea and fail, and then forgiving enough to help them clean up.

I know: it sounds like nobody could be so saintly, but I've known, oh, maybe ten or fifteen DGTSers exactly like that. They exist!

The bossiness thing is a fine line. At Google they're pretty bossy about adhering to the engineering guidelines. Well, not so much bossy as nagging. But sometimes that's just what you need, when faced with schedule pressure to hack things.

Obviously, given a choice I prefer DGTSers to SGTDers, and I prefer leadership to bossiness and nagging.

Possibly the greatest post I've ever read on this subject, and thank you for crystallizing ideas and thoughts I've never quite been able to pull together.

My experience in this problem area is a little different, as I am a manager of software developers who is not, himself, a software developer. I just really like hanging out with software developers.

And I suspect that this is in some fashion helpful as far as finding (or at least recognizing) DGTSers. Because I don't rank myself on the sort of "smart" scale that a developer does, I'm beginning to suspect that it's easier for me to recognize when a given software developer is far above the median. I mean, they're ALL smarter than me, so I don't get caught up in the trouble of trying to recognize someone who exceeds my limitations.

But I absolutely agree on the "working interview" lasting a few months. I never found any method more effective at truly identifying a candidate's quality.

A I remember from the Joel articles, the summer internship is one of the main recruiting tools he has. Gets people who are at least SGTD in for a summer, and then you can work out during those three months who the DGTS people are, and hang on to them as much as you can.

Doesn't solve the seeding problem, but Joel had worked at a few other places first, so probably worked with a few DGTS folk who could have their arms twisted to work with him.

In terms of finding DGSTers, it might be helpful to think about what motivates them and what kind of a place they enjoy working in. I'd guess that there is something about the excitement and challenge of a startup (allong with a compelling leader) that is very attractive to DGSTers. But that may taper off as the company gets larger and loses some of those startup qualities.

That may be one of the secrets of Google: that they've been able to maintain some of that culture as they've grown and can still attract DGSTers.

One thing I'm pretty sure, it's not simply about money. If that were the case, they'd all work at hedge funds (where I work, and I can assure you that DGSTers are underrepresented in "high finance").

So, if I actually have a self-esteem problem, and I don't overestimate myself; And, I have recognized 3 or 4 truly great programmers and about 10 others who are Unusually Good; Then, I myself must be really wonderful! The syllogism is unbeatable. And, thank Goodness, it applies to me!

If this whole super-elitist trend continues, fully half the graduates in CS/SE will be sidetracked into monkey-testing or selling shoes; The entire industry will get a bad rep and nobody will want to work in computers. The real challenge is to get good software out of the teams we can really hire.

In some orgs, if you hire people better than yourself, you're out of a job.

To hire people better than yourself, give them code to write that you found hard; Something the size of binary search or reverse-the-words in a string. Binary search has been overdone, and reverse the words in a string is too easy for most jobs. But something that can fit in a page of code.

Go over your bug list and extract some buggy code. Write an example and test it, make sure it has the bug. See who spots the bug and who doesn't. Caveat: this turns out to be partially a test of programming language/culture. So it ain't perfect.

I do remember hiring C coders a few years back. As a screener, I took the code for strcpy() from the K&R, changed the variable names, and asked them what the 3-line function did. 90% had no idea.

Joel Spolsky's blog relentlessly flatters his customers and his employees. The whole recruitment process, starting with the blog, holds up employment with Joel as precious prize, like the Nobel.

Since Joel's customers are also software techs, this works as marketing. Imagine your customer/prospect base coming to your site regularly just to read your ads. Brilliant! Most people don't even know it's marketing.

I've known a few and "cut from better cloth" is quite apt. As far as I can tell a few of the common traits are a large working memory, a fascination with detail and a playfulness when learning (although the latter is probably not causal). You're right though - most of the stuff comes in left of field.

Jesus Christ man. You are a great writer, and your extremely absurdly long posts make sense when you are summarizing a talk or there is a lot of technical substance, but this one was repeatedly redundant. Do it like the interviews: get in, get the substance, get out.

All a software company needs to do to be successful is hire a superhero coder.

All a basketball team needs to do to be successful is sign Michael Jordan.

Seems so simple.

Basing your entire hiring process on recruiting superstars is a policy doomed to failure. When it is so hard to find people who are merely competent, telling us to hire superstars is like telling a dog to fly.

If Google were that productive, it would have revolutionized the computer industry 10 times over with its army of developers. As it turns out, the one thing that truly revolutionized the industry was Google search, which I'm assuming was developed prior to even having a hiring policy or even a company.

I can sort of relate to this. I used to be freakishly smart as a kid until my head hit a windshield at 30mph which sort of screwed up the error correction on my call stack. Under exactly the right circumstances and with a lot of effort I can still get back into DGTS mode sometimes though.

I can tell you it's an absolutely completely friggin different world than the one most coders live in.

For me the only way I can describe the few weeks in DGTS-mode I had as being able to construct hundreds of unit-tests in your mind and then cycling through them at the rate of about one or two tests per second and for each test that fails observe where it fails, make a quick fix (usually 5-10 seconds, hardly ever more than a minute) and then continue cycling through the unit-tests starting with the ones most likely to have been affected by your fix and only writing down (mental) code that hasn't changed for a while.

The last time I got into DGTS mode for more than three days was when I was 18 and even though I had virtually no knowledge of proper programming practices (3NF being the closest thing to wisdom I knew) I still managed to crank out a pretty darn good Customer Support System in Perl/MySQL in 2 weeks.

I'm pretty sure these people can do similar things for stuff like every single line of source code in the Java libraries and mentally constructing several different architectures for a single problem in great detail and then cherry-picking the good parts of each architecture and merging them into a coherent whole in a couple of minutes ...

The funny thing is that trying to recreate those moments has eventually led me to Lisp because things like for example macros map almost directly to the mental tricks I used to keep the whole program in my mind; except for the fact that my universal data structure was more like a hybrid between (semantic) triples and n-tuples with n <= 5, than cons-cells. (I think that's because the mind can easily store and process a virtually infinite amount of quints; but that's a whole 'nother story ;)

Steve, thanks for brnging this up. This is something I've been thinking about for a long time. The existance of superhumans is one of the best and most prevalent lessons you learn from competitive sports. I still remember when I had the good fortune to go to the State Open during high school wrestling. I was good, heck pretty much everyone there was, but there was one kid I remember (140lb from Milford I think) that nobody could touch. Strength, speed, technique and even luck; he was unstoppable - luckily I was 160lbs so I didn't have to find out first hand.

Thats how I first found out that I'm not superman. Those people...they're special. Incidentally, that's why I have no concern whatsoever that my (and yours I see) boy Obama will loose in November. He, is a bonafide poltical superhuman. Honestly, just watch him walk through a crowd, he shares the style of Derek Jeter, Kobe Bryant, the kid from Milford and - I suspect - your Google superstar. For someone like that, at the top of their game, loosing is practically inconcievable.

As an annotation, that is not to say that the superhumans ALWAYS win. For all their Superness they still inherit from Human and therefore are just as messed up in the head (unless that's their particular domain of superness) as the rest of us. We had a kid on our wrestling team who was super too, I believe he won New Englands his sophmore year; it wasn't even close, he steam rolled, then he got a girlfriend, got busy, got depresed, got fat and lazy and alcoholic and stopped caring. He was still far and away the best pound for pound guy on his worst day on the team but he was simply not interested in preforming to his ability. Keeping up the intensity is a super trait in itself.

Sorry Steve but Google recruiting is weak. I applied to two of the biggest companies in the US for a internship and decided not to go for google as i disliked the recruiting so much. I had chosen the companies according to my profile and where i felt like I would learn the most and potentate myself.

You guys should be more human. We are not numbers. You should never get our names wrong (I'm not Nino, thank you). And I really think that if google wants the best they should - at the very least - treat people in a personalized way. And no, I don't mean like sending chocolates, but knowing of previous emails sent to me or being interviewed by someone who is actually listening is a nice start. Getting my name right gives extra points. And no. It's not acceptable to say "you can't do your internship in mountain view as you are european". It makes no sense.

You can't go and think. Yeah, where google we don't need you. You need us. That's a lie. Of course google needs good developers, and good interns. And doing things like this you won't get any intelligent person that has a minimum of self-respect. Simply because integrity is not for sale, at any price.

"How do you do it? Well, Brian Dougherty of Geoworks did it somehow. Jeff Bezos did it somehow. Larry and Sergey did it somehow. I'm willing to bet good money that every successful tech company out there had some freakishly good seed engineers. But a lot of company heads who make these decisions aren't necessarily industry programmers, and they still manage to find some world-class people in all the noise. So there must be a second way to identify Done, and Gets Things Smart."

Isn't this just a self-fulfilling prophesy? We hear about and remember the Googles and Amazons of the world because they happened to have great seed engineers. We forget the Schmoogles and Schamazons, though they may well have equally capable founders, because they didn't get as lucky with their first few employees.

Wait. What if I somebody is a DGTSer? Does he know? Is he full of doubts all of his life? I say it'd be better to be ignorant and happy than doubtful and miserable!

No, but seriously, I don't know any DGTSer personally (that tells you how dumb I must be, or I've just been hanging out at the wrong places), so for those of you who do, what do they think of their own DGTSness?

Effortful study is the key to getting good at anything and is basically defined by continually attempting tasks that are just outside your current capabilities.

It takes 10 years to get really good at anything, from chess to soccer, and motivation is far more important than any kind of innate ability. You alluded to this in your comment that the insanely good engineers are typically older, experienced people. If you were to sit down with these engineers you'd find that they have been continually pushing their own boundaries for decades.

If you want to read more about this the Scientific American article titled "The Expert Mind" is a fascinating read, http://www.sciam.com/article.cfm?id=the-expert-mind. Steven Levitt, of Freakonomics fame, has come to pretty much the same conclusion that experts are made not born.

A full list of DGTS traits would be nice. It would really help in evaluating whether I am one or not. I do seem to pick up on things really quickly ("You looked at that PDF library for 5 minutes and you know more than I do after struggling with making it work until 10:00 PM last night!?")--in all sorts of situations, to the point where it strains my patience to deal with people in general, because I feel like I'm spending so much time waiting for them to catch up.

I kindof think that if you are worrying whether you are one, or how to become one then you are not, almost by definition.

Because people like that don't worry about what they are, they worry about the problem they are trying to solve. They care about it overwhelmingly, to the exclusion of everything else, even the question of "how good am I?" That is why they come usually across as so absurdly modest, even while they are blowing everyone else away.

So if you're principally worrying about "being good" then you probably won't ever be as good as the best, by the very nature of what you are trying to do.

"How do you do it? Well, Brian Dougherty of Geoworks did it somehow. Jeff Bezos did it somehow. Larry and Sergey did it somehow."

DGTSers may well be able to recognize and draw others of the same ilk. I'm thinking that some of the most successful founders are DGTSers, too. Larry and Sergey both have a reputation for being seriously great engineers themselves and I'd think that in itself would attract the best and brightest.

I think I met a DGTS at IBM in the mid-1990s. He vastly improved most of the development environnement while he was there then just left to work on xemacs. It's Martin Buchholz (this guy: http://xemacs.digimirror.nl/People/martin.buchholz/). Don't know where he is now.

Dunning-Kruger doesn't even say it is impossible to detect smart (or "not smart"). It simply says we'll be off. Given a sufficient magnitude of smart (or "not smart"), we will still reliably detect that. At least if we're not so filled with hubris that we don't want to.

I think Spolsky's original tells everything and this reformulation doesn't add an awful lot for me.

Unstructured interviews have an r-squared of about 5% with job performance, so they are useless.

There is actually some good research out there about this. "Executive Intelligence" by Justin Menkes would be a good introduction to the topic; much better than making it up based on personal observations. Here are three things that are known to work. Each adds maybe 25-30% to the r-square.

1. Behavioral event interviews. Take a class of problems and ask the candidate for an example from their past. Get them to take you through what they did situation->actions->result. Repeat several times for several different problems.

2. IQ tests. For any job with significant cognitive difficulty, IQ is a powerful predictor (35% R^2) of performance. In the US you can't give IQ tests but you can ask for academic transcripts which are a semi-reasonable proxy.

3. Try to test actual job performance. Assk yourself this: would you hire someone as a juggler without seeing them juggle? Actors and musicians have auditions. Google gets people to write code on the whiteboard. Give people a problem and ask for a first cut of the design or get them to code a key component. An internship or trial period can be as useful but you need to work out how you are going to measure performance.

By the way writing code on a whiteboard is different than keying it in, so practice this if you are interviewing at google!

This is an excellent post. There are two additions I would make to this. Firstly, do what you can to make your organisation and team be the sort of place that attracts the sort of exceptional people you want to hire. And make the role the kind of role that a really great person would want to do. It sounds obvious, but incredible people don't want to do awful jobs working for bad employers. I for example would rather club myself to death than work for Joel Spolsky making his stupid bug tracker.

Secondly, remember that DGTS is an ethos that can be learned and also can be crushed. If I have to get 15 types of authorisation and a bunch of code review for every thing I want to change it represents a major barrier to getting things smart. Even if I would normally pile in and improve things instead I probably will just make the smallest possible change (probably making the world a little bit worse in the processs). So you want to make the barrier to improving smartness low where possible.

"So if you're principally worrying about "being good" then you probably won't ever be as good as the best, by the very nature of what you are trying to do."

I have to disagree. If you're never trying to evaluate something, you never find out if you're improving. For example, simplicity in software is good, but if you never ask "Is there a simpler way to do this?" you end up with viciously complex code by default.

Even so, there's a time for everything. If you're all-consumed by the question of how good you are and don't leave any room for actually doing anything, then that *would* guarantee that you would never be the best.

How I Learned to Let My Workers Lead, by Ralph Stayer, (online: http://www.wku.edu/~hrtm/CFS-452/Readings/stayer.htm) and in book form (http://www.amazon.com/Learned-Workers-Lead-OnPoint-Enhanced/dp/B00005UMLM).

Ricardo Semler (http://www.amazon.com/s/ref=nb_ss_b/103-8201982-9019059?url=search-alias%3Dstripbooks&field-keywords=ricardo+semler&x=0&y=0). His books: "Maverick!", "The Seven-Day Weekend: Changing the Way Work Works", "Managing Without Managers"

"The Fabric of Creativity: At W.L. Gore, innovation is more than skin deep: The culture is as imaginative as the products.", by Alan Deutschman, Fast Company, Issue 89, December 2004. (http://www.fastcompany.com/magazine/89/open_gore_Printer_Friendly.html)

Referenced in "What is Pay. Really? This." At my own little unread blog.(http://snorpulence.blogspot.com/2008/01/what-is-pay-really-this.html)

I don't know. Even then the empirical evidence for success of a hire is tough to gauge. How do you calibrate for the next hire? To me, the original assertion from Joel was to follow "some guidelines". I would bet that if you compared Steve's ideas for hiring against Joel's you wouldn't get far because they are producing different products in different industries. Hence, Joel knows his business.

"So looking for Smart is a bit problematic, since we aren't smart enough to distinguish it from B.S. The best we can do is find people who we think are smart because they're a bit like us."

Being literate, I prefer long blogs. Occasionally, however, there are hostages to be taken.

B.S. is quite clearly obvious. No "Done," and no "Gets things smart." Lose the first sort (given BS) and, well, lost the second sort (given BS.) "Gets things smart" is a really bad predictor on an interview. Or, indeed, a 360-degree performace review. Or whatever.

I've worked for people who are astonishingly smart (Dave Thomas people (and btw this would look less emphatic if your blod had a practical url tag, which I assume is a low priority, and I could add anything in here apart from a plain-text version of, say, "http://www.pragprog.com/"), for example, and you need to improve your mark-up, because I'm just trying to make the point that Dave Thomas is astonishingly smart. Ill leave the arsehole comment til later.)

I have no interest whatsoever in people who are "a little bit like us."

I went through university being annoyed by these idiots, and I have no desire to work with or over them now.

Good God. It's difficult enough to deal with total freaks, and to work out whether I'd go along with them or not.

One method that worked for me was to take a real work example and ask people in the final round to spend a few hours of their own time working on it. I found that the best people did something elegant in a ralatively short time and came up with some good ideas that we hadn't thought of.

The other thing I noticed is that really good people are continually improving themselves by reading a lot in their field. Just ask them to discuss what they've been reading lately.

People who are good in problem solving and getting things done are having different thinking capability compared to others. Those people HAVE common sense approach to problem identification and rectification.

I was able to solve the problems (my expertise: Win32, VC++, MFC) quicker than my seniors and domain/technology specialists in our company (who analyze for months for the same problem) but I don't how it works for me. When I was in GE Health care, we had great people from top institution in India even they struggle for finding solutions for simple problem when other smart guys from unpopular institution fix the problem in minutes.

Thank you to sapphirecat for showing me I was being unclear. I said "So if you're principally worrying about "being good" then you probably won't ever be as good as the best, by the very nature of what you are trying to do," and he (she?) objected "If you're never trying to evaluate something, you never find out if you're improving."

Of course. I may have sacrificed clarity for brevity, so at the risk of being long-winded, I'll try to say this more carefully.

The key here is "principally," and that I am describing motivation, not self-evaluation. The question is, what's driving you? What gets you working? If its just trying to show that you're good, then you won't be. It has to be something else too, or it won't get you through the concentrated decade of training it takes to get to that level.

Look at the history of the person we're all presuming Steve Yegge is talking about. He graduated (with honors) in 1990 and started at Google in 1999. So he worked a long time before he got to the level of Google's star.

When I was at Google I hung out on Sunday afternoons with a similar superstar. Nobody else was reliably there on Sunday; but he always was, so I could count on having someone to talk to. On some Sundays he came to work even when he had unquestionably legitimate reasons for not feeling well, but he still came to work. Why didn't he go home like any normal person would? It wasn't that he was trying to prove himself; he'd done that long ago. What was driving him?

The only way I can describe it is one word: fury. What was he doing every Sunday? He was reviewing various APIs that were being proposed as standards by more junior programmers, and he was always finding things wrong with them. What he would talk about, or rather, rage about, on these Sunday afternoons was always about some idiocy or another that someone was trying make standard, and what was wrong with it, how it had to be fixed up, etc, etc. He was always in a high dudgeon over it all.

What made him come to work when he was feeling sick and dizzy and nobody, not even Larry and Sergey with their legendary impatience, not even them, I mean nobody would have thought less of him if he had just gone home & gone to sleep? He seemed to be driven, not by ambition, but by fear that if he stopped paying attention, something idiotically wrong (in his eyes) might get past him, and become the standard, and that was just unbearable, the thought made him so incoherently angry at the sheer wrongness of it, that he had to stay awake and prevent it from happening no matter how legitimately bad he was feeling at the time.

It made me think of Paul Graham's comment: "What do I mean by good people? One of the best tricks I learned during our startup was a rule for deciding who to hire. Could you describe the person as an animal?... I mean someone who takes their work a little too seriously; someone who does what they do so well that they pass right through professional and cross over into obsessive.

What it means specifically depends on the job: a salesperson who just won't take no for an answer; a hacker who will stay up till 4:00 AM rather than go to bed leaving code with a bug in it; a PR person who will cold-call New York Times reporters on their cell phones; a graphic designer who feels physical pain when something is two millimeters out of place."

I think a corollary of this characterization is that if you really want to be "an animal," what you have cultivate in yourself is partly ambition, but it is partly also self-knowledge. As Paul Graham says, there are different kinds of animals. The obsessive graphic designer might be unconcerned about an API that is less than it could be, while the programming superstar might pass by, or create, a terrible graphic design without the slightest twinge of misgiving.

Therefore, key question is: are you working on the thing you care about most? If its wrong, is it unbearable to you? Nothing but deep seated fury will propel you to the level of a superstar. Getting there hurts too much; mere desire to be good is not enough. If its not in you, its not in you. You have to be propelled by elemental wrath. Nothing less will do.

Or it might be in you, but just not in this domain. You have to find what you care about, and not just what you care about, but what you care about violently: you can't fake it.

(Also, if you do have it in you, you still have to choose your boss carefully. No matter how good you are, it may not be trivial to find someone you can work for. There's more to say here; but I'll have to leave it for another comment.)

Another clarification of my assertion "if you're wondering if you're good, then you're not" should perhaps be said "if you need reassurance from someone else that you're good, then you're not." One characteristic of these "animals" is that they are such obsessive perfectionists that their own internal standards so far outstrip anything that anyone else could hold them to, that no ordinary person (i.e. ordinary boss) can evaluate them. As Steve Yegge said, they don't go for interviews. They do evaluate each other -- at Google the superstars all reviewed each other's code, reportedly brutally -- but I don't think they cared about the judgments of anyone who wasn't in their circle or at their level.

I agree with Steve Yegge's assertion that there are an enormously important (small) group of people who are just on another level, and ordinary smart hardworking people just aren't the same. Here's another way to explain why there should be a quantum jump -- perhaps I've been using this discussion to build up this idea: its the difference between people who are still trying to do well on a test administered by someone else, and the people who have found in themselves the ability to grade their own test, more carefully, with more obsessive perfectionism, than anyone else could possibly impose on them.

School, for all it teaches, may have one bad lasting effect on people: it gives them the idea that good people get A's on tests, and better ones get A+'s on tests, and the very best get A++'s. Then you get the idea that you go out into the real world, and your boss is kind of super-professor, who takes over the grading of the test. Joel Spolsky is accepting that role, being boss as super-professor, grading his employees tests for them, telling them whether they are good.

But the problem is that in the real world, the very most valuable, most effective people aren't the ones who are trying to get A+++'s on the test you give them. The very best people are the ones who can make up their own test with harder problems on it than you could ever think of, and you'd have to have studied for the same ten years they have to be able even to know how to grade their answers.

That's a problem, incidentally, with the idea of a meritocracy. School gives you an idea of a ladder of merit that reaches to the top. But it can't reach all the way to the top, because someone has to measure the rungs. At the top you're not just being judged on how high you are on the ladder. You're also being judged on your ability to "grade your own test"; that is to say, your trustworthiness. People start asking whether you will enforce your own standards even if no one is imposing them on you. They have to! because at the top people get given jobs with the kind of responsibility where no one can possibly correct you if you screw up. I'm giving you an image of someone who is working himself sick, literally, trying grade everyone else's work. In the end there is only so much he can do, and he does want to go home and go to bed sometimes. That means he wants people under him who are not merely good, but can be trusted not to need to be graded. Somebody has to watch the watchers, and in the end, the watchers have to watch themselves.

OK, now as I've feared, I emulated a grand Yegge tradition and went on too long. Actually, my original comment was twice as long; I just cut half of it, but its still long. My apologies to this comment section, and I hope they find this lengthy comment worth reading.

Steve you hit the nail and if i had any doubt Rebecca has cleared it. I think this differentiates from super acheivers from others. I personally know one of DGTS guy, although i didnt worked with him but he gave us some training. Although he had Phd in Statistics from Stanford univ, but he was the best programmer i have ever met.

This has been one of the most bizarre and unnerving posts I have ever read from you, and some of the other blogs that confiscate little bits of my day. Right now in the company I am working for, I am one of the two DGTS guys we have. Or at least, I think I am one. It's funny to have a label that you can use, I always used to just call this category of people Janitors.

One can identify Greater Intelligence (GI) if they work hard to break through self-deception which for various reasons is an evolved trait in humans (e.g. religion).

Interviews need to be very objective (e.g. if he claims he can do X then objectively he must be able to answer Y and so on). As far as whether he/she can get things done - only a 6 month internship/contract can tell you that (actually even that could be deceiving - i.e. he/she may relax to his natural self after confirming his position).

At the risk of sounding arrogant (a very fine line) here is my perspective.

===

I'm a DGTSer. At least I think I am. Others have informed me of this repeatedly over the year using other labels and designations.

When stuff needs to get done, I get it done. Everything I touch I work to improve as I go. I equate mediocrity with stagnation and stagnation with death. Therefore I fight to reverse entropy in all its manifestations.

I am a teacher, a leader and a mentor. I strive to help others become SGTDers and develop to their fullest potential.

I am a perfectionist.

I want others to do better than me; I don't want them to emulate me.

I am non-conformist and strongly disapprove of authority by fiat. I despair that so many people willfully allow themselves to be boxed in by unfair policies or unthinking illusions.

I create. I dream, lucidly. I take things apart and put them back together. I dissect beliefs and precepts. I theorize. I make inferences and explain them to others.

I provide comfort. I cherish friendship, love and understanding. I seek beauty.

I make mistakes. I have confidence I can resolve them. They used to embarrass me but they don't bother me too much anymore. Mistakes are the richest learning experiences. They signal new challenges ahead. Why get stuck?

When I start a project, I assume that I can accomplish it. I don't know all of the details of how but I don't let it stop me from making forward progress in some area.

I've been like this all of my life. I'm not sure how it happened. But I owe a great debt of gratitude to my parents, grandparents, teachers, mentors, peers and friends for helping it along...

===

Someone asked whether DGTSers get along.

I think we do! Really really well.

Being DGTS requires one to relinquish ego and presumption. One must acquire an intense respect for the work of others while maintaining a critical sense of judgment.

There's no need to prove that you're smart to another DGTS or anyone else for that matter. If we let that go and just work together then we can do GREAT things!

And that's what I'm waiting for. I'm fairly happy in my current position but I'm itching to do a startup with another similarly inclined DGTS and all of the SGTDs and talented passionate individuals we can get our hands on.

I don't want to do a startup on my own because I think it's far more rewarding to work with others.

Plus, I know people who can do stuff better than I can, and I know how to get them to do it for me... :-)

Thanks for the explanation. I've been around computers for as long as I can remember (growing up with C64s and Amiga 500s, seriously abusing a Win95 install, and doing the same to RedHat once I got my own computer). It has never been enough for me to get something to work. I have to know *why* it works. Which has made me (as far as I can tell anyway) a pretty good system administrator, but it's only been in the last year that I've started consciously applying the same fanaticism to programming itself. So I'm still trying to figure out how to tell how good I am, and how to reveal dimensions in which improvement is needed.

I think DGTSers have a clearer vision of the end result. They know exactly what is required, and also what is not required. And that enables them to make certain shortcuts.

I think that is what slows me down the most as a software developer is overthinking the design. I found that DGTSers usually go for a simple design or just something that makes sense to them, even if it is not in the book.

Maybe the key to their success is linear thinking. If you want to get from here to there, then the shortest path is a straight line. DTGSers have this ability to see that path, and they feel no guilt taking it.

Hello Steve,Identifying the DGTS Programmers and learning how they got that way was the main point of my recent book, Secrets of the Rock Star Programmers. One common trait I saw was "pride tempered by humility". Another was mastery at navigating "the Orders of Ignorance". This handy classification scheme was coined by Phillip Armour.

The cult of the rock star programmer is a lot of what's wrong with the profession.

"Done" is possible in a certain context: when a smart developer knows what needs to be done and can do it without involving others. In the real world, requirements gathering, meetings, testing and other phases of development are forms of overhead that can't be eliminated.

Communications of the ACM is filled every month with hand-wringing about how there aren't enough students entering computer science programs, not enough women, not enough money from the defense department, blah, blah, blah...

Somehow they miss the point that students aren't stupid. They're seeing that IT people reach their mid 30's and find that they've got few choices in their careers -- it's not that they're slowing down or obsolete, but that there's a "glass ceiling" in most organizations: no promotion paths.

Many of my Gen X friends are going back to school to get MBA degrees. Young people are "smart" enough to understand that it's dumb to spend 15 years in a dead end career, so they go for business, law, medicine or accounting right away.

Sure, there's entrepreneurialism, but that's not a route that's going to work for everyone. For instance, San Francisco's Twitters got there through luck, not through skill or the ability to manage complex technological systems successfully. There's a fine line between being a kick ass consultant and being a beautiful loser like Donald Trump (uh, I mean Paul Graham.)

I wonder if there's a correlation between DGTS'ers and how much they love what they do. I know I am MUCH better at things I love. They don't seem anywhere near as hard to accomplish as things I don't like doing, or that my heart isn't really into.

I am humbled by this column, as I always do when I read your blogs. But again, reading this article, I feel has made me smart :-). I agree and look forward to the extended 6 month format. But it is like a Heisenberg principle...if you know you are measured, your behavior changes, but again, that is nature of any appraisal or any measure...so it might work.

It took 15 years for you to figure out that you are not smart...how dumb you should be to take that long a time, or maybe you are smart but takes time to get thingsdone and prove yourself that you are not smart and thus get the things done :-)

A***h***, u made me cry again...wonderful read...

Some qualities of the Done and Get Things smart that I came up with1. They do not care for their titles or where they came from (Microsoft, Google, Amazon or anything)...They do not fan out their Microsoft work experience or working at google...etc...they make those places...they make MS and Google get that Ego...they do not get their Ego from the companies they work for

2. Corollary to #1...they do not care to compare them with others in general. They just look at how they improve over a period of time...

3. And in general, they do not try to be jargonish...It is like Einstein...I guess..they look for simple words to communicate...not that there is anything wrong with jargons...per se..

I'm looking for work now, and my problem is I find it hard to believe an organization would ever consider hiring anyone but me. How could they? I'm clearly the one special candidate, and they MUST be able to see that I am. Of course, once I don't get the job, I crash into "why would anyone hire me?" mode. There never seems to be any middle ground.

I would postulate a third method to detecting DGTSers, which is to randomly see someone do something, or find out they did something, that only a DGTS could have possibly done.

I will give two examples from my startup. I don't claim this method always worked; there were some false positives. But, it's worth a few false positives if you snag a DGTS.

DGTS #1: I was co-located with someone working on a completely unrelated project. He was teaching a co-worker how to use a complex piece of software on an SGI (an acient Unix workstation for you young-uns). After a few hours of listening surreptitiously to their banter, and watching #1 teach this woman the system (both navigation of the OS and intricacies of the application sofware), something became clear to me. He had never seen this system or this application before in his life. This was at a time when applications were not as user-friendly or self-documenting as today. He had no manual; he was learning both the OS (I believe he had not used Unix before) and the application purely through intuition, trial, and error. He was doing this in real-time, quickly enough to keep pace with his student's ability to absorb the information.

#1 was not a coder, but he did everything else having to do with computers better than anyone I have ever met before or since. From hardware to admin, testing, demos, QA, build/release, customer support, setting up huge (for the time) data centers, debugging client/server problems -- on and on, this person was easily worth 10 other employees. If he had not been my second hire, I doubt our company would have succeeded.

DGTS #2: I was interviewing a typically asperger-ish engineer. It was difficult to engage with him beyond simple question/answer pairs. I like to get people to talk about themselves; I want to get an idea about the person behind the skills. With this prospective employee, that just wasn't going to happen. I browsed through his resume, and noticed a small detail I had missed before: he had once played keyboards for Philip Glass. If you don't know Glass's music, suffice to say playing it (prior to the advent of sequencers -- most of Glass's seminal recordings are played by live musicians) is not something to be undertaken lightly. To be good enough at that one skill to actually be hired by him, implies a level of achievement that is several sigmas to the right of "plays piano".

I ended up hiring him pretty much based on this one fact. I couldn't believe that someone who had achieved that level of expertise at one thing would decide to spend his life programming computers and accept "pretty damn good" as his goal. I realize this might seem to go against the D-K effect; I'll leave that dilemma for someone else to parse. The upshot is that both #1 and #2 were incredible, once-in-a-lifetime hires, who absolutely had a strong effect on our odds of success in a brutally competitive space. I would conjecture that, early on in the company's life (< 30 people), our ratio of DGTS to other programmers (mostly SGTD's with a few nonperformers) was about 20%. That is, in my experience, an extremely hard ratio to achieve, and it becomes exponentially more difficult to maintain as a company scales up.

Do your remember the interview with Stiff? (http://www.stifflog.com/2006/10/16/stiff-asks-great-programmers-answer/) One of his questions was: "What do you think makes some programmers 10 or 100 times more productive than others?"

I think I agree most with the answer of Peter Norvig. A brain with a lot of RAM is invaluable.