3 ms·

I'm reminded of the quantity vs. quality groups in a photography class: https://sebastianhetman.com/why-quantity-matters/ https://sebastianhetman.com/why-quant

I'm reminded of the quantity vs. quality groups in a photography class: https://sebastianhetman.com/why-quantity-matters/ https://sebastianhetman.com/why-quantity-matters/ Do stuff, and you learn stuff. Go play.

x3n0ph3n3 1y ago
Quantity has a quality all its own.
- pvdebbe 1y ago
  It worked for Garry Winogrand, for one.
godelski 1y ago
While I generally agree with the conclusion of that, I think it might be a bit too naive. The quantity group has a trivial way to "hack" the metric. I can just sit there snapping photos of everything. I could just set up a camera to automatically snap photos all day and night. To be honest, if I'm not doing this at a stationary wall there's probably a good chance I get a good photo since even a tiny probability can be an expected result given enough samples. But I think the real magic ingredient comes from the explanation > The group never worried about the quality of their work, so they spent time experimenting with lighting, composition, and such. The way I read this is "The quantity group felt assured in their grade, so used the time to be creative and without pressure." But I think if you modified the experiment so that you'd grade students on a curve and in proportion to the number of photos they took then the results might differ. Their grade might not feel secure as it could take just one person to communicate that they're just snapping photos all day as fast as they can. In this setting I think you'd have even less ability to explore and experiment than the quality group. I do think the message is right though and I think this is the right strategy in any creative or primarily mental endeavor (including coding). The more the process depends on creativity the more time needs to be allocated to this type of exploration and freedom. I think in jobs like research that this should be the basis for how they are structured and effectively you should mostly remove evaluation metrics and embrace the fundamentally ad hoc nature. In things like coding I think you need more of a mix and the right mix depends highly on the actual objectives. But I wanted to make the above distinction because I think it is important if we're trying to figure out what those objectives are.
- d-us-vb 1y ago
  This is an interesting take. It maps decently to the "first to market" mentality of a lot of programming these days. For sure, we'd get better programmers if they were judged by the quantity of code they produced in their personal projects, but if "quantity learners" are simply forced to churn out bad code without any reflection or the time to experiment, then I would agree that it seems pretty naive to think they'll ever improve... except at a handful of patterns that make bad code sort of work.
  - godelski 1y ago
    Also think about software recently. Is it actually better? IME I face more bugs than ever. Trivial ones to that are clearly being deprioritized but relatively easily solvable.[0] Do an experiment for me. Write down every bug you face today. Even small. I think you'll be surprised at how many there are and even more at how many are likely simple to solve. I know it's not just me as so many around me are getting increasingly frustrated with their devices. It's not the big things, it's a thousand paper cuts. But if you just you look at a paper cut in isolation, it isn't meaningful. That's the problem and why they get ignored. But they get created because we care more about speed than direction. I'd argue that's a good way to end up over a cliff [0] https://news.ycombinator.com/item?id=45363210 https://news.ycombinator.com/item?id=45363210
    - pixl97 1y ago
      >I face more bugs than ever I mean, lets leave phones out of this for a moment and look at PCs... When was the last time your PC operating system crashed? When was the last time your applications you use on your PC crashed? When was the last time you could not find an application for your PC that did what you needed to accomplish? The early days of software absolutly sucked. Crashes, data loss, and limitations were the name of the game. The big things like data corruption were constantly problems. You didn't notice the small problems because you were fighting the big ones. The problem spaces software was solving for people was also relatively small. Now it's easy to find small bugs everywhere because software ate the world. It's harder to name something software has not expanded into than what it has, and yet we are still not near the boundaries of exploration of what software can do. When a system has not discovered its boundaries speed will almost always win over direction.

x3n0ph3n3 1y ago

Quantity has a quality all its own.

pvdebbe 1y ago
It worked for Garry Winogrand, for one.

godelski 1y ago

While I generally agree with the conclusion of that, I think it might be a bit too naive. The quantity group has a trivial way to "hack" the metric. I can just sit there snapping photos of everything. I could just set up a camera to automatically snap photos all day and night. To be honest, if I'm not doing this at a stationary wall there's probably a good chance I get a good photo since even a tiny probability can be an expected result given enough samples. But I think the real magic ingredient comes from the explanation > The group never worried about the quality of their work, so they spent time experimenting with lighting, composition, and such. The way I read this is "The quantity group felt assured in their grade, so used the time to be creative and without pressure." But I think if you modified the experiment so that you'd grade students on a curve and in proportion to the number of photos they took then the results might differ. Their grade might not feel secure as it could take just one person to communicate that they're just snapping photos all day as fast as they can. In this setting I think you'd have even less ability to explore and experiment than the quality group. I do think the message is right though and I think this is the right strategy in any creative or primarily mental endeavor (including coding). The more the process depends on creativity the more time needs to be allocated to this type of exploration and freedom. I think in jobs like research that this should be the basis for how they are structured and effectively you should mostly remove evaluation metrics and embrace the fundamentally ad hoc nature. In things like coding I think you need more of a mix and the right mix depends highly on the actual objectives. But I wanted to make the above distinction because I think it is important if we're trying to figure out what those objectives are.

d-us-vb 1y ago
This is an interesting take. It maps decently to the "first to market" mentality of a lot of programming these days. For sure, we'd get better programmers if they were judged by the quantity of code they produced in their personal projects, but if "quantity learners" are simply forced to churn out bad code without any reflection or the time to experiment, then I would agree that it seems pretty naive to think they'll ever improve... except at a handful of patterns that make bad code sort of work.
- godelski 1y ago
  Also think about software recently. Is it actually better? IME I face more bugs than ever. Trivial ones to that are clearly being deprioritized but relatively easily solvable.[0] Do an experiment for me. Write down every bug you face today. Even small. I think you'll be surprised at how many there are and even more at how many are likely simple to solve. I know it's not just me as so many around me are getting increasingly frustrated with their devices. It's not the big things, it's a thousand paper cuts. But if you just you look at a paper cut in isolation, it isn't meaningful. That's the problem and why they get ignored. But they get created because we care more about speed than direction. I'd argue that's a good way to end up over a cliff [0] https://news.ycombinator.com/item?id=45363210 https://news.ycombinator.com/item?id=45363210
  - pixl97 1y ago
    >I face more bugs than ever I mean, lets leave phones out of this for a moment and look at PCs... When was the last time your PC operating system crashed? When was the last time your applications you use on your PC crashed? When was the last time you could not find an application for your PC that did what you needed to accomplish? The early days of software absolutly sucked. Crashes, data loss, and limitations were the name of the game. The big things like data corruption were constantly problems. You didn't notice the small problems because you were fighting the big ones. The problem spaces software was solving for people was also relatively small. Now it's easy to find small bugs everywhere because software ate the world. It's harder to name something software has not expanded into than what it has, and yet we are still not near the boundaries of exploration of what software can do. When a system has not discovered its boundaries speed will almost always win over direction.