9 ms·

You Don’t Need Superstar Developers

87 points by ArturT 9y ago

kozak 9y ago
One of my most useful insights in software development is that no matter how smart you are, if you write code that can't be understood by a junior developer, it means that you didn't do a good job writing that code.
- DamonHD 9y ago
  And the reason that "the code is self-documenting" is a bad smell is because in 3 months even the 'rock star' who wrote it won't remember without appropriate help (eg comments). I've worked with some pretty smart developers in some pretty interesting roles, and the people cock-sure of themselves are rarely anything other than a poisonous danger to overall performance and deliverables typically. I say this as a lone wolf by inclination, though also unexpectedly happy on a trading floor with hundreds of people around not entirely managing their emotional interactions!
  - athenot 9y ago
    Besides, code speaks to the compiler/runtime; comments speak to the human. - The machine need to know HOW something should happen. That's code. - The human needs to understand WHY that thing should happen that way. These are two different objectives, and good quality code weaves the two in the appropriate measure. Having said that, I don't believe all code should be reduced to the subset that a junior dev can understand. Keep it simple when possible, yes. But don't limit yourself, otherwise it's just a shift to verbosity, eating into the finite attention span within the brain. Rather, if the intent is properly documented, then the junior devs can still work on the parts of the code they understand, and reach out to a senior dev when they need to touch the part they don't understand, because even if they don't quite grasp the "how", they can follow the "why" in the code.
    - diggan 9y ago
      > Besides, code speaks to the compiler/runtime; comments speak to the human. > - The machine need to know HOW something should happen. That's code. > - The human needs to understand WHY that thing should happen that way. While valuable, some people argue that they should be the same (granted, I mostly deal with high-abstraction language). For example most (all?) lisps have homoiconicity which means the computer and you see the code the same.
      - pjc50 9y ago
        Homoiconicity is irrelevant - comment text has no meaning to the computer but can do for the human. Computers have a hard time with "why".
    - ithkuil 9y ago
      yeah. I've seen a lot of comments like: // Sleep for 10 minutes sleep(15*60) Unfortunately, the compiler cannot check your comments. Don't put facts that are better looked up in the actual code and that they only risk getting out of sync with the code.
      - BoorishBears 9y ago
        And to keep with the theme of self-documenting, the self-documenting version of that would be: NAP_LENGTH_MINUTES = 15; ... sleep(NAP_LENGTH_MINUTES*60);
        Clubber 9y ago
        Still not good enough. Why is this nap function in there? If I want to make it faster and didn't know, I would just remove all references to it. What did I break? Can't tell by that variable name.
        BoorishBears 9y ago
        a) Self documenting doesn't mean no comments b) I didn't give enough context for your specific commentary to really make sense. I mean, when did I even say this is a function? It's a snippet of pseudo-code not a code sample. c) Are you really running around programs ripping out references because you don't know what they do? I'd advise working on your definition of optimization before worrying about whether your code documents itself.
  - diggan 9y ago
    In my mind "the code is self-documenting" doesn't mean that you should have no comments anywhere in the code. It rather says that instead of lazily adding a comment for some complex piece of code, try to refactor the code so it better explains what is happening there. And then sometimes, you just have some compiler-hack or otherwise complex piece of interaction that you can't refactor into something better, and then it's of course better to add a comment rather than just leaving it there.
  - zip1234 9y ago
    And the other side of the coin is that being too focused on documenting all of your code usually ends up with lots of out of date and confusing documentation over time.
  - crdoconnor 9y ago
    >And the reason that "the code is self-documenting" is a bad smell is because in 3 months even the 'rock star' who wrote it won't remember without appropriate help That simply means you're working with poor developers.
    - Clubber 9y ago
      So you've never written code and come back to it 6 months later said said to yourself, "why did I do this?"
      - tbrownaw 9y ago
        There are two kinds of that. One is "wtf was I thinking", which comments won't help with. The other is "where did the requirement come from", and that's (1) not a "cock-sure of themselves" sort of thing; and (2) best solved by putting a tracking number on the commit message, rather than traditional code comments.
      - crdoconnor 9y ago
        Many years ago yes, but not recently. If you're a supposed "rock star" senior developer doing this it means you're just a bad developer. If you're a junior doing it just means you have some maturing to do.
  - cema 9y ago
    A self-documenting code means we can (relatively) easily see what is being done by the program just by reading the program. What is one question; why is another. When we work with the existing code (debugging, maintenance) we need to know answers to both questions. So, in addition to a well written (self-documenting) code base we need a document explaining the rationale for the choices that were made and, more generally, the context in which the code was created.
