Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

A former Uber engineer's disaster story

twitter.com

Post reply on HN
Print view View original

201–210 of 344 posts

Re: A former Uber engineer's disaster story

#201

Post by ForHackernews »

dntrkv wrote: post #194
lock-free wrote: post #192

Earlier quoted context omitted.

You should scratch below the surface because this isn't really explaining much - it does not sound like something that requires more than 100 people. Their legal team sounds like it should be twice that alone. Or am I crazy?

Take look at this thread: https://news.ycombinator.com/item?id=25376346 My point is that there is 100s of screens/features in the Uber app that you don't even know exist. And you have those same 100s of screens across their other apps. Multiplied across all of the different platforms. Plus any internal tools they use. I'm curious, have you worked at a software company of Uber's scale? Not trying to be a dick here, ge…

But like, why? Do all of these things make them tons of money? It's a dumb taxi app, ultimately.

You're not answering the question except as a tautology:

- Q: Why is Uber's engineering team so ridiculous and bloated?

- A: Because they need a ridiculous bloated team to make this ridiculous bloated app.

Re: A former Uber engineer's disaster story

#202

Post by entropicdrifter »

jonny_eh wrote: post #85
asimpletune wrote: post #51

Earlier quoted context omitted.

Yeah it’s kind of bizarre that after writing everything leading up to that, the author would still frame the ObjC folks in that way. Like, this or that eng. was so brilliant with their hack, but all those obj-c eng. who advocated boring but stable solutions all along were just curmudgeons with no helpful advice.

Sounded like a "both sides" analysis, where the assumption is that both sides in a disagreement must share blame.

The Middle Ground Fallacy

Re: A former Uber engineer's disaster story

#203

Post by ForHackernews »

renewiltord wrote: post #191
kingnothing wrote: post #172

Earlier quoted context omitted.

I also worked for Uber but on backend systems in the payments flow. Every single piece of app functionality mentioned above has at least one, if not multiple, backend systems and teams supporting it. Like in the app, "payments" sounds like it would be a simple Stripe integration but it isn't. For one, that's way too expensive at Uber's scale. They build their own payment integrations to save fractions of a point that…

It genuinely blows my mind anyone who has written software couldn't have guessed at all of this from the beginning. Uber PMs and engineers should be super proud. The fact that each user thinks that their one use-case is "all the app does" is fucking brilliant product design. I've had over a thousand Uber rides (used it to commute) in 10+ countries and it's obvious there the way it seamlessly adjusts to each region bu…

> The fact that each user thinks that their one use-case is "all the app does" is fucking brilliant product design.

Alternatively: The fact that they try to bundle all the world's use cases in some 100+ MB monstrosity of a client app is a tragicomic commentary on the misaligned incentives in the tech world's VC-driven wannabe-monopolies.

Re: A former Uber engineer's disaster story

#204

Post by andrewprock »

bobobob420 wrote: post #73

Posting stories as Twitter threads personally for me make me loose all respect for you as an engineer. I mean what in the hell is the abysmal way of reading? How could any person allow themselves to post something like this?

As with Swift vs. ObjC, this may be an instance of "fashion over function".

Re: A former Uber engineer's disaster story

#205

Post by sokoloff »

bhupy wrote: post #182
lightroast123 wrote: post #176

Earlier quoted context omitted.

thanks for sharing. I'm a former Uber engineer still reading in most Uber-related reddit threads how they could build the app in a weekend

There needs to be a game of Uber HN/Reddit thread BINGO. Squares include: * Uber being a simple CRUD app * Uber having no moat because it can easily be disrupted by those able to build the app over a weekend, because Uber is a simple CRUD app * Uber continuing to operate solely because VC's currently subsidize every single ride

* Medallion taxis being safer because they're more rigorously inspected.

Free space in the middle: drivers have no clue as to their costs and are only signing up because they're too naive to realize they're losing money.

Re: A former Uber engineer's disaster story

#206

Post by sixstringtheory »

microtherion wrote: post #56
nwsm wrote: post #28

Earlier quoted context omitted.

