5 ms·

I don't think there is enough context to determine that. It seems plausible that it could maybe be a mix of being highly productive due to the lack of overhead

I don't think there is enough context to determine that. It seems plausible that it could maybe be a mix of being highly productive due to the lack of overhead of working with many other people and some obfuscation through complexity probably for the same reason that he wasn't working with other people and could optimize for only his own legibility.

gsibble 4y ago
It was a combination of being the sole decision maker, architect, product manager, etc. without having to coordinate with a team, being very senior (25+ years), being a very fast coder (I produced 4x the lines of code of anyone else at the company during my year there), and the fact they only hired jrs other than me straight out of coding camps. They expected code monkeys to write Shakespeare. This was a bank with extreme security requirements that I build in a high sophisticated microservice architecture. My code was easy to read, but the systems were certainly not easy to understand, especially to jrs with zero experience in microservices, Kubernetes, devops at all, etc..
kayodelycaon 4y ago
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.

gsibble 4y ago

It was a combination of being the sole decision maker, architect, product manager, etc. without having to coordinate with a team, being very senior (25+ years), being a very fast coder (I produced 4x the lines of code of anyone else at the company during my year there), and the fact they only hired jrs other than me straight out of coding camps. They expected code monkeys to write Shakespeare. This was a bank with extreme security requirements that I build in a high sophisticated microservice architecture. My code was easy to read, but the systems were certainly not easy to understand, especially to jrs with zero experience in microservices, Kubernetes, devops at all, etc..

kayodelycaon 4y ago

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.