[csande17]

> It was the norm for a single programmer to be doing the work that would normally be a team (sometimes multiple teams).

One thing that surprised me when I entered the professional world was just how much this is seen as a downside. At almost every level, companies will choose technologies and techniques that allow them to hire more headcount, even if that results in a worse end product.

Many startups value the appearance of having a large actively-hiring engineering team, and many BigCo middle managers want lots of direct reports. They don't usually care how much work gets done per employee, and sometimes they don't even care about the total amount of work that gets done across the organization. It's all about getting warm bodies into seats, either to impress investors or to gain status within the organization.

[Karrot_Kream]

Bus factor. What happens if the knowledgeable lead developer gets into an accident? What happens if they retire? More realistically, what happens when they burn out because it's so hard to hire other team members and so they can never really take a vacation and have to take their pager everywhere with them? That's why businesses optimize for headcount.

[p_l]

I have yet to encounter positive solutions to those questions, as usually increasing headcount does not relieve pressure on team members - it's used to enable quicker replacement by yet-another-junior-to-burned-at-the-altar who will leave after gaining experience and burning out.

The classic "we have niche languages" solution to that is to enable on-the-job learning of those, and not just doing simple fact checking on whether someone honestly claimed to have learnt Popular Language X as claimed on their CV.

[inopinatus]

Incompetent managers certainly believe they're hedging for bus factor by increasing headcount.

In practice, it doesn't work. For any given product there's still always a small/solo core team.

Don't optimise your business for mediocrity.

[Zababa]

There's probably a link to monolith and distributed systems here. You gain way more resiliance when you get more people in your team, but what was once a thought firing in the brain of someone is now two people talking, which is order of magnitude slower. But on the flip side, you can probably handle more things in general this way.

[sigg3]

The interview sort of answers this:

> Because we operate a lot in Latin America, I trained non-lisper engineers who speak Spanish on how to program Lisp

So they grew their lisp heads from raw human. That's not an overhead most companies would readily accept.

[svetlyak40wt]

I think here he is talking about "integrators" - engineers who write in DLisp rules to process documents.

[hcarvalhoalves]

Hiring thousands of developers is a success metric now.

[Jtsummers]

Management is still one of the fastest ways to a high paying job. Managers get rewarded (implicitly or explicitly) for being in charge of more people, either with better pay in the same position or by appearing to be more competitive when going for promotions. This creates a perverse incentive where someone can make decisions which promote a higher headcount at the cost of actual capability or efficiency.

It's often not even deliberate. No one sits down and says, "This language or tool kit requires a higher headcount, so I'll select it for my project". But they aren't motivated to find a more efficient approach that results in them being put in charge of a smaller team (because this would cost them and not reward them).

EDIT: Some grammar things.

[cle]

It's also a way to hedge risks. If you've got a single programmer working on something, they're a single point of failure and they also have huge leverage (which can be good or bad depending on the person and circumstances).

Not that middle management bloat isn't a thing...it definitely is. But I don't think it's as black-and-white as it's made out here.