Appreciate your insight, and I'm sorry to hear about the AMS team. The OP indicates that a rewrite was necessary regardless. Even if Swift was not yet mature, do you think it was more worthwhile than rewriting in ObjC? Given that the goal was to "sustain mobile development at Uber for the next 5 years". Secondly, I'm not a mobile developer so I don't have much context, and I'm wondering about your outlook on iOS deve…

A complete rewrite of a large project is risky anyway. Doing so in a language in which literally no other project of that size exists yet strikes me as insane. I love Swift. But I've been adopting it in bits and pieces over the years. It's not just that the language has changed significantly, you also have to get used to the idioms. E.g. my early Swift code often featured Pyramid of Doom patterns, and both language i…

One thing I was surprised not to see was a mention of their Swift 2 to 3 migration, which was terrible in my experience working on apps that were nowhere near the complexity of Uber.

Apple should have never pushed Swift as hard as it did at the time. Between the constant API changes and issues like requiring dynamic framework linkage and copying the whole runtime into every app, it was absolutely not production ready.

Re: A former Uber engineer's disaster story

#208

Post by mewpmewp2 »

didip wrote: post #126
pjc50 wrote: post #60

This may be an egregious question, but what does the Uber app actually do that makes it so big? It displays a map with some moving dots on them, allows you to pick a location, and asks the server for a route and price. Plus a bit of workflow for signup, credit card, reviews; not a huge number of screens. I appreciate the difficulties of getting an app to fit in a fixed space having worked on a point of sale system th…

I have to say, this comment is quite ridiculous. Might as well say that Google is simple because it's just an app with one search field. I never work for Uber but I can easily imagine the following problems: * Map data is not a solved problem. Tons of inaccurate data especially on non-english speaking countries. * As someone mentioned about payments, different country requires different payment platform integrations.…

And how big is Google's web search bundle?

Most of what you mentioned should be server side.

Re: A former Uber engineer's disaster story

#209

Post by ufmace »

ForHackernews wrote: post #203
renewiltord wrote: post #191

Earlier quoted context omitted.

It genuinely blows my mind anyone who has written software couldn't have guessed at all of this from the beginning. Uber PMs and engineers should be super proud. The fact that each user thinks that their one use-case is "all the app does" is fucking brilliant product design. I've had over a thousand Uber rides (used it to commute) in 10+ countries and it's obvious there the way it seamlessly adjusts to each region bu…

> The fact that each user thinks that their one use-case is "all the app does" is fucking brilliant product design. Alternatively: The fact that they try to bundle all the world's use cases in some 100+ MB monstrosity of a client app is a tragicomic commentary on the misaligned incentives in the tech world's VC-driven wannabe-monopolies.

Anything else seems like an even bigger mess:

What happens when a user who travels unexpectedly discovers they need to download a new version of the app for where they are now? And what if they're on a low-bandwidth or capped cell plan and can't download a 100MB app easily, where 3/4 of the data is duplicates of stuff in their other 5 copies of the app?

What happens when a user tries to book an Uber from one area with a special app version to another area with a different special app version? This could easily generate tens of thousands of permutations.

What happens if the user is physically in one country right now, but is a national of another country and wants to pay for their Uber in their usual currency and payment method?

If the user ends up needing to have 20 copies of the app for various locations, how well will they sync ride history, changes in payment methods, and other such info?

I don't even work for Uber, and I thought of all of these complications in 10 minutes. The real Uber probably has 100x more complications that would arise from splitting location-specific functionality into location-specific apps.

Re: A former Uber engineer's disaster story

#210

Post by sixstringtheory »

11thEarlOfMar wrote: post #69

I'm reminded of the story of Windows NT and how David Cutler commented at one point after the release that divorces and nervous breakdowns were tracked in the program metrics. I expect that's hyperbole, but there is a real cost to these death marches. I couldn't find that specific quote, though, and being 25 years back it could be a false memory of who said it (I did read it somewhere, if you were on the team at the…

I believe it. During my last stretch of unemployment I started tracking the days I couldn't get out of bed in my spreadsheets.
Post reply on HN