531–540 of 689 posts
Developers at unicorns: even in the best of times, do you feel more expendable than you've felt at other jobs? We always are amazed at the number of developers at companies like this. (the numbers I've seen are old, but I guess out of 22,000 employees, it was something like 5000 engineers?) While that allows you to build in a more robust way than a smaller company, it seems like there's no shortage of developers work…
Developers at unicorns: even in the best of times, do you feel more expendable than you've felt at other jobs? We always are amazed at the number of developers at companies like this. (the numbers I've seen are old, but I guess out of 22,000 employees, it was something like 5000 engineers?) While that allows you to build in a more robust way than a smaller company, it seems like there's no shortage of developers work…
I'm at Airbnb (opinions strictly are my own). The number of engineers working on tooling for us is actually not that large. The vast, vast majority are product engineers and with our most recent layoffs the majority of the cuts were for those types of engineers. My own opinion is that we simply had way too many product engineers for the amount of actual output we got from them. Uber is on another different plane alto…
These are complete guesses for the pre-covid era, but it gives an idea of scale difference. The average Airbnb user probably books 2-3 times per year. The average Uber user probably books 2-3 rides per week. At 50x the volume, the infrastructure is different, and probably more complicated to handle the volume.
Earlier quoted context omitted.
I've never worked for a true unicorn but I've been in companies that got a sudden success and grew way too big way too fast. I think you can tell from the inside when a company loses its way. As you mention, suddenly you have tons of teams working on what seems to be fairly niche aspects of the company's product. You have man-years worth of work going nowhere as projects get scrapped mid-development. You start having…
>suddenly you have tons of teams working on what seems to be fairly niche aspects of the company's product At scale it tends to be worthwhile, even necessary, to engage fully with the complexity of all those "niche" aspects. When you don't understand how something could possibly take so much effort, it's possible all the people working on it are idiots and you could do it better in a weekend. (When you spot situation…
When large companies have such excess engineering power to blow, they tend to say yes to all requirements and scope creep takes over everything. So no, the engineers building the abstract framework factory are not stupid, but they should have just built the report dashboard instead of the tool to generate tool generators.
Earlier quoted context omitted.
"I had to make this decision because our very future as an essential service for the cities of the world — our being there for millions of people and businesses who rely on us — demands it." This is only one sentence in an otherwise fairly measured email, but it nevertheless annoyed me given the context. Uber is not an "essential service". They made this decision so that they can stay in business to make money for th…
You are thinking of only US and similar countries where everyone already owns cars. In country like India, there were not much taxis before Uber came. An alternative was autorickshaw which took twice as long to go the same distance, had much worse safety features, exposed one to all the pollution all the time, not to mention the cheating of fares.
She doesnt drive following a car wreck. She had walk half a mile to wait out in the bitter rocky mountain cold at a bus stop to go to the Dr. Shes on social security. She told me she didnt have the money to take a cab, that is if she could even get a hold of one.
Then uber came along.
She learn to use uber on her own before even whatsapp.
Yea, I'd call it downright essential.
Developers at unicorns: even in the best of times, do you feel more expendable than you've felt at other jobs? We always are amazed at the number of developers at companies like this. (the numbers I've seen are old, but I guess out of 22,000 employees, it was something like 5000 engineers?) While that allows you to build in a more robust way than a smaller company, it seems like there's no shortage of developers work…
Oh, you might be surprised how many people are not working on anything of consequence. Some of these companies don't even do much in the way of building stuff outside of the product teams, and even then, they frequently fizzle after some point. You know the line "don't mistake motion for progress"? There's a whole lot of motion up in those SoMa offices... but very little progress. Some of these teams are very good at…
As the userbase scales, infrastructure scales, and what was once a simple "ALTER TABLE" is now a system with a team managing it because a single Postgres instance didn't scale.
As the engineering headcount scales, code changes, builds, even understanding the system become slower. You overcome that with better engineering, but mostly more engineers.
As the product matures, there's still a drive for growth, but the low-hanging product fruit has been picked, so you get lots of product teams trying to either optimize their little part because, at scale, it makes a big difference, or product teams working on new, crazy ideas--the startup within a unicorn-startup--that will most likely fail.
Developers at unicorns: even in the best of times, do you feel more expendable than you've felt at other jobs? We always are amazed at the number of developers at companies like this. (the numbers I've seen are old, but I guess out of 22,000 employees, it was something like 5000 engineers?) While that allows you to build in a more robust way than a smaller company, it seems like there's no shortage of developers work…
Earlier quoted context omitted.
>> You have man-years worth of work going nowhere as projects get scrapped mid-development. That's better than seeing man-years go into features that get deployed. I witnessed one successful control system company spin up a team of new hotshot UI engineers, all right out of the best schools. After months of work the team "updated" the product. Withing hours the call center was hit with hundreds of "You changed the g-…
[flagged]
Hard to let go of that many people without losing critical knowledge, Uber will come out of this a diminished company in many ways. Best of luck to those laid off.
Earlier quoted context omitted.
Why not go with "work-years"? It has the benefit of being gender neutral and even more relevant.
Seems to imply a different amount of time. Work year would be the amount of time worked in a year (usually ~2000 hours give or take). Sort of like how a work-day is 8 hours rather than 24. Man/woman/person/dev/etc-year seem to imply an amount of work that is equivalent to a year (~8760 hours). Or at least that's how I would use those terms. It's entirely possible that these definitions are regional in nature.