6 ms·

Isn't it kinda obvious? Same way great person <> ideal spouse for everybody. Great hackers tend to stand alone. If you are master at something it also means ev

Isn't it kinda obvious? Same way great person <> ideal spouse for everybody. Great hackers tend to stand alone. If you are master at something it also means everybody or almost everybody has less knowledge than you and this puts you in a kinda precarious situation. You can either slow down for the rest (ie. be ideal "team player") or do work at your own pace (ie. be a "great hacker" or "10x developer"). Or advance to management role... Great hackers tend to require a lot of organization to support them. Somebody needs to do the dirty work that the "great hacker" does not care to complete because he has already set his eyes on another idea. And there tends to be a lot of dirty work... Or they don't require any organization to support them at all. But then they don't scale and are limited by their own (sometimes considerable) output. This is also why you can't have a team full of rock stars and why these experiments tend to fail spectacularly. Either they assume other rockstars in their team are there to do their laundry or they just never cooperate at all and want to solve the problem on their own. "Great hackers" who can do both are worth their weight in diamonds but they are extremely rare. Ideally, if you are great hacker, you want to figure out what kind of person you are and what kind of environment suits your style of work. Likewise, if you are manager, you need to understand "great hackers" are not replaceable cogs and you always need to put more effort into setting up framework with which to extract value from them than with other members of your team.

username90 6y ago
If you put an average coder with a shitty coder then the average coder will usually become frustrated. If you put a great coder with an average coder the same thing happens. Some can handle it, but it will always be a strain. It isn't more complicated than that. There is no reason to associate a lot of negative personality traits with it.
- rightbyte 6y ago
  I don't agree. Mediocre coders do just fine with great coders.
  - corobo 6y ago
    Wasn't the point that the great coder suffers in that setup?
    - rightbyte 6y ago
      I meant it as mutual i.e. neither suffers. And I meant mediocre coders as in average, "not exceeding expectation". Suffers implies something destructive and I would hardly call working with ordinary men being destructive even though obviously the outcome might be better if all coders are great, even thought that is hardly realistic for most setups, especially bigger.
- lmilcin 6y ago
  I think it is a little bit more than putting together coders of very different skills. It is not just that the difference in skills causes frustration but also that frustrations over long period of time also influence the developer. For example, if you have observed, over long period of time, that people are generally slow and unreliable, that your products tend to work better, that you can think up better designs without bothering to talk to your team, ... wouldn't that influence your character and the way you typically interface with other developers? It is not that he/she became a great developer suddenly. This must have taken years.
  - rightbyte 6y ago
    Ye doing it yourself without outsourcing even the tiniest bit to your teammates is usually way more smooth and easy - keeping collaboration on a higher level. I just can't seem to share the plan in my head in a good way. Probably becouse it is very fuzzy until it is done. This is why I hate Scrum where tasks are supposed to be broken down and shared between the team members and the last person touching the issue has to ensure everything works together ...
    - BlargMcLarg 6y ago
      You're not the only one. I work with quite a few above-average and bright guys. Even something as simple as "you make this module, you make this module, I make this module and they all communicate through this core interface" is far from trivial. In something like Scrum, the emphasis seems to be more on "everyone works on this little piece of this module", which bloats the communication overhead required and I get into the same problem you describe: implementation details need to be made concrete much faster, as now people need to know them to proceed instead of a general idea what data they'll be getting. NB: I know this is not specific to Scrum, and Scrum does not enforce this. Yet I can't help but feel there is some sort of correlation.
      - lmilcin 6y ago
        To be fair the while the need for communication is inflated the goal of Scrum is also to make that communication cheap. That's why work in small, tightly knit teams, on the same feature. That's why refinings, plannings, standups, etc.
- watwut 6y ago
  People is different skills can actually cooperate. It is pretty easy in fact, because they tend like different tasks.
- Mauricebranagh 6y ago
  Should not the better coder mentor the less experienced one? I've only seen one case of some one who IMHO was not just suited as a developer and this is with support and a proper PIP process.
vsareto 6y ago
> Somebody needs to do the dirty work that the "great hacker" does not care to complete because he has already set his eyes on another idea. IMO if you are leaving stuff unfinished, you're probably not great and probably don't love the work. You're just chasing a high and not caring about the consequences.
- watwut 6y ago
  Tho, there are quite a few pros in that category. Consider themselves great, believe that they have more passion then everyone else, but they are fast because other people have to finish their work and do all time consuming parts and do the hard parts.
  - BlargMcLarg 6y ago
    I'd argue it may be the opposite. They are seen as pros because they don't spend the time finishing things, often despite the fact they are perfectly capable of finishing the job. They are getting 80% of the merit doing 20% of the job, while leaving others do the remaining 80% for 20% of the merit. They have more time to gather more merit, chase knowledge and ideas, experiment, which ends up opening doors. It isn't too far from how consultants tend to function, why job hopping is lucrative, etc.. There just isn't enough incentive to stay for the dirty work as long as others, be it the managers, the employers or the coworkers, don't hold the ones leaving the mess accountable.
    - lmilcin 6y ago
      Now, we have assumed we are talking about great developers. It is true that sometimes it is difficult to tell one from the other, if you are a manager and you squint your eyes a little bit. Sometimes mediocre developer masking himself as a great developer is able to create a distortion field when he never finishes anything and relies on help from others to achieve his perceived fantastic output. No, we are not talking about that kind of person. What I mean is a person that is truly great developer. The organizations will frequently try to make good use of this person. One strategy is to get that developer to work on green-field projects only. He will design/write the code but once it is in prod it is going to be outsourced to another team and the star developer moves to another exciting project. Another strategy is to offload as much non-critical work as possible. Junior developers to write to spec? Testers? "Devops" engineers (as much as I hate that term)? These are all possible way to keep the perceived star developer with only hardest problems. Now, I don't say it is a good practice -- it is just something I have noticed over the years. Good developers have much more say in what they are going to be working on and in what capacity and this means taking interesting tasks and leaving mundane to more junior members.
