4 ms·

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 t

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.
      - BlargMcLarg 6y ago
        Is it? Often times I feel Scrum was more invented as a way to centralize communication under the lofty goal of increasing its quality, and decreasing the quantity of communication (make all activities central to reduce decentralized meetings with loads of people). Which to me says the opposite of making communication cheap. In practice, I feel the opposite tends to happen too. Not only does the quantity increase, but the quality of these centralized activities is questionable at best, and high quality decentralized activities slowly disappear due to the increased overhead. In tight knit teams, I find many of the centralized activities are unnecessary, since we deal with them as we go anyway. If we don't, someone will end up blocked for a day if not multiple days. The only exceptions being large design choices and assuring everyone works towards the same goal. If you need to sync on that every day in your average CRUD webapp dev team, I highly question how tightly knit the team is.
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.

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.
    - BlargMcLarg 6y ago
      Is it? Often times I feel Scrum was more invented as a way to centralize communication under the lofty goal of increasing its quality, and decreasing the quantity of communication (make all activities central to reduce decentralized meetings with loads of people). Which to me says the opposite of making communication cheap. In practice, I feel the opposite tends to happen too. Not only does the quantity increase, but the quality of these centralized activities is questionable at best, and high quality decentralized activities slowly disappear due to the increased overhead. In tight knit teams, I find many of the centralized activities are unnecessary, since we deal with them as we go anyway. If we don't, someone will end up blocked for a day if not multiple days. The only exceptions being large design choices and assuring everyone works towards the same goal. If you need to sync on that every day in your average CRUD webapp dev team, I highly question how tightly knit the team is.

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.