3 ms·

> Does this not scream "just the distribution of outcomes can drastically differ" at you? Yes. My argument is that outcomes depend more on the people than tool

by Swizec 1y ago

> Does this not scream "just the distribution of outcomes can drastically differ" at you? Yes. My argument is that outcomes depend more on the people than tools.

perching_aix 1y ago
How does that follow? Or are we talking past each other? I tried to model this formally (well, to the extent I can model anything formally), cause this is a fun little exercise in a way, and got that at least as far as my toy model goes, it's a wash, both matter equally (since at the extremes, they will approach each other's distributions, i.e. the distribution of expertise or the distribution of tool choice). Or to be more specific, what matters more is what you can change more, something I only accounted for in the very end. And I don't think significantly pushing the needle in expertise, especially in a way that persists over time, is realistic. People need time to gain expertise, so those with majority expertise will always be a minority. But improving tooling and doing so with long lasting effects is much more realistic. Hence, good tooling that leads your hand matters more. It raises the bar, and automatically ensures past mistakes aren't repeated without a need for costly rediscovery or specific training.
- Swizec 1y ago
  I think we are violently agreeing. Think of frameworks as "distilled experience". They help the next "generation" go faster because they don't need to make all the same mistakes. This is awesome. But it is not magic. People will make a mess. Often because they hold the framework wrong and/or miss what it's trying to do for them. Or just don't grok the author's beautiful vision. However, an experienced practician groks the fundamentals and can quickly adapt to any framework. Because all the frameworks are built on similar fundamentals so it's easy to hold them correctly. You go "Ah, the author believes X, so if we just assume X, it all falls into place and the code looks great". That said, you might be working in a domain where X is fundamentally untrue. Then this is the wrong framework and an experienced practician will go "This is the wrong tool and choose a tool that fits better". The thing that doesn't fit may be the current team/experience moreso than the business domain. At the end of the day more experienced engineers will produce a better solution than less experienced engineers. For a variety of reasons. Good tools can make less experienced engineers ramp up faster.
  - perching_aix 1y ago
    Oh okay, we are indeed in agreement then. > That said, you might be working in a domain where X is fundamentally untrue. Then this is the wrong framework and an experienced practician will go "This is the wrong tool and choose a tool that fits better". Agreed, this is always the money shot. I further think that the holy grail for advancements is for them to lead people's hands in a way that is self-justifying. It's a very tall and cruel order, but I think it's absolutely essential. If a solution fails to do this, people eventually turn on it, and adoption reverts or otherwise falls apart. I'm particularly worried about this happening to e.g. Rust, but this can be applied to basically anything.

by Swizec 1y ago

> Does this not scream "just the distribution of outcomes can drastically differ" at you? Yes. My argument is that outcomes depend more on the people than tools.

perching_aix 1y ago

How does that follow? Or are we talking past each other? I tried to model this formally (well, to the extent I can model anything formally), cause this is a fun little exercise in a way, and got that at least as far as my toy model goes, it's a wash, both matter equally (since at the extremes, they will approach each other's distributions, i.e. the distribution of expertise or the distribution of tool choice). Or to be more specific, what matters more is what you can change more, something I only accounted for in the very end. And I don't think significantly pushing the needle in expertise, especially in a way that persists over time, is realistic. People need time to gain expertise, so those with majority expertise will always be a minority. But improving tooling and doing so with long lasting effects is much more realistic. Hence, good tooling that leads your hand matters more. It raises the bar, and automatically ensures past mistakes aren't repeated without a need for costly rediscovery or specific training.

Swizec 1y ago
I think we are violently agreeing. Think of frameworks as "distilled experience". They help the next "generation" go faster because they don't need to make all the same mistakes. This is awesome. But it is not magic. People will make a mess. Often because they hold the framework wrong and/or miss what it's trying to do for them. Or just don't grok the author's beautiful vision. However, an experienced practician groks the fundamentals and can quickly adapt to any framework. Because all the frameworks are built on similar fundamentals so it's easy to hold them correctly. You go "Ah, the author believes X, so if we just assume X, it all falls into place and the code looks great". That said, you might be working in a domain where X is fundamentally untrue. Then this is the wrong framework and an experienced practician will go "This is the wrong tool and choose a tool that fits better". The thing that doesn't fit may be the current team/experience moreso than the business domain. At the end of the day more experienced engineers will produce a better solution than less experienced engineers. For a variety of reasons. Good tools can make less experienced engineers ramp up faster.
- perching_aix 1y ago
  Oh okay, we are indeed in agreement then. > That said, you might be working in a domain where X is fundamentally untrue. Then this is the wrong framework and an experienced practician will go "This is the wrong tool and choose a tool that fits better". Agreed, this is always the money shot. I further think that the holy grail for advancements is for them to lead people's hands in a way that is self-justifying. It's a very tall and cruel order, but I think it's absolutely essential. If a solution fails to do this, people eventually turn on it, and adoption reverts or otherwise falls apart. I'm particularly worried about this happening to e.g. Rust, but this can be applied to basically anything.