3 ms·

There are a lot of explanations possible. I’ve deal with with the aftermath of with “80% developers” my entire career. In two weeks, they’d write a good enough

There are a lot of explanations possible. I’ve deal with with the aftermath of with “80% developers” my entire career. In two weeks, they’d write a good enough program with no handling of edge cases or errors. Replacing one of these with a proper application can take a year. I’ve also dealt with a team of programmers who couldn’t come close to my productivity solo. It was due to constraints and communication overhead, not incompetence. When you go from a solo dev to a team of 19, that sounds more like a change in strategy by management than anything else.

bmitc 4y ago
I’m not sure what you mean by 80% developers, but I am generally cautious on developers who are seen as uber productive. I worked with one in the past, and they would blow through so much code. It amazed everyone else, but they left a literal wake in the code. It was just a gigantic mess when you dove into it that wasted so much time down the road in onboarding others, refactoring it, maintaining it, etc.
- deleted 4y ago
  [deleted]
- kayodelycaon 4y ago
  Sorry, I should have clarified, they are developers that quickly do 80% of the work and move to the next thing. They are often quite intelligent and very productive, but aren't inclined to think a problem through to completion.
  - bmitc 4y ago
    Gotcha, and no worries! That makes perfect sense. I was just calling it out that I wasn't for sure to ward off inadvertently supporting or commenting on something I wasn't sure about.
lamontcg 4y ago
Yeah, I've inherited a mess of software written by one of those before. I used to have some imposter syndrome because I wasn't that hyper productive, but not after having to clean that code up. For example, I found a supposedly queue-less parallel map / threadpool with 2 or 3 queues inside of it, which had weird deadlock bugs that would result in strange occasional timeouts. I replaced it with a parallel map with no queues built on top of a thin and standardized threading library. The deadlocks went away. The resulting code was pretty boring in readable. I never bothered to dig into why the old code deadlocked, but throwing it all away fixed all the problems. It is a lot easier to greenfield where you can put off the edge conditions till later and focus entirely on the first 80%, it is also really easy to greenfield when you focus on just typing as fast as you can and spray sloppy code everywhere (actually sloppy code like that crazy parallel map implementation I threw away). I suspect the latter is what a lot of "10x developers" actually are.

bmitc 4y ago

I’m not sure what you mean by 80% developers, but I am generally cautious on developers who are seen as uber productive. I worked with one in the past, and they would blow through so much code. It amazed everyone else, but they left a literal wake in the code. It was just a gigantic mess when you dove into it that wasted so much time down the road in onboarding others, refactoring it, maintaining it, etc.

deleted 4y ago
[deleted]
kayodelycaon 4y ago
Sorry, I should have clarified, they are developers that quickly do 80% of the work and move to the next thing. They are often quite intelligent and very productive, but aren't inclined to think a problem through to completion.
- bmitc 4y ago
  Gotcha, and no worries! That makes perfect sense. I was just calling it out that I wasn't for sure to ward off inadvertently supporting or commenting on something I wasn't sure about.

lamontcg 4y ago

Yeah, I've inherited a mess of software written by one of those before. I used to have some imposter syndrome because I wasn't that hyper productive, but not after having to clean that code up. For example, I found a supposedly queue-less parallel map / threadpool with 2 or 3 queues inside of it, which had weird deadlock bugs that would result in strange occasional timeouts. I replaced it with a parallel map with no queues built on top of a thin and standardized threading library. The deadlocks went away. The resulting code was pretty boring in readable. I never bothered to dig into why the old code deadlocked, but throwing it all away fixed all the problems. It is a lot easier to greenfield where you can put off the edge conditions till later and focus entirely on the first 80%, it is also really easy to greenfield when you focus on just typing as fast as you can and spray sloppy code everywhere (actually sloppy code like that crazy parallel map implementation I threw away). I suspect the latter is what a lot of "10x developers" actually are.