Atlas · Details
Done, and Gets Things Smart
Author’s note
The thesis of this one is that you would not use the standard corporate interview process to hire people for your OWN startup. Instead, you would hire the best people you already know.
This essay explores the characteristics of the very best engineers, who are so fast that they always appear to be Done, and as they work, the leave everything better (Smarter) than when they entered it.
This is one of my few essays that has become even more relevant with the advent of AI-assisted programming. I dream of a day when almost everyone on earth is Done, and Gets Things Smart.
AI Notes
Published June 2008 as a direct response to Joel Spolsky's hiring aphorism "Smart, and Gets Things Done." It builds on the Dunning-Kruger Effect, which Steve presents as a "devil's pitchfork" with two prongs: incompetent people overestimate their own competence, and they fail to recognise genuine skill in others. The second prong breaks interviewing — how do you hire someone smarter than you if you can't tell that they are? Classic interviews mostly hire people good at interviewing, or copies of the interviewer. Steve cops to it himself through the Navy Nuclear Power School story (a strong memory let him set record exam scores while understanding nothing, then failing the hands-on radar lab). His fix is the extended interview — Geoworks' six-month internship, Amazon's contractor pattern, Google's pre-slotting period. And the reframed heuristic in the title: you want seed engineers — superheroes rather than superstars — who finish absurdly fast and improve the systems and the engineering culture while they're in there.
The honesty is what carries it: Steve casts himself as the man who couldn't tell, then inverts a proverb everyone had stopped questioning. The Geoworks-Amazon-Google comparison is an early showing of the engineering-culture thesis that underwrites the whole site.
Related listings
-
2008
Get That Job at Google
The other side of the same table, three months earlier. Get That Job is advice for the candidate; Done, and Gets Things Smart is Steve admitting how badly the people on the hiring side can misjudge what they are looking at.
-
2005
Five Essential Phone-Screen Questions
Steve's earlier, concrete interviewing checklist. The phone-screen questions are the practical floor; Done, and Gets Things Smart is the harder, humbler problem above it — how to recognise someone genuinely better than you.
-
2008
Portrait of a N00b
Both essays are about misreading skill. Portrait of a N00b is about telling a beginner from a veteran by their code; Done, and Gets Things Smart is about why the beginner often cannot tell, and hires accordingly.
Where it was argued
- Hacker News Jun 2008
From the peanut gallery
Read the rest of the thread · 92 more
-
First off, I'm calling for a moratorium on Simpsons references until the writers over there are Done, and gets things funny.
Secondly, is it possible to cluster DGTSers? Can they recognize each others' brilliance and form into a sort of hive mind, or do they end up abrading one another with slight differences?
(Thanks for the two recent posts!) -
Thank you for reminding me that I'm not one.
-
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. -
Meant to say "Probably the best advice one can receive before writing any essay or taking any position pronouncing anything...is to consider that you can be, and probably are, somewhat wrong."
-
do *they* know who they are? Are these the same Hackers Paul Graham talks about or are they different?
-
Can your next post focus on how the rest of us morons can make the best of our miserably mediocre careers?
-
FYI, Dunning-Kruger is an IG nobel winner, not "Nobel". Slightly different.
-
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.
jldugger: d'oh. -
Surely you're joking, mr Feynman has a chapter about an education system in Brazil similar to that Navy story.
Pirated here, search for Brewster in the text. -
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. -
"The trouble with the world is that the stupid are always cocksure and the intelligent are always filled with doubt." -Bertrand Russell
Whenever I meet a developer with an ego, I immediately assume I've met a mediocre developer. (Note, ego is not the same as confidence.) -
Semi-related, here's a video with Malcolm Gladwell on how interviews and such can be poor filters:
The Mismatch Problem [video] -
"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 -
I know you were somewhat tongue-in-cheek about your use of bold text, but it really helps when reading long text online. I'd recommend sprinkling in more bold text in the future.
-
john: yeah, I noticed that too, which is part of the reason I kept doing it through the end.
It's weird, eh? I wonder if a random selection of font properties and sizes applied to random bits of text makes it inherently more readable.
Why's Poignant Guide is about the only example of this I can think of, and it seems to work pretty well for him. -
I’m happy to see you’re still using “blog” as “blog post” :)
-
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 magnificence
5. being bossy (as opposed to "good leaders") can cause severe harm... see "The Asshole Method" -
leoboiko: in this context, it's shorthand for "blog movement".
-
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. -
Steve,
You have this preternatural ability to make me feel like a total empty-headed, bovine, can't-code-anything-worthwhile engineer.
:)
Great post! -
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.
And as others say, thanks for reminding me how far I am from DGTS ... -
Regarding bold face text, I think Jeff Atwood's Coding Horror blog is a good example. He uses more bold text than you would in a print, but not too much for online reading.
-
Here's a shorter version, but there are remarkable similarities in the description.
The Free Electron
http://www.randsinrepose.com/archives/2005/03/20/free_electron.html -
Steve, as much as I like all of your writing, the "meta" inside me thinks it's really sad how preoccupied we all are about our precise degree of smartness...
-
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. -
And Steve touched on the issue of flattery.
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 have to say, I really enjoy your rants but they are so damned long. I think I am suffering from the following: http://www.theatlantic.com/doc/200807/google
-
The "inverse D-K effect" you mention sounds a lot like the Imposter Syndrome, which afflicts almost every Assistant Professor I've met.
http://en.wikipedia.org/wiki/Impostor_Syndrome -
Great post. The DK paper itself (linked from the Wikipedia page) is a quick and even entertaining read.
And bonus points for using the word "kneebiter". :)
- Marty -
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.
-
"so you don't get stuck in some slummy local minimum."
Would it not be a local maximum that you would get stuck in?
Thanks for the great read. -
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.
-
"And it probably convicted Hans Rosling of Murder"
I hope you meant Reiser, not Rosling. -
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. -
@David Broderick
"The best lack all conviction, while the worst
Are full of passionate intensity."
- W.B. Yeats
That was from 1919, I can't prove it but I bet the Irishman thought that up before the Brit. -
Please fix your feed :) It's only showing the first paragraph.
-
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.
I my case the result was that I ended up in the other company.
By the way, you said your memory is your strongest point. Well, that's my weakest. I'm a memory absent person :P -
I have to take a guess that the Google "DGTSer" is Jeff? He has status approaching Chuck Norris among the Google eng community.
-
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? -
Blub programmers.... I like it! Err... at least I think I do....
-
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.
Even so, I assume that one trait isn't definitive. -
"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. -
My contribution to Approach #2:
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.
-Akiba -
Is it Jeffrey Dean?
He was one of two people out of many speakers at Google IO who I thought were "smart."
I want to know if I can do the impossible - detect "smart" :-) -
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.
More on my blog:
http://smoothspan.wordpress.com/2008/06/19/smart-is-as-smart-does/
Cheers,
BW -
Okay, engineering talent, sure, but isn't the guy who put Google on the fast track named Omid Kordestani? (Or arguably Bill Gross?)
That comment about 10 years of training is interesting. How many of us take our profession seriously enough to even do any serious, purposeful practice at all? (Where are the programming coaches?) -
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! -
BobWarfield, you are correct ...
Also, smart people don't carelessly throw around words like 'impossible.'
I liked what you had to say in "Smart Is As Smart Does" and agree with some of your statements.
Steve,
I'd love to hear your thoughts on smart vs wise? -
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. -
Some resources.
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)
-- Dave -
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.
-
This comment has been removed by the author.
-
As ye live, so shall ye die:
"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. I
ll 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.
Life is too short. -
Hmm.. how does the DGTSmarter avoids procrastination? As an example, you stop working to code yet-another-elisp-function to do your job sometimes... how does that differs from DGTS?
Cheers -
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.
This is really interesting post, has a lot of insightful thoughts. -
My programming teacher in High School told us a story of this guy who programmed a non-working telephone once.
I don't remember all the details of it but it was pretty interesting.
I think the guy my teacher talked about has to be one of the DGTS type, now that you assign a title to it and all that.
I so wish I was that kind of person. -
@Klasanov : Don't be so hard on yourself. That person is serious hacker and tinker'er. You can be smart, and a success, without resuscitating a broken cell phone with your own OS.
-
This article gave me a lot to think about. I'm depressed and inspired at the same time, so thanks a lot, both sarcastically and really. :)
-
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.
Vinay -
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.
Anyway, this was a blog entry that really blew my mind. Thanks Steve. -
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). -
I have an honest question for you Steve. Do you really write these huge blogs all by yourself. I have been trying to blog stuff but its so hard to find time while developing.
-
The best and brightest engineers I've ever worked with have also been the most modest. "The things I _don't_ know can (and do) fill many college textbooks" is a typical quote.
The opposite also appears anecdotally to be true: the most arrogant engineer I've ever worked with also turned out to produce work of mediocre quality. -
rebecca,
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 bet most of these DGTSers don't blog? LOL
They have their thing, you have yours Steve. It seems to me you are a lifelong student, or researcher, whatever.. One seeking some sort of ultimate knowledge? :)
Anyway, sharing with us your insights is probably your greatest contribution. Don't worry about not being a DGTS. -
Dude, as an experiment, cut out half of your next post. Then do it again. Then do it again. When you're done, you will be enlightened.
-
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.
Thanks for the post.
Ed -
How I spot smart :-)
Needs to automate things, hates repeated manual processes - Not with 100s of java classes but with lines of bash scripts filled with greps, awks and seds.
Comments on existing process - Sees inefficiencies and doesn't like it, tries to change things.
Doesn't like 'black boxes' - always tries to 'pull things apart' to understand them better.
Knows when to stop tinkering. -
Sigh.
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.
Consistently better performance isn't going to happen unless the profession is professionalized.
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 things
done 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 with
1. 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.
-insanitaryharry.blogspot.com -
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. -
That is a monster post. I'm not sure about everything you say, but I found the comment about an exceptional memory being a barrier to understanding a very interesting one.
Wendy Ragiste -
>I'm not sure about everything you
>say, but I found the comment about
>an exceptional memory being a
>barrier to understanding a very
>interesting one.
Are you talking about short-term memory or long-term memory.
I definitely agree that having a larger short-term memory would be of great advantage when coding. -
Steve,
Though i am java developer i am your big time fan especially i love watching your tech videos.
Thanks
Prashant Jalasutram
http://prashantjalasutram.blogspot.com/ -
wow, I feel even more inferior at my new job now :P and you seem to have a bit of a problem with spam comments :P
-
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.
"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.
— Matthew Gertner · 10:14 PM, June 17, 2008
Steve falls into the category "Done, and I already blogged about it"
— Chris · 1:35 PM, June 26, 2008
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.
— Rifkele · 11:51 AM, June 18, 2008
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.
— psamtani · 1:55 PM, June 17, 2008