4 ms·

they worked in 2-3 day sprints for ridiculous hours, and then stayed home or might as well have. The other points you make might be big problems depending on t

they worked in 2-3 day sprints for ridiculous hours, and then stayed home or might as well have. The other points you make might be big problems depending on the situation, but this? What's wrong with someone taking a day off after a burst of productivity? This seems like classic valuing of face-time over results.

marcus_holmes 9y ago
it's not team-oriented behaviour. I'm not talking about face-time, but about having the attitude that you're part of a team. The "10x" works 16 hours a day for 3 days and produces a chunk of code that works, does what it's supposed to, ahead of schedule. So far, so awesome. But the rest of the team is working away on the rest of the project. Suddenly they're lumped with a huge chunk of code that they don't understand. They weren't involved in the design decisions, they didn't pair-program or brainstorm any of the code. It's pretty impenetrable. And the "10x" who wrote it is now unavailable after that "heroic" sprint so they can't even ask questions. Teams work together. Heroic sprints of productivity followed by absence is not working together. It's leaving other people to clean up your mess while you claim the credit.
- dmitrygr 9y ago
  You know that famous inverse square root code? Apple basic? Some things just cannot be pair programmed. They are simply impenetrable to average minds at the time. Your argument sounds like one for a Handicapper General, to be honest. (If missing the reference Google it). You want to handicap everyone actually competent with a slower partner. And before you claim the usual: it is ok to write suboptimal but simple to understand code, consider that in some cases we actually DO care for performance and size of code..
  - PhoneRemote 9y ago
    99.9% of modern software does not require that level of cleverness. Also, the fast inverse square root code is a poor example as it's: 1) A very small amount of code 2) Isolated from everything else 3) Conceptually easy to understand what it's accomplishing (even if the implementation itself is interesting and non-obvious) Most people would kill for a colleague who wrote code like that. No, instead what you most often get out of people like the OP is mentioning (because I too have worked with and been burned by them) is some weird pseudo-ORM they wrote from scratch because they don't like how Hibernate handles joins. Naturally, there's no documentation or even comments because it should be obvious why paxos was poorly implemented in this weird pseudo-ORM framework. And of course, the entire codebase was rewritten overnight to use this new framework as well.
  - chrisbennet 9y ago
    Metaphorically speaking, some mountain routes require a very, very good climber to scale. If it is a team that you are trying to get to the top, that amazing lead climber still needs to throw a rope down to the rest of the team. I do agree that sometimes managers want to fit "chefs" into a McDonald's like cooking process.
- A-25yzT 9y ago
  "team-oriented behavior"? So the talented individual gets to write all the code and explain it to other people at the same time? This is a well known major impediment for creative persons in any field. You can explain things after they are done, not while you are doing them. This is why average developers create such a drag on productivity. They always want meetings, explanations -- in short, anything that slows down the work horse and make them look productive in the process.
- le-mark 9y ago
  This is not 10x, this -10x. If a developer churns out tech debt in a vacuum, they're a liability, not an asset.
- Footkerchief 9y ago
  The parent post seems to assume that a "heroic sprint of productivity" would not include communication and documentation, i.e. that productivity only means coding. I don't see that assumption reflected in the grandparent post, and moreover if you don't consider communication productive in its own right, you're going to have much bigger problems than people taking a day off.

marcus_holmes 9y ago

it's not team-oriented behaviour. I'm not talking about face-time, but about having the attitude that you're part of a team. The "10x" works 16 hours a day for 3 days and produces a chunk of code that works, does what it's supposed to, ahead of schedule. So far, so awesome. But the rest of the team is working away on the rest of the project. Suddenly they're lumped with a huge chunk of code that they don't understand. They weren't involved in the design decisions, they didn't pair-program or brainstorm any of the code. It's pretty impenetrable. And the "10x" who wrote it is now unavailable after that "heroic" sprint so they can't even ask questions. Teams work together. Heroic sprints of productivity followed by absence is not working together. It's leaving other people to clean up your mess while you claim the credit.

dmitrygr 9y ago
You know that famous inverse square root code? Apple basic? Some things just cannot be pair programmed. They are simply impenetrable to average minds at the time. Your argument sounds like one for a Handicapper General, to be honest. (If missing the reference Google it). You want to handicap everyone actually competent with a slower partner. And before you claim the usual: it is ok to write suboptimal but simple to understand code, consider that in some cases we actually DO care for performance and size of code..
- PhoneRemote 9y ago
  99.9% of modern software does not require that level of cleverness. Also, the fast inverse square root code is a poor example as it's: 1) A very small amount of code 2) Isolated from everything else 3) Conceptually easy to understand what it's accomplishing (even if the implementation itself is interesting and non-obvious) Most people would kill for a colleague who wrote code like that. No, instead what you most often get out of people like the OP is mentioning (because I too have worked with and been burned by them) is some weird pseudo-ORM they wrote from scratch because they don't like how Hibernate handles joins. Naturally, there's no documentation or even comments because it should be obvious why paxos was poorly implemented in this weird pseudo-ORM framework. And of course, the entire codebase was rewritten overnight to use this new framework as well.
- chrisbennet 9y ago
  Metaphorically speaking, some mountain routes require a very, very good climber to scale. If it is a team that you are trying to get to the top, that amazing lead climber still needs to throw a rope down to the rest of the team. I do agree that sometimes managers want to fit "chefs" into a McDonald's like cooking process.
A-25yzT 9y ago
"team-oriented behavior"? So the talented individual gets to write all the code and explain it to other people at the same time? This is a well known major impediment for creative persons in any field. You can explain things after they are done, not while you are doing them. This is why average developers create such a drag on productivity. They always want meetings, explanations -- in short, anything that slows down the work horse and make them look productive in the process.
le-mark 9y ago
This is not 10x, this -10x. If a developer churns out tech debt in a vacuum, they're a liability, not an asset.
Footkerchief 9y ago
The parent post seems to assume that a "heroic sprint of productivity" would not include communication and documentation, i.e. that productivity only means coding. I don't see that assumption reflected in the grandparent post, and moreover if you don't consider communication productive in its own right, you're going to have much bigger problems than people taking a day off.