- ArturT 9y ago
  It's easy to lose yourself as a developer in problem-solving mode instead of looking at the big picture of a project. It's great to have people around you that reminds you the code is just a part of the more complex story - how to help your client solve a business problem.
  - DamonHD 9y ago
    That is a hard lesson to learn; I'm still working on it decades in!
  - crdoconnor 9y ago
    It's better to lose yourself, IMO. I've been most productive when working with product managers who delivered crystal clear user stories and precisely ordered priorities and took pressure off me having to deal with "that side" of the business. If I have to deal with ambiguous specifications, vague priorities and to fill in the gaps I need to start modeling the business's needs, operational structure and priorities in order to make appropriate decisions then that means I have fewer cognitive resources to deal with the actual coding. i.e. it's not just code that needs to be loosely coupled, it's businesses.
- maxxxxx 9y ago
  I think you should rephrase this as "code that can't be explained to a junior developer". There certainly is legitimate code that is not easy to understand without knowing some background.
- miga 9y ago
  Really depends how bright is your "junior developer". Obviously you cannot expect complex code to be well understood without background and programming capability. Having well-documented code is one thing, and ability to work on this code without breaking things is another.
- wolco 9y ago
  Not sure all rules are absolute. If you can write for the lowest common dominator you may not be writing anything overcomplex.
- flavio81 9y ago
  >if you write code that can't be understood by a junior developer Only true for simple apps (i.e., CRUD, etc.)
jasonmaydie 9y ago
Well that's a broad statement. We don't all need the same thing.
- katastic 9y ago
  Tomorrow from Gamesutra: "Developers are dead. Good developers don't have to be your audience!"
twobyfour 9y ago
It depends so much on what you're building. If you're doing _groundbreaking_ research in, say, AI or facial recognition or whatever, you may need people who are technical superstars. If you're building the average CRUD-plus-workflow application, the last thing you want are superstars who are going to get bored with routine work. Then they'll go off over-engineering some minor feature or spending weeks at a time inventing some algorithm you don't need instead of building the product you do need - just to keep themselves from going stir crazy. What you really want are people who are technically not outstanding but quite capable and have very strong soft skills. People who can work well as part of a team; people who mentor and learn well; people who follow through on their tasks; people who not only can, but want to understand your product and business so they can make small decisions independently and well as they work; people who are good at prioritizing their own work; people who are good at identifying risk and knowing when it's worth the time to address; people who are good at communicating with both teammates and management. Although you might argue that people with several or all these qualities are rare enough to be superstars in their own way, they're not superstars in the sense often discussed in forums like HN.
- pyrophane 9y ago
  Ah, but if you are doing groundbreaking AI research, you need AI experts. You will also need developers, but those developers may not actually need to be superstars.
  - nur0n 9y ago
    I think 'groundbreaking AI' was used as an example of something which is (1) new and (2) requires efficient use of hardware. Of course you will need domain experts. But if the new idea requires infrastructure which has not been built and places high demands on the machine, then the project will require above average developers.
  - cbsmith 9y ago
    It sure helps if they are though.
  - alexasmyths 9y ago
hathym 9y ago
the real question is, can you afford Superstar Developers?
- chrisco255 9y ago
  Yes because there's no real agreed upon definition of "super star" developer. So we're all super stars?
nickthemagicman 9y ago
Why wouldn't you try to get the best developer you can pay for?
- vonmoltke 9y ago
  Because this industry keeps going on and on about a shortage of competent developers?
- ubernostrum 9y ago
  See "We only hire the best means we only hire the trendiest": https://danluu.com/programmer-moneyball/ https://danluu.com/programmer-moneyball/
