Comment by agentultra

> they’re often put to work making the boxes more blue or sitting in meetings with PMs for hours

Haha, this is exactly my experience.

I'll never forget the best candidate I ever interviewed - my feedback was to absolutely hire him and put him on the most interesting and challenging problems. They put him in a marketing team tweaking upsell popups. He left after 2 months.

> If you’ve never read Fred Brooks, I’d recommend it. The aphorism is a bit dated but rings true: you can’t add another developer and make the process go faster.

He didn’t say that. He said adding developers to a late project makes it slower, explained why, and even added some charts to illustrate it. The distinction matters.

By your interpretation, no company should have more than a few developers, which is obviously false. You can argue team organization, but that’s not what Brooks was saying, either.

On top of that, parent never said he hired 40 devs for one project at one time. He was talking in general terms, over the course of years, perhaps in multiple companies.

Finally, let me invoke another aphorism: hours of planning can save you weeks of development. Right here you have the bottleneck staring you into the face.

Of course it’s development. And unless you’re in a really dysfunctional environment, most of that development is coding, testing and debugging, where AI can help a lot.

> The aphorism is a bit dated but rings true: you can’t add another developer and make the process go faster. It usually slows teams down.

I've been doing this for 30-years and this is another political slogan of sorts. this is true in every single imaginable job - new people slow you down, until they do not and become part of the well-oiled machine that is hopefully your team. not sure why people insist on saying this, it is like saying "read this book, says that that Sun will rise tomorrow morning"

> I’ve seen it time and again: startups move from their market-fit phase into an operational excellence phase on the backing of VC funding and they start hiring a ton of people. Most of those developers are highly educated, specialized people with deep technical skills and they’re often put to work making the boxes more blue or sitting in meetings with PMs for hours. Teams slow down output when you add more people.

I wasn't talking about startups or developers making boxes more blue, I was talking about personal experience. The bottleneck, if you are doing amazing shit and not burning some billionaries money on some silly "startup" is always the code which is why we hire developers to write the code. Everything else is just coming up with some silly unrelated examples - of course there are people (at every job again) doing nothing or menial tasks - this isn't what I was talking about.

> You don’t have a quota. It’s not like you’ll have fewer units to sell if you don’t add that 30k lines of code by Friday.

I do have customers that want features that would make their lives easier and are willing to handsomely pay for it, that good enough?

> This is knowledge work. The work is understanding problems and knowing how to develop solutions to them. You add more people and you end up adding overhead. Communication, co-ordination, operations overhead.

This is only on super shitty teams with super shitty co-workers (especially senior ones) and super shitty managers. I feel for the careers in this industry where this is/was the case. A whole lot of people are terrible at their jobs in places like this - a whole lot of people...

> A well-sized team that has worked together a long time can outperform a massive team any day in my experience.

a well-sized team was at one point (well-sized team - 1) and (well-sized team - 2) and (well-sized team - 3) and in the future if it is right team will be even more amazing as well (well-sized team + 1), (well-sized team + 2)