4 ms·

And Unix was mainly made by two people, it's astounding that as I get older, even tech managers don't know "the mythical man month", and how software production

And Unix was mainly made by two people, it's astounding that as I get older, even tech managers don't know "the mythical man month", and how software production generally scales.

thunky 8mo ago
Sorry but 99.999% of developers could not have built Unix. Or Winamp. Managers are crossing their fingers that devs they hire are no worse than average, and average isn't very good.
- sdf2erf 8mo ago
  Thats because the distribution of developer quality and capability is skewed.
- eqvinox 8mo ago
  > Sorry but a 99.999% of developers could not have built Unix. Or Winamp. > Managers are crossing their fingers that devs they hire are no worse than average, and average isn't very good. The problem is that that's the same skill required to safely use AI tools. You need to essentially audit its output, ensure that you have a sensible and consistent design (either supplied as input or created by the AI itself), and 'refine' the prompts as needed. AI does not make poor engineers produce better code. It does make poor engineers produce better-looking code, which is incredibly dangerous. But ultimately, considering the amount of code written by average engineers out there, it actually makes perfect sense for AI to be an average engineer — after all, that's the bulk of what it was trained on! Luckily, there's some selection effect there since good work propagates more, but that's a limited bias at best.
  - thunky 8mo ago
    Agree completely. Where I'm optimistic about AI is that it can also help identify poorly written code (even it's own code), and it can help rewrite it to be better quality. Average developers can't do this part. From what I've found it's very easy to ask the AI to look at code and suggest how to make the code maintainable (look for SRP violations, etc, etc). And it will go to work. Which means that we can already build this "quality" into the initial output via agent workflows.
- gamblor956 8mo ago
  Not today's programmers, no. The side effect of a massively increased programmer labor population is that the average skill of the group plummeted. But back then? Most programmers would not have tried but a substantial portion would have been able to if they did.
MyHonestOpinon 8mo ago
I do agree with this idea in the sense that companies keep trying to add people to projects to do more things or complete projects sooner which ends up wasting a lot of effort. A more cost conscious way is to have smaller teams and let them more time to explore better approaches for longer.
caminante 8mo ago
> And Unix was mainly made by two people Speaking of myths, they were part of a team of 4-5 early contributors with the benefit of network effects via Bell Labs.[0] [0] https://en.wikipedia.org/wiki/Unix#History https://en.wikipedia.org/wiki/Unix#History
- FieryTransition 8mo ago
  Thanks, I learned something, but the original point stands, 5 people is still not a lot and well within the scale where you could manage things within the team yourself without dedicated management and have first hand information flow.

And Unix was mainly made by two people, it's astounding that as I get older, even tech managers don't know "the mythical man month", and how software production generally scales.

thunky 8mo ago

Sorry but 99.999% of developers could not have built Unix. Or Winamp. Managers are crossing their fingers that devs they hire are no worse than average, and average isn't very good.

sdf2erf 8mo ago
Thats because the distribution of developer quality and capability is skewed.
eqvinox 8mo ago
> Sorry but a 99.999% of developers could not have built Unix. Or Winamp. > Managers are crossing their fingers that devs they hire are no worse than average, and average isn't very good. The problem is that that's the same skill required to safely use AI tools. You need to essentially audit its output, ensure that you have a sensible and consistent design (either supplied as input or created by the AI itself), and 'refine' the prompts as needed. AI does not make poor engineers produce better code. It does make poor engineers produce better-looking code, which is incredibly dangerous. But ultimately, considering the amount of code written by average engineers out there, it actually makes perfect sense for AI to be an average engineer — after all, that's the bulk of what it was trained on! Luckily, there's some selection effect there since good work propagates more, but that's a limited bias at best.
- thunky 8mo ago
  Agree completely. Where I'm optimistic about AI is that it can also help identify poorly written code (even it's own code), and it can help rewrite it to be better quality. Average developers can't do this part. From what I've found it's very easy to ask the AI to look at code and suggest how to make the code maintainable (look for SRP violations, etc, etc). And it will go to work. Which means that we can already build this "quality" into the initial output via agent workflows.
gamblor956 8mo ago
Not today's programmers, no. The side effect of a massively increased programmer labor population is that the average skill of the group plummeted. But back then? Most programmers would not have tried but a substantial portion would have been able to if they did.

MyHonestOpinon 8mo ago

I do agree with this idea in the sense that companies keep trying to add people to projects to do more things or complete projects sooner which ends up wasting a lot of effort. A more cost conscious way is to have smaller teams and let them more time to explore better approaches for longer.

caminante 8mo ago

> And Unix was mainly made by two people Speaking of myths, they were part of a team of 4-5 early contributors with the benefit of network effects via Bell Labs.[0] [0] https://en.wikipedia.org/wiki/Unix#History https://en.wikipedia.org/wiki/Unix#History

FieryTransition 8mo ago
Thanks, I learned something, but the original point stands, 5 people is still not a lot and well within the scale where you could manage things within the team yourself without dedicated management and have first hand information flow.