cbsmith 9y ago
Team dynamics are of course critical, but part of that dynamic is "game recognizes game". Having highly skilled developers makes it easier to have an overall highly skilled team... and ironically that makes it easier to be selective for factors like "team dynamics". It's when you have weaker developers that you have conversations like, "we are just going to have to put up with the ahole because without them we'd be really screwed".
js8 9y ago
It's always interesting to work with geniuses, but I think.. If your business model is based on your employees being geniuses, then you probably have a wrong model.
leowoo91 9y ago
True, mostly. You might steel need few of them to lead by example.
HillaryBriss 9y ago
Evenness of communication is about giving everyone roughly equal chance to speak up, not having some parties dominate the conversation. in my work experience, there are almost always one or two leads who dominate the conversation.
miga 9y ago
Yeah, hire below-average developers instead and never end the job of cleaning up. I heard about startup that changed team three times, and had to rewrite codebase likewise.
- s73ver_ 9y ago
  I fail to see where they said "below average developers". Unless you think the average is "superstar".
DavidWoof 9y ago
I think most of this is, or should be, uncontroversial. While it's incredibly important to avoid bad developers, once you hit a certain high level of technical ability other traits become more important. Besides, this isn't a fixed scale. Except for a few outliers, the concept of "more skilled" doesn't really have a meaning once you pass a certain level. At that point, what many shops do is hire people they enjoy being around, which is usually a shorthand for hiring people just like them, and then create all sorts of pseudo-psychological justification for it. The truth is that one day isn't going to tell you much about a dev. Some people are really good when first meeting strangers, some people are very uncomfortable for at least a week. Everyone deals with that nervousness differently, and on the other side, most people are incredibly unaware of their own prejudices that might be affecting their one-day reaction to a new person. At the end of the day, there's really no magic formulas for creating great teams.
eksemplar 9y ago
Team working skills, business understanding, the ability to communicate from a social constructive point and an openness to working with prototyping in consumer focused project groups are much more important abilities than technical skills in a lot of modern development. Superstars and best practice masters can be important, but all those enterprise applications we build on all the right practices are being replaced by web-apps, microservices and a range of other things, effectively rendering all the brilliant work useless because no one ever revisited shit. I get why you'd want a technical superstar for certain things, like developing your long term libraries, but for most tasks a shitty programmer who is business savvy and actually capable of talking to non-it people will deliver a better end project. Of course a lot of superstar developers do the other things really well, as well.
notruthallowed 9y ago
The real "super star" is the programmer who can put their head down and focus on their code day in day out, for years. It's not about being Albert Einstein for 99.9% of programming, it's about sustained focus and effort.
klagermkii 9y ago
> In our case, we want a new hire to be able to act as an independent contributor, i.e. their work doesn’t have to be double-checked. We also focus a lot on craftsmanship since it means that we all are getting better at what we do and at a good pace. Maybe this varies between cities and job markets but when I read that baseline description he gives in an off-hand manner for the programmers he hires, I think I would probably be calling them "superstars". I don't know if the availability of skilled employees is great in Krakow, but when FizzBuzz type tests are still filtering a large percentage of applicants, it makes it sound like it's from another world. That's my concern when reading these kinds of hiring articles, it feels very different to how hiring looks when you aren't privileged to have an abundance of skilled candidates available.
throwaway2016a 9y ago
There is a third measurement. Experience. And the superstar developers tend to have more of it, although not exclusively. Specifically they have probably seen and done the problem you are trying to solve already and don't need to spend as much time learning and researching. Less seasoned developers take a lot of mentoring and not every company can do that. In fact the words "mentor" and "train" are nowhere in this article. Granted you don't have to be a superstar to have experience. And also, on some projects (like CRUD as someone else mentioned) less experienced developers have plenty enough experience to do the job. There is also the added benefit of experienced developers being able to see when something is being done the hard way. I've seen many cases in my career where a less experienced developer didn't know a tool or technique and would have (or did) go down the more expensive and time consuming path. What this article should be (and i think might be getting at slightly) is "you don't need superstar developers if you have superstar mentors." If you have neither you're in for longer development time and higher cost over time. The flip side of the coin is that superstars also have a tendency to favor projects that are mentally / academically challenging which leads to over-engineering or boredom and attrition.
chasedehan 9y ago
I would add a second element to the title "You Don't need Superstar Developers: You Need High-Acheivers" The challenge is really having a mixed team of high talent and minimal talent. While yes, those who are of lower talent will learn more from the super talented, the inverse is not always true. I have found many lazy (or at least not super motivated) devs who have the required minimum competence level, but are not super driven to crank out high quality work. This then makes me not want to work as hard. This is a little different in that in general companies should go after high-achievers, rather than a minimum technical competence.
- Clubber 9y ago
  I believe Spolsky summarized it as: 1. Smart. 2. Gets things done.