deleted 6y ago
[deleted]

username90 6y ago

If you put an average coder with a shitty coder then the average coder will usually become frustrated. If you put a great coder with an average coder the same thing happens. Some can handle it, but it will always be a strain. It isn't more complicated than that. There is no reason to associate a lot of negative personality traits with it.

rightbyte 6y ago
I don't agree. Mediocre coders do just fine with great coders.
- corobo 6y ago
  Wasn't the point that the great coder suffers in that setup?
  - rightbyte 6y ago
    I meant it as mutual i.e. neither suffers. And I meant mediocre coders as in average, "not exceeding expectation". Suffers implies something destructive and I would hardly call working with ordinary men being destructive even though obviously the outcome might be better if all coders are great, even thought that is hardly realistic for most setups, especially bigger.
lmilcin 6y ago
I think it is a little bit more than putting together coders of very different skills. It is not just that the difference in skills causes frustration but also that frustrations over long period of time also influence the developer. For example, if you have observed, over long period of time, that people are generally slow and unreliable, that your products tend to work better, that you can think up better designs without bothering to talk to your team, ... wouldn't that influence your character and the way you typically interface with other developers? It is not that he/she became a great developer suddenly. This must have taken years.
- rightbyte 6y ago
  Ye doing it yourself without outsourcing even the tiniest bit to your teammates is usually way more smooth and easy - keeping collaboration on a higher level. I just can't seem to share the plan in my head in a good way. Probably becouse it is very fuzzy until it is done. This is why I hate Scrum where tasks are supposed to be broken down and shared between the team members and the last person touching the issue has to ensure everything works together ...
  - BlargMcLarg 6y ago
    You're not the only one. I work with quite a few above-average and bright guys. Even something as simple as "you make this module, you make this module, I make this module and they all communicate through this core interface" is far from trivial. In something like Scrum, the emphasis seems to be more on "everyone works on this little piece of this module", which bloats the communication overhead required and I get into the same problem you describe: implementation details need to be made concrete much faster, as now people need to know them to proceed instead of a general idea what data they'll be getting. NB: I know this is not specific to Scrum, and Scrum does not enforce this. Yet I can't help but feel there is some sort of correlation.
    - lmilcin 6y ago
      To be fair the while the need for communication is inflated the goal of Scrum is also to make that communication cheap. That's why work in small, tightly knit teams, on the same feature. That's why refinings, plannings, standups, etc.
watwut 6y ago
People is different skills can actually cooperate. It is pretty easy in fact, because they tend like different tasks.
Mauricebranagh 6y ago
Should not the better coder mentor the less experienced one? I've only seen one case of some one who IMHO was not just suited as a developer and this is with support and a proper PIP process.

vsareto 6y ago

> Somebody needs to do the dirty work that the "great hacker" does not care to complete because he has already set his eyes on another idea. IMO if you are leaving stuff unfinished, you're probably not great and probably don't love the work. You're just chasing a high and not caring about the consequences.

watwut 6y ago
Tho, there are quite a few pros in that category. Consider themselves great, believe that they have more passion then everyone else, but they are fast because other people have to finish their work and do all time consuming parts and do the hard parts.
- BlargMcLarg 6y ago
  I'd argue it may be the opposite. They are seen as pros because they don't spend the time finishing things, often despite the fact they are perfectly capable of finishing the job. They are getting 80% of the merit doing 20% of the job, while leaving others do the remaining 80% for 20% of the merit. They have more time to gather more merit, chase knowledge and ideas, experiment, which ends up opening doors. It isn't too far from how consultants tend to function, why job hopping is lucrative, etc.. There just isn't enough incentive to stay for the dirty work as long as others, be it the managers, the employers or the coworkers, don't hold the ones leaving the mess accountable.
  - lmilcin 6y ago
    Now, we have assumed we are talking about great developers. It is true that sometimes it is difficult to tell one from the other, if you are a manager and you squint your eyes a little bit. Sometimes mediocre developer masking himself as a great developer is able to create a distortion field when he never finishes anything and relies on help from others to achieve his perceived fantastic output. No, we are not talking about that kind of person. What I mean is a person that is truly great developer. The organizations will frequently try to make good use of this person. One strategy is to get that developer to work on green-field projects only. He will design/write the code but once it is in prod it is going to be outsourced to another team and the star developer moves to another exciting project. Another strategy is to offload as much non-critical work as possible. Junior developers to write to spec? Testers? "Devops" engineers (as much as I hate that term)? These are all possible way to keep the perceived star developer with only hardest problems. Now, I don't say it is a good practice -- it is just something I have noticed over the years. Good developers have much more say in what they are going to be working on and in what capacity and this means taking interesting tasks and leaving mundane to more junior members.

deleted 6y ago

[deleted]