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

181–190 of 344 posts

Re: A former Uber engineer's disaster story

#181

Post by ericjang »

gregdoesit wrote: post #93
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…

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…

Interesting. I assume other multinational apps run into this problem as well. Is Apple considering support for apps with country-dependent payloads in the future? Otherwise seems like a lot of bloat across all major apps.

Re: A former Uber engineer's disaster story

#182

Post by bhupy »

lightroast123 wrote: post #176
gregdoesit wrote: post #93

Earlier quoted context omitted.

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…

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

Re: A former Uber engineer's disaster story

#184

Post by coldcode »

scoutt wrote: post #47
coldcode wrote: post #39

Earlier quoted context omitted.

When you write code like shit, the language doesn't matter. What Uber did was write a monstrosity with too many engineers and too many features without considering that was beyond their ability to deliver reliably. The product decision making was also clearly deficient and didn't help. Rewriting is neither a panacea nor a problem if you completely understand what you started with and what you will wind up with and be…

It can be quality code written by good engineers, but there are issues you won't see until you deal with big numbers. The problem here is that Swift seemed to be a cool language that it might work for a "Hello world" app. You won't notice any problem until the thing grows up to a certain point. For example, I work in embedded and I am proposed with a new "X brand" Chinese Modem to integrate in our devices. I don't re…

We started with Swift 2.X as well but it became Swift 3 before we shipped anything; Swift 5.X now is much more mature and we have no issues. Trying to do too much with a new language plus all the other things was asking for trouble.

Re: A former Uber engineer's disaster story

#185

Post by pfortuny »

mcguire wrote: post #137
didip wrote: post #126

Earlier quoted context omitted.

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.…

Isn't all of that server-side?

Not as per the long twitter thread.

Re: A former Uber engineer's disaster story

#186

Post by pandanomic »

Apocryphon wrote: post #171
carapace wrote: post #110

I started to write a whole big thing here because I found this whole thing pretty disgusting but it's not worth it. > I had privately had the “we need to stop” conversation with my director. He told me that if this project fails he might as well pack his bags. The same was true for his boss all the way up to the VP. There was no way out. > With only a week left we decided eat the 8 figures and drop support for iOS 8.…

One wonders if this is common everywhere at this scale. Take Facebook's massively bloated iOS app: https://www.reddit.com/r/iOSProgramming/comments/6upeu6/how_... https://news.ycombinator.com/item?id=14903228 And their Android app patching Dalvik at runtime to deal with the huge number of Java methods: https://www.facebook.com/notes/facebook-engineering/under-th... And they're not the only ones known for bloated apps…

Misinformed take. Android natively supports what facebook did back then, because almost every app hits the dex limit.

Re: A former Uber engineer's disaster story

#188

Post by lhorie »

saagarjha wrote: post #164
lhorie wrote: post #152

Earlier quoted context omitted.

Eh. It doesn't seem particularly relevant to bring up Linux, with its hundreds of thousands of person-hours worth of volunteer contributions and an extremely technically focused BDFL gatekeeper. It's a relatively well known fact that multi-team corporate projects have tech debt. There was a thread recently about Google Cloud being slow due to too-many-cooks-in-the-kitchen syndrome, and many ex-amazon folks say AWS UI…

I mean, Uber has had a huge number of people working on it too, with the incentive that they are paid to do a good job. Regardless of the eventual outcome, I have no misconceptions that Uber doesn't have some engineers who are extraordinary talented. And, the project is newer, too, with fewer guarantees on stability and fewer users to boot. I think it's a valid comparison to make at least–they are both huge, complex…

To be clear, I do think you have a valid point about e.g. unused assets and loading big libs to do trivial things, but IMHO, that's really a commentary on software development at large, rather than anything specific to Uber.

And there are cases, even in the Uber app, where thought has been put into optimizing both for upfront download size and internal complexity (the legal pages, for example)

Something that is worth considering is that a lot of what was said about the app being complicated is that it is also _dynamically_ complicated. For example, in the driver app, a feature was added to ensure drivers are wearing face coverings. The backend for that does AI-based fraud detection to prevent shenanigans like photos of photos. The picture upload flow is just one small part of a much more complex project that had to be rushed out because the covid pandemic happened. There are a bunch of similarly large impact things that touch several of the Uber apps simultaneously, often in non trivial ways and with tight timelines (e.g. features for compliance with specific legal requirements)

The reason I think Linux seems like a bad comparison is that if Linux contributors don't want to support some random driver for 3 years, that might be annoying but is generally just the way it is. Uber can't really afford to not do some of the complicated things it does in a timely manner.

Re: A former Uber engineer's disaster story

#189

Post by Apocryphon »

pandanomic wrote: post #186
Apocryphon wrote: post #171

Earlier quoted context omitted.

One wonders if this is common everywhere at this scale. Take Facebook's massively bloated iOS app: https://www.reddit.com/r/iOSProgramming/comments/6upeu6/how_... https://news.ycombinator.com/item?id=14903228 And their Android app patching Dalvik at runtime to deal with the huge number of Java methods: https://www.facebook.com/notes/facebook-engineering/under-th... And they're not the only ones known for bloated apps…

Misinformed take. Android natively supports what facebook did back then, because almost every app hits the dex limit.

Not an Android dev, just going off of how the FB comments there and elsewhere have responded to that article.

Re: A former Uber engineer's disaster story

#190

Post by Apocryphon »

pavlov wrote: post #151
saagarjha wrote: post #98

Earlier quoted context omitted.

"Botched introduction, really? Perhaps Apple could have been a bit more upfront about the state of the tooling (which, of course, they never will be) but I think they did a rather good job considering that they moved development out from "total secrecy" to "community-involved" within two years, all the while shipping new features and improvements to the experience at a fairly decent pace.

> “which, of course, they never will be” That’s the problem. Apple knows by now that their developer community laps up absolutely everything they put out and regularly gets burned. (I’m old enough to have rewritten code for Cocoa Bindings in 2004. It’s the next big thing! And garbage collection in 2008. It will fix everything! And GCD... and...) For such an enormous change as Swift, they should have switched off the…

What's wrong with GCD?
Post reply on HN