87 points by ArturT 9y ago

One of my most useful insights in software development is that no matter how smart you are, if you write code that can't be understood by a junior developer, it means that you didn't do a good job writing that code.

DamonHD 9y ago
And the reason that "the code is self-documenting" is a bad smell is because in 3 months even the 'rock star' who wrote it won't remember without appropriate help (eg comments). I've worked with some pretty smart developers in some pretty interesting roles, and the people cock-sure of themselves are rarely anything other than a poisonous danger to overall performance and deliverables typically. I say this as a lone wolf by inclination, though also unexpectedly happy on a trading floor with hundreds of people around not entirely managing their emotional interactions!
- athenot 9y ago
  Besides, code speaks to the compiler/runtime; comments speak to the human. - The machine need to know HOW something should happen. That's code. - The human needs to understand WHY that thing should happen that way. These are two different objectives, and good quality code weaves the two in the appropriate measure. Having said that, I don't believe all code should be reduced to the subset that a junior dev can understand. Keep it simple when possible, yes. But don't limit yourself, otherwise it's just a shift to verbosity, eating into the finite attention span within the brain. Rather, if the intent is properly documented, then the junior devs can still work on the parts of the code they understand, and reach out to a senior dev when they need to touch the part they don't understand, because even if they don't quite grasp the "how", they can follow the "why" in the code.
  - diggan 9y ago
    > Besides, code speaks to the compiler/runtime; comments speak to the human. > - The machine need to know HOW something should happen. That's code. > - The human needs to understand WHY that thing should happen that way. While valuable, some people argue that they should be the same (granted, I mostly deal with high-abstraction language). For example most (all?) lisps have homoiconicity which means the computer and you see the code the same.
    - pjc50 9y ago
      Homoiconicity is irrelevant - comment text has no meaning to the computer but can do for the human. Computers have a hard time with "why".
  - ithkuil 9y ago
    yeah. I've seen a lot of comments like: // Sleep for 10 minutes sleep(15*60) Unfortunately, the compiler cannot check your comments. Don't put facts that are better looked up in the actual code and that they only risk getting out of sync with the code.
    - BoorishBears 9y ago
      And to keep with the theme of self-documenting, the self-documenting version of that would be: NAP_LENGTH_MINUTES = 15; ... sleep(NAP_LENGTH_MINUTES*60);
      - Clubber 9y ago
        Still not good enough. Why is this nap function in there? If I want to make it faster and didn't know, I would just remove all references to it. What did I break? Can't tell by that variable name.
        BoorishBears 9y ago
        a) Self documenting doesn't mean no comments b) I didn't give enough context for your specific commentary to really make sense. I mean, when did I even say this is a function? It's a snippet of pseudo-code not a code sample. c) Are you really running around programs ripping out references because you don't know what they do? I'd advise working on your definition of optimization before worrying about whether your code documents itself.
- diggan 9y ago
  In my mind "the code is self-documenting" doesn't mean that you should have no comments anywhere in the code. It rather says that instead of lazily adding a comment for some complex piece of code, try to refactor the code so it better explains what is happening there. And then sometimes, you just have some compiler-hack or otherwise complex piece of interaction that you can't refactor into something better, and then it's of course better to add a comment rather than just leaving it there.
- zip1234 9y ago
  And the other side of the coin is that being too focused on documenting all of your code usually ends up with lots of out of date and confusing documentation over time.
- crdoconnor 9y ago
  >And the reason that "the code is self-documenting" is a bad smell is because in 3 months even the 'rock star' who wrote it won't remember without appropriate help That simply means you're working with poor developers.
  - Clubber 9y ago
    So you've never written code and come back to it 6 months later said said to yourself, "why did I do this?"
    - tbrownaw 9y ago
      There are two kinds of that. One is "wtf was I thinking", which comments won't help with. The other is "where did the requirement come from", and that's (1) not a "cock-sure of themselves" sort of thing; and (2) best solved by putting a tracking number on the commit message, rather than traditional code comments.
    - crdoconnor 9y ago
      Many years ago yes, but not recently. If you're a supposed "rock star" senior developer doing this it means you're just a bad developer. If you're a junior doing it just means you have some maturing to do.
