4 ms·

I don't think I'm a 100x developer or anything, but I think people underestimate the compounding interest of being a 5x-10x developer. If you architect things

by cbanek 6y ago

I don't think I'm a 100x developer or anything, but I think people underestimate the compounding interest of being a 5x-10x developer. If you architect things just right today, that can save you a lot of time tomorrow. Spending time testing today can save weeks of bug time later, which can be spent to create something useful, compounding on itself. If we say green field is 10x, and someone is doing good things, I think that should go up over time. Getting things like builds, documentation, tests, make people more productive. Whereas on the other hand, people who make code worse eventually start drowning in their own filth, and eventually slow down to nearly nothing. Filth also compounds.

asciident 6y ago
I was involved in an accidental situation where two teams at different companies worked on the exact same project from the same starting point, each led by different developers. This was not the company's core product, but a necessary part of it (for anonymity, let's say this was the device driver for a fancy piece of hardware). The lead developers on each selected different frameworks, used different data architectures, and set up different workflows. One project became hugely convoluted, with bugs that were very difficult to trace due to race conditions, the way the navigation worked, and choices that let to more complex code. The other team had a much simpler architecture, and was literally 95% less code. That team was able to add new features with ease, and without complex bugs cropping up out of nowhere. In fact, that project went into "maintenance mode" because there was nothing else to add, and the lead developer could just add one or two minor things when they cropped up, and instead spent most of his time on a new unrelated project. I'd say the lead developer with the better architecture was not only 100X, but the other team's lead developer would probably lead to the downfall of that company -- both morale and development speed would plummet to 0.
- fsloth 6y ago
  Yes - excellent developers are a productivity multiplier. It’s not about the 12’o clock shoot-from-the hip duel - the one who shoots more codepoints in the general direction leaves winner. A piece of code - if it ends up in production - has so many potential ways to waste work hours that avoiding just a fraction of them is a huge win.
  - asciident 6y ago
    Yes, and not just hours of work, but reputation damage. Think of all the products out there where people say "but it sucks because it crashes for no reason sometimes." These are not reproducible crashes generally (as most developers can fix those), but rather bad developer decisions that led to a system that is hard to make bug-free due to the way it's structured. Even the decision to use a programming language without pointers can lead to fewer unexplained crashes, security vulnerabilities, etc.
- castlecrasher2 6y ago
  What was the outcome? Did the convoluted project get abandoned?
- ayewo 6y ago
  This is an interesting story. Was wondering if you have it written up somewhere so I can cite it? If not, perhaps you could mention how you’d like for it to be cited, thanks. On a lighter note your username definitely checks out :)
dktoao 6y ago
Yes, but I don't think it compounds forever. There is a natural thermodynamic limit somewhere. In practice if your company has a 1x code-base you are working for a decent company. If your company has a 5x code-base, you are working for a world class company. EDIT: On the other hand, there is no limit in the other direction and that is where companies end up in big time trouble with a 0.01x codebase.
- cbanek 6y ago
  It's true, it doesn't compound forever, I think because eventually it is finished, and you don't want to add things to it. I think knowing when something is finished as opposed to adding yet another tool on a swiss-army knife is also an important skill. Otherwise you end up with a swiss-army ball of mud. I'm also going to go out on a limb and say there's such a thing as a negative codebase. For example, let's say I have to work in a codebase for a particular political reason, and I can't rewrite something. But if that takes me 100x the time it would to do it correctly, then really the codebase is actually a net negative. One example of this is places that use an in-house framework for something (when there isn't a good alternative), but then a good open source alternative comes around. Of course you don't want to rewrite things all the time either, so I do agree there is a limit, but really I think that comes down to the code doing exactly what it should in the least complex way possible (with no bugs). Once you get there, there's nowhere to go?
ticmasta 6y ago
There's a big difference between making obvious mistakes that make everything worse and making the "right" decision for a future consideration. Beyond first-hand experience (i.e. making the mistake and then recognizing it in a future, similar decision) I'd say even the best "architects" have about a 20% success rate when moving into uncharted territory. Planning for tomorrow at a strategic level is hard.
mbesto 6y ago
> but I think people underestimate the compounding interest of being a 5x-10x developer. If you architect things just right today, that can save you a lot of time tomorrow. I'd also argue that a lot of people over-architect solutions and they miss out capturing markets, which leads to real life economics for a business. YMMV
chansiky 6y ago
Exactly how I see it. Good code builds and compounds on itself. It makes every developer on the team more productive. Its not just about the output of the single "10x" developer. Just having them on your team increases your whole team's output, even after they've left. Sometimes other "10x" developers build on top of that work. Bad code also builds and compounds on itself. Same argument but in reverse. At some point the codebase becomes so unwieldy, someone will have to convince the manager, that a complete rewrite is arguably a better option.

