Hacker News Reader

Comment by impulser_ | Hacker News Reader

My theory is the majority of the bad tech decisions made at these companies is mostly due to the high turnover rate of employees in these company.

The average tenure of a software engineer/developer is just 2 years.

People come and go and the next thing you know you're using 6 different database with services written in 5 different languages.

Instead if you kept the same 6 engineers around for decades you could probably scale to 100m with those same engineers.

It one of the reasons why it seems like Google can never release a product. They can't keep people around long enough to see it through.

View on HN

The best teams I have worked with have been tightly knit for years. I had a tenure as a consultant for a team I knew quite well and those guys, around 7 or 8, had been together for perhaps 10 years.

They knew eachother so well and of course a side effect from that was that they produced absolutely astonishing things.

I was fended by these guys and the level of tooling set up for me not to fuck up, and their reviews, test strategies etc. was lean, direct and nutured by every single individual. They had built these skills as a team through years of hardship. It was quiet a Ln experience to be honest.

So yes, I totally agree with you on that people are what matters most and being in an organisation which hands down are backing it.

What is meant by “Ln experience” ?

logarithmic?

learning?

Sorry. "An" not "Ln". Updates for trying though :)

Google has longer tenure.

The thing you seem to miss are the other common denominator.

Huge amount of money and unreasonably far into the future expectations of returns.

Means there is no short to medium term pressure to optimise for efficiency or returns, which means one of the fundamental element of good engineering environment is missing.

These companies build in a vacuum of limitations in term of cost and a vacuum in term of goals.

The average tenure at Google has been widely reported for while now as roughly one year.

https://stackoverflow.blog/2022/04/19/whats-the-average-tenu...

s/average/median/g according to the linked source(cnbc)

When you have an average that low (or far away from the median) you by definition have a extremely large number of 1 year or lower tenures.

The floor is 0. You can't have a negative tenure at a company.

What I meant to point out is that Stackoverflow quotes the source CNBC wrong (primary source linked to by CNBC is no longer available). It is the median that is that low. The average might be higher or lower than that number.

That explains why working for Google seems so common. Hmm interesting, that explains a lot about why former Google developers are shit employees.

because they were in a massive hiring spree at that time, if you hire 10s of thousands of people in a single year it's going to drive down your average tenure

> My theory is the majority of the bad tech decisions made at these companies is mostly due to the high turnover rate of employees in these company.

I think your theory is less theory and more fact.

Another problem is that engineers will use a new tech project at work as an opportunity to use a new, hot technology that you can then put on the resume for your next job. That's when you see over-complication.

How do I know this? Bc I have done it - I am part of the problem. I do not want to, but the job market is competitive and I know my employer will never counter an offer I get from a new company.

A lot of this would be solved if companies would try hard to keep their engineers. I would not have made some of the decisions I have made if I knew that I would have to maintain my own garbage. I do try to write good design docs and code comments at least.

I think people just respond to incentives.

Engineers get promoted for creating complex architecture. I explicitly remember my manager asking me in my yearly review for promotion "what is so hard about that" .

Managers get promoted for hiring more people to support the said complex systems.

Charles Munger has wrote some very wise words on this. I cannot recall the title but you will find it interesting if you look it up.

How can I look it up?

Just ask ChatGPT. I'm sure we'll get exactly what OP was thinking.

It's called the Psychology of Human Misjudgement https://fs.blog/great-talks/psychology-human-misjudgment/

Part of it is how many of these companies handle performance. If you're more likely to get a good rating by building a complex system, you might as well do it and take the money.

WhatsApp scaled this way. -500m daily users with only -30 total engineers across 5 devices + backend.

Depends on the company culture, I have mostly worked in companies where there are company wide regulations on what technologies to use, exceptions for when customers require otherwise.

So it is possible to avoid this, regardless of employees turnover.

Instead if you kept the same 6 engineers around for decades you could probably scale to 100m with those same engineers.

I doubt it. Effort does not scale linearly with user scale, in my experience, primarily because features don't. This means that horizontal scalability is insufficient to go from 10M to 100M. And that means that more complex systems are required to support it--I can easily see a team of 6 very experienced engineers with deep domain knowledge of the application becoming overwhelmed as that scale change occurs.

It’s poor leadership whichever way you slice it. Even with turnover you could implement a culture that prevents this garbage inconsistent architecture but leaders seem eager to trade away any culture for “scale” and “psychological safety” basically so that dont have to be the ones saying “no” to someone. Hey, it works as long as you dont ever have to make money, yeah about that…

> Instead if you kept the same 6 engineers around for decades you could probably scale to 100m with those same engineers.

Scaling to 100m users is more about your users/product than your engineering IMHO.

If your product doesn't appeal to 100m users, you can't scale that high. It's not necessary to be ready for usage that's unrealistically high. And your team won't develop experience scaling if it's not happening.

Mega scaling gets more approachable all the time. Ebay had to shard their databases pretty early, because what they could fit on the biggest Sun machine to run Oracle they could buy isn't much. Now you can run a dual socket Epyc and get 256 cores with terrabytes of memory and petabytes of storage in one system. Might not be the best way to run your database, but if your queries aren't super awful, you can do a ton of queries per second with that much ram.

The discussion is implicitly based on the assumption that the product can attract 100M users and the engineering challenges arise from that

Reply on news.ycombinator.com