- cema 9y ago
  A self-documenting code means we can (relatively) easily see what is being done by the program just by reading the program. What is one question; why is another. When we work with the existing code (debugging, maintenance) we need to know answers to both questions. So, in addition to a well written (self-documenting) code base we need a document explaining the rationale for the choices that were made and, more generally, the context in which the code was created.
ArturT 9y ago
It's easy to lose yourself as a developer in problem-solving mode instead of looking at the big picture of a project. It's great to have people around you that reminds you the code is just a part of the more complex story - how to help your client solve a business problem.
- DamonHD 9y ago
  That is a hard lesson to learn; I'm still working on it decades in!
- crdoconnor 9y ago
  It's better to lose yourself, IMO. I've been most productive when working with product managers who delivered crystal clear user stories and precisely ordered priorities and took pressure off me having to deal with "that side" of the business. If I have to deal with ambiguous specifications, vague priorities and to fill in the gaps I need to start modeling the business's needs, operational structure and priorities in order to make appropriate decisions then that means I have fewer cognitive resources to deal with the actual coding. i.e. it's not just code that needs to be loosely coupled, it's businesses.
maxxxxx 9y ago
I think you should rephrase this as "code that can't be explained to a junior developer". There certainly is legitimate code that is not easy to understand without knowing some background.
miga 9y ago
Really depends how bright is your "junior developer". Obviously you cannot expect complex code to be well understood without background and programming capability. Having well-documented code is one thing, and ability to work on this code without breaking things is another.
wolco 9y ago
Not sure all rules are absolute. If you can write for the lowest common dominator you may not be writing anything overcomplex.
flavio81 9y ago
>if you write code that can't be understood by a junior developer Only true for simple apps (i.e., CRUD, etc.)

jasonmaydie 9y ago

Well that's a broad statement. We don't all need the same thing.

katastic 9y ago
Tomorrow from Gamesutra: "Developers are dead. Good developers don't have to be your audience!"

twobyfour 9y ago

It depends so much on what you're building. If you're doing _groundbreaking_ research in, say, AI or facial recognition or whatever, you may need people who are technical superstars. If you're building the average CRUD-plus-workflow application, the last thing you want are superstars who are going to get bored with routine work. Then they'll go off over-engineering some minor feature or spending weeks at a time inventing some algorithm you don't need instead of building the product you do need - just to keep themselves from going stir crazy. What you really want are people who are technically not outstanding but quite capable and have very strong soft skills. People who can work well as part of a team; people who mentor and learn well; people who follow through on their tasks; people who not only can, but want to understand your product and business so they can make small decisions independently and well as they work; people who are good at prioritizing their own work; people who are good at identifying risk and knowing when it's worth the time to address; people who are good at communicating with both teammates and management. Although you might argue that people with several or all these qualities are rare enough to be superstars in their own way, they're not superstars in the sense often discussed in forums like HN.

pyrophane 9y ago
Ah, but if you are doing groundbreaking AI research, you need AI experts. You will also need developers, but those developers may not actually need to be superstars.
- nur0n 9y ago
  I think 'groundbreaking AI' was used as an example of something which is (1) new and (2) requires efficient use of hardware. Of course you will need domain experts. But if the new idea requires infrastructure which has not been built and places high demands on the machine, then the project will require above average developers.
- cbsmith 9y ago
  It sure helps if they are though.
- alexasmyths 9y ago

hathym 9y ago

the real question is, can you afford Superstar Developers?

chrisco255 9y ago
Yes because there's no real agreed upon definition of "super star" developer. So we're all super stars?

nickthemagicman 9y ago

Why wouldn't you try to get the best developer you can pay for?

vonmoltke 9y ago
Because this industry keeps going on and on about a shortage of competent developers?
ubernostrum 9y ago
See "We only hire the best means we only hire the trendiest": https://danluu.com/programmer-moneyball/ https://danluu.com/programmer-moneyball/

cbsmith 9y ago

Team dynamics are of course critical, but part of that dynamic is "game recognizes game". Having highly skilled developers makes it easier to have an overall highly skilled team... and ironically that makes it easier to be selective for factors like "team dynamics". It's when you have weaker developers that you have conversations like, "we are just going to have to put up with the ahole because without them we'd be really screwed".

js8 9y ago

It's always interesting to work with geniuses, but I think.. If your business model is based on your employees being geniuses, then you probably have a wrong model.

leowoo91 9y ago