by cbanek 6y ago

asciident 6y ago

I was involved in an accidental situation where two teams at different companies worked on the exact same project from the same starting point, each led by different developers. This was not the company's core product, but a necessary part of it (for anonymity, let's say this was the device driver for a fancy piece of hardware). The lead developers on each selected different frameworks, used different data architectures, and set up different workflows. One project became hugely convoluted, with bugs that were very difficult to trace due to race conditions, the way the navigation worked, and choices that let to more complex code. The other team had a much simpler architecture, and was literally 95% less code. That team was able to add new features with ease, and without complex bugs cropping up out of nowhere. In fact, that project went into "maintenance mode" because there was nothing else to add, and the lead developer could just add one or two minor things when they cropped up, and instead spent most of his time on a new unrelated project. I'd say the lead developer with the better architecture was not only 100X, but the other team's lead developer would probably lead to the downfall of that company -- both morale and development speed would plummet to 0.

fsloth 6y ago
Yes - excellent developers are a productivity multiplier. It’s not about the 12’o clock shoot-from-the hip duel - the one who shoots more codepoints in the general direction leaves winner. A piece of code - if it ends up in production - has so many potential ways to waste work hours that avoiding just a fraction of them is a huge win.
- asciident 6y ago
  Yes, and not just hours of work, but reputation damage. Think of all the products out there where people say "but it sucks because it crashes for no reason sometimes." These are not reproducible crashes generally (as most developers can fix those), but rather bad developer decisions that led to a system that is hard to make bug-free due to the way it's structured. Even the decision to use a programming language without pointers can lead to fewer unexplained crashes, security vulnerabilities, etc.
castlecrasher2 6y ago
What was the outcome? Did the convoluted project get abandoned?
ayewo 6y ago
This is an interesting story. Was wondering if you have it written up somewhere so I can cite it? If not, perhaps you could mention how you’d like for it to be cited, thanks. On a lighter note your username definitely checks out :)

dktoao 6y ago

Yes, but I don't think it compounds forever. There is a natural thermodynamic limit somewhere. In practice if your company has a 1x code-base you are working for a decent company. If your company has a 5x code-base, you are working for a world class company. EDIT: On the other hand, there is no limit in the other direction and that is where companies end up in big time trouble with a 0.01x codebase.

cbanek 6y ago
It's true, it doesn't compound forever, I think because eventually it is finished, and you don't want to add things to it. I think knowing when something is finished as opposed to adding yet another tool on a swiss-army knife is also an important skill. Otherwise you end up with a swiss-army ball of mud. I'm also going to go out on a limb and say there's such a thing as a negative codebase. For example, let's say I have to work in a codebase for a particular political reason, and I can't rewrite something. But if that takes me 100x the time it would to do it correctly, then really the codebase is actually a net negative. One example of this is places that use an in-house framework for something (when there isn't a good alternative), but then a good open source alternative comes around. Of course you don't want to rewrite things all the time either, so I do agree there is a limit, but really I think that comes down to the code doing exactly what it should in the least complex way possible (with no bugs). Once you get there, there's nowhere to go?

ticmasta 6y ago

There's a big difference between making obvious mistakes that make everything worse and making the "right" decision for a future consideration. Beyond first-hand experience (i.e. making the mistake and then recognizing it in a future, similar decision) I'd say even the best "architects" have about a 20% success rate when moving into uncharted territory. Planning for tomorrow at a strategic level is hard.

mbesto 6y ago

> but I think people underestimate the compounding interest of being a 5x-10x developer. If you architect things just right today, that can save you a lot of time tomorrow. I'd also argue that a lot of people over-architect solutions and they miss out capturing markets, which leads to real life economics for a business. YMMV

chansiky 6y ago

Exactly how I see it. Good code builds and compounds on itself. It makes every developer on the team more productive. Its not just about the output of the single "10x" developer. Just having them on your team increases your whole team's output, even after they've left. Sometimes other "10x" developers build on top of that work. Bad code also builds and compounds on itself. Same argument but in reverse. At some point the codebase becomes so unwieldy, someone will have to convince the manager, that a complete rewrite is arguably a better option.