[jdminhbg]

> How can us commenters on HackerNews sit from our armchair and say "ah, goofballs should've just not let headcount get so high!"

The cliche HN comment on sites like Twitter (and many, many others, any time headcount comes up) has always been "why do they need so many people?" I've mostly dismissed it the same way I dismiss "I could build Uber in a weekend," but with every other tech giant laying people off, maybe I shouldn't. Maybe the effect of all that extra money sloshing around in the system was to incentivize hiring everyone to make sure you didn't accidentally get a false negative, and not all of those hires were good ones.

[jiggawatts]

A friend of mine used to work for a private equity firm that had about a hundred C++ and Java developers working on a stock trading and prediction system. He quit and rewrote the essence of that system in F# single-handedly.

If you watch interviews with famous developers like John Carmack, they'll mention that working alone scales to about the equivalent of 5x developers. That is, adding 1-3 extra people might slow you down because of the overheads of communication and coordination. It's only around 5+ in a team that there is a definite advantage.

But what are the chances of putting together a team of 5 rockstar developers that all agree on language, style, and vision? Basically zero. So you have to settle for mediocrity. Popular languages, simple approaches, established design patterns.

If you're an experienced "rockstar" developer coding by yourself and use a fancy language like F#, you can outperform a team of 10+ people. If you're replicating a system you've seen already, 20-50 might not be out of the question, especially if you're smart enough to avoid "tarpits" and instead rely on good quality libraries and CotS components like databases, PaaS, and the like.

[abakker]

I think this is not too far wrong. I also think in addition that the really competitive job market of the last 2 years and the hiring they were doing inevitably resulted in some highly paid people who were not good fits or good at their jobs. I think that covid wage hikes and job competitiveness is doing a bit of reckoning now as there is finally enough data to evaluate performance relative to output.

OTOH, at non tech companies, all the research interviews and surveys I have done recently continue to show a talent shortage and fears of losing tech staff, so maybe it is just that Tech companies are saturated and have too much capital for their creativity.

[jdminhbg]

I'm not doing interviews or surveys, but this also matches with my anecdotal experience with non-"tech" companies, who are all still starving for talent. I guess it makes sense, given that tech companies disproportionately pay in stock and tech companies were disproportionately highly-valued during the 2020-22 Covid weirdness.

[ShredKazoo]

>OTOH, at non tech companies, all the research interviews and surveys I have done recently continue to show a talent shortage and fears of losing tech staff

I wonder if any science fiction writer could have predicted silliness like Snapchat having fewer outages than serious government websites because Snapchat is better at hiring engineers. Tech hiring is so bizarre.

[namdnay]

The problem with having a lot of money sloshing around is that you can no longer say “no”. You estimate a new feature will take your team a year. But someone wants it in 6 months. “Why aren’t you hiring to meet the deadline?”

[randomsearch]

My first job out of Uni was a company that ran financial services, logistic fulfilment, and retail. They had at least a dozen large in-house retail brands, several large warehouses with automation that Amazon was probably behind at the time, and they also ran serviced some of the most well known brands in the country - from their website to customer support to logistics. They had delivery networks, networks of direct shipping, vast call centres with thousands of staff. We integrated with the banking system, with all sorts of external companies.

Our total headcount was under 10 000. Most of that was logistics and call centres (taking retail orders). Our IT dept was literally about 200 ish. All our office staff fit within a few floors of a medium sized building. IT was less than a single floor.

I’d say our software, whilst serving fewer users, was completing tasks orders of magnitude more complex than Twitter. We didn’t have much down time, in fact almost zero beyond physical damage to our networks and the once every few years disaster. Our critical support team was a handful of greybeards who spent much of the time playing solitaire. Code reviews were tight and access to production strictly controlled.

What we did have was a very lean culture, carefully managed over a long time. The company was over 100 years old.

I do not understand how, with far more sophisticated tech, companies like Twitter need so many staff. We could have run Twitter with a thousand folks, including sales. From an engineering standpoint a few hundred would do. And most of us weren’t great engineers. There were a few very experienced freelancers, though. We all worked 0900-1730, but we worked 7 full hours every single day, every minute of those 7 hours. No beanbags. Most of that time was sat quietly coding in a very cleverly designed open plan office (no cubicles) that was like a library.

Looking back, I think the key insight was that we were very cost driven and absolutely kept everything as simple as possible. We had all the usual project overrun problems, usually because things turned out to be more complex than previously imagined. But it baffles me when I hear engineering head count at places like Twitter. If you had given us 1000 engineers, we wouldn’t have known what to do with them.

[treis]

It is amazing how quickly complexity comes about to serve complexity. Like at $CURRENT_JOB we split everything into a few dozen microservices with their own DBs. Turns out that we need all the data in one place to make some decisions. Shocking I know.

Cue a team of engineers working for a year+ to build a complicated data pipeline to bring all that data back together into a graph DB (not a clue why a graph DB) and build a DSL to write the code to make these decisions.

That's where the engineers go. It's complexity that is introduced setting off a chain reaction of increased complexity to account for the complexity introduced. Then you need complexity to account for that complexity and so on.

Not that it's all self inflicted wounds. Running a site that counts 1/10 of humanity as active users is a hard thing to do