True, mostly. You might steel need few of them to lead by example.

HillaryBriss 9y ago

Evenness of communication is about giving everyone roughly equal chance to speak up, not having some parties dominate the conversation. in my work experience, there are almost always one or two leads who dominate the conversation.

miga 9y ago

Yeah, hire below-average developers instead and never end the job of cleaning up. I heard about startup that changed team three times, and had to rewrite codebase likewise.

s73ver_ 9y ago
I fail to see where they said "below average developers". Unless you think the average is "superstar".

DavidWoof 9y ago

I think most of this is, or should be, uncontroversial. While it's incredibly important to avoid bad developers, once you hit a certain high level of technical ability other traits become more important. Besides, this isn't a fixed scale. Except for a few outliers, the concept of "more skilled" doesn't really have a meaning once you pass a certain level. At that point, what many shops do is hire people they enjoy being around, which is usually a shorthand for hiring people just like them, and then create all sorts of pseudo-psychological justification for it. The truth is that one day isn't going to tell you much about a dev. Some people are really good when first meeting strangers, some people are very uncomfortable for at least a week. Everyone deals with that nervousness differently, and on the other side, most people are incredibly unaware of their own prejudices that might be affecting their one-day reaction to a new person. At the end of the day, there's really no magic formulas for creating great teams.

eksemplar 9y ago

Team working skills, business understanding, the ability to communicate from a social constructive point and an openness to working with prototyping in consumer focused project groups are much more important abilities than technical skills in a lot of modern development. Superstars and best practice masters can be important, but all those enterprise applications we build on all the right practices are being replaced by web-apps, microservices and a range of other things, effectively rendering all the brilliant work useless because no one ever revisited shit. I get why you'd want a technical superstar for certain things, like developing your long term libraries, but for most tasks a shitty programmer who is business savvy and actually capable of talking to non-it people will deliver a better end project. Of course a lot of superstar developers do the other things really well, as well.

notruthallowed 9y ago

The real "super star" is the programmer who can put their head down and focus on their code day in day out, for years. It's not about being Albert Einstein for 99.9% of programming, it's about sustained focus and effort.

klagermkii 9y ago

> In our case, we want a new hire to be able to act as an independent contributor, i.e. their work doesn’t have to be double-checked. We also focus a lot on craftsmanship since it means that we all are getting better at what we do and at a good pace. Maybe this varies between cities and job markets but when I read that baseline description he gives in an off-hand manner for the programmers he hires, I think I would probably be calling them "superstars". I don't know if the availability of skilled employees is great in Krakow, but when FizzBuzz type tests are still filtering a large percentage of applicants, it makes it sound like it's from another world. That's my concern when reading these kinds of hiring articles, it feels very different to how hiring looks when you aren't privileged to have an abundance of skilled candidates available.

throwaway2016a 9y ago

There is a third measurement. Experience. And the superstar developers tend to have more of it, although not exclusively. Specifically they have probably seen and done the problem you are trying to solve already and don't need to spend as much time learning and researching. Less seasoned developers take a lot of mentoring and not every company can do that. In fact the words "mentor" and "train" are nowhere in this article. Granted you don't have to be a superstar to have experience. And also, on some projects (like CRUD as someone else mentioned) less experienced developers have plenty enough experience to do the job. There is also the added benefit of experienced developers being able to see when something is being done the hard way. I've seen many cases in my career where a less experienced developer didn't know a tool or technique and would have (or did) go down the more expensive and time consuming path. What this article should be (and i think might be getting at slightly) is "you don't need superstar developers if you have superstar mentors." If you have neither you're in for longer development time and higher cost over time. The flip side of the coin is that superstars also have a tendency to favor projects that are mentally / academically challenging which leads to over-engineering or boredom and attrition.

chasedehan 9y ago

I would add a second element to the title "You Don't need Superstar Developers: You Need High-Acheivers" The challenge is really having a mixed team of high talent and minimal talent. While yes, those who are of lower talent will learn more from the super talented, the inverse is not always true. I have found many lazy (or at least not super motivated) devs who have the required minimum competence level, but are not super driven to crank out high quality work. This then makes me not want to work as hard. This is a little different in that in general companies should go after high-achievers, rather than a minimum technical competence.

Clubber 9y ago
I believe Spolsky summarized it as: 1. Smart. 2. Gets things done.