 |
| “Former Uber engineer/EM here: I worked on the Rider app.” (comment) | ||
| recommended by 8 users | 2020 | gregdoesit on: A former Uber engineer's disaster story | company culture | original thread | | ||
| gregdoesit on Dec 10, 2020 | on: A former Uber engineer's disaster story | view on HN | ||
| 8 users recommended this comment. What they said: |
|
dvdhsu Jan 24, 2021 | on: Uber, after buying Postmates, lays off more than 180… | context
This is one of my favorite comments on HN: https://news.ycombinator.com/item?id=25376346. It really changed my perspective on why Uber has so many software engineers. |
|
sida Dec 11, 2020 | on: Airbnb’s Stunning IPO | context
This comes up a lot (ohh it is a just a crud app and you just need a couple of people) This is fine and it is common misconception about how large app businesses work. (kudos to airbnb for making complex things look so simple) Here is a great post about Uber and why Uber gets complex (once you have many product lines across hundreds of cities, each with their own subtleties and rules/regulations) https://news.ycombinator.com/item?id=25376346 |
|
bhupy Feb 26, 2021 | on: How Uber Deals with Large iOS App Size | context
An old (but fantastic) comment from the previous discussion about Uber's app size that addresses why the Uber app is so big: https://news.ycombinator.com/item?id=25376346 |
|
lhorie Aug 24, 2021 | on: I could do that in a weekend (2016) | context
I don't see nearly as many people claiming Google could be built in a weekend, but I do see that sentiment a lot in threads about Uber. It's easy to think it's a simple app, but there was a great response from a former EM highlighting just why that isn't so[0]. > This reminds me of a common fallacy we see in unreliable systems, where people build the happy path with the idea that the happy path is the “real” work, and that error handling can be tacked on later. For reliable systems, error handling is more work than the happy path. Is there a name for this fallacy? I think this isn't merely a familiar anecdote, but something that points to the root of why armchair architects think things are easier than they actually are. |
|
philipkglass May 13, 2025 | on: FastVLM: Efficient vision encoding for vision language… | context
A lot of geography-specific scenarios are compiled into the app, including regional payment SDKs. There's a great comment from a former Uber engineer explaining it here: |
|
piva00 Sep 7, 2021 | on: “You don't need this overengineered goo for your project.” | context
I remember this post from gregdoesit [1] as a good example of how much complexity is hidden under seemingly trivial interfaces. It's about Uber's supposedly bloated app, I believe that anyone who has worked at a scale where they had to support different national legal systems in their code would know that maintaining a large-scale product is nothing trivial. |
|
jasode May 23, 2022 | on: How Uber Uses Zig | context
>I still find it hard to comprehend how a one of the tools of a taxi calling app has this much complexity and have thousands of engineers working on it . Fyi... have you already seen the famous Uber engineer comment on the complexity of the app? https://news.ycombinator.com/item?id=25376346 As a case study, the simpler non-profit RideAustin app fails customers even after Uber/Lyft left Austin: https://techcrunch.com/2017/03/12/austin-is-fine-without-ube... It takes a lot of money and engineer salaries to make high-demand apps that work. That's not to say Uber staffing isn't bloated; they may be. That doesn't change the fact that armchair observers may still drastically underestimate how many hundreds (or thousands) of programmers it requires to build something equivalent. |
|
jpalomaki Oct 22, 2023 | on: Uber migrates microservices to multi-cloud platform running… | context
There's an an interesting HN comment[1] from 2020 by former Uber engineer, which discusses the complexity a bit. It's more about UI, but the thread discusses the backend as well. In brief something that may look super simple for the user (like handling payments) is actually quite complicated when you cover all the market, different payment types etc. And all this carries to the backend as well. |
| Also recommended by people who recommended this: | ||
| 1. | “I have a few qualms with this app:” (comment) | |
| recommended by 325 users | 2007 | BrandonM on: My YC app: Dropbox - Throw away your USB drive | aged poorly | original thread | | ||
| 2. | Lichess on Scala3 – Help Needed (lichess.org) | |
| recommended by 1 user | 2022 | 2 points by dzogchen | original thread | | ||
| 3. | I Can’t Write My Name in Unicode (modelviewculture.com) | |
| recommended by 3 users | 2015 | 610 points by luu | original thread | | ||
| 4. | “I'm unlikely to write a book, but here are a few more tidbits that come to mind.” (comment) | |
| recommended by 3 users | 2018 | coffeemug on: Ask HN: What is the dark side of working at a successful… | original thread | | ||
| 5. | Mcmaster.com is the best e-commerce site I've ever used (bedelstein.com) | |
| recommended by 1 user | 2022 | 1402 points by runxel | original thread | | ||
Former Uber engineer/EM here: I worked on the Rider app.
The “there are only a few screens” is not true. The app works in 60+ countries, with features shipped in the app that often for a country, and - in rare cases - a city.
The app has thousands of scenarios. It speaks to good design that each user thinks the user is there to support their 5 use cases, not showing all the other use cases (that are often regional or just not relevant to the type if user - like business traveler use cases).
Uber builds and experiments with custom features all the time. An experimental screen built for London, UK would be part of the app. Multiply this by the 40-50 product teams building various features and experiments outside the core flows you are talking about (which core flows are slightly different per region as well).
I worked on payments, and this is what screens and components are in the Uber app:
- Credit cards (yes, this is only a a few screens)
- Apple Pay / Google Pay on respective platforms
- PayPal (SDK)
- Venmo (SDK)
- PayTM (15+ screens)
- Special screens for India credit cards and 2FA, EU credit cards and SCA, Brazil combo cards and custom logic
- Cash (several touch points)
- AMEX rewards and other credit card rewards (several screens)
- Uber credits & top-ups (several screens)
- UPI SDK (India)
- We used to have Campus Cards (10 screens), Airtel Money (5), Alipay (a few more), Google Wallet (a few) and I other payment methods I forget about. All with native screens. Still with me? This was just payments. The part where most people assume “oh, it’s just a credit card screen”. Or people in India assume “oh it’s just UPI and PayTM”. Or people in Mexico “oh, it’s just cash”. And so on.
Then you have other features that have their own business logic and similar depths behind the scenes when you need to make them work for 60 countries: - Airport pickup (lots of specific rules per region)
- Scheduled rides
- Commmuter card functionality
- Product types (there are SO many of these with special UI, from disabled vehicles, vans, mass transport in a few regions etc)
- Uber for Business (LOTS of touchpoints)
- On-trip experience business logic
- Pickup special cases
- Safety toolkit (have you seen it? Very neat features!)
- Receipts
- Custom fraud features for certain regions
- Customer support flows
- Regional business logic: growth features for the like of India, Brazil and other regions.
- Uber Eats touchpoints
- Uber Family
- Jump / Lime integrations (you can get bikes / scooters through the app)
- Transit functionality (seen it?)
- A bunch of others I won’t know about.
Much of the app “bloat” has to do with how business logic and screens need to be bundled in the binary, even if they are for another region. E.g. the UPI and PayTM SDKs were part of the app, despite only being used for India. Uber Transit was in a city or two when it launched, but it also shipped worldwide.
And then you have the binary size bloat with Swift that OP takes about.