Live data from Hacker News

A former Uber engineer's disaster story

twitter.com

271–280 of 344 posts

Re: A former Uber engineer's disaster story

#271

Earlier quoted context omitted.

Would you want to download a different app every time you traveled to a new country? If you're in the EU/APAC with many countries close together and travel for business? Uber works relatively well in every country you go to, including at one point, China. Not many apps have ever accomplished that.

I wouldn’t mind if the app started up and said, “download the $country_or_region extension,” but that is just me (assuming it doesn’t require re-creating an account, or re-entering billing details).

Get off the plane in a developing country. Some of those airports are not nice. Some of them are nice shells that are almost deserted, with no wifi and a couple vendors that won't take your American credit card. Your "World Plan" often works, sorta, but you can't always get data due to different radio bands or because the network is simply not good enough for a 100+mb download. You'll either have to hop into a hopefully licensed taxi, or start walking in the dark in an industrial area (where airports usually are) in order to find a wifi hotspot or a street vendor that will sell you a SIM card. It's not fun.

Uber made the right choice.

Re: A former Uber engineer's disaster story

#272
post #214

Earlier quoted context omitted.

It seems a little strange to criticize someone for asking a question on a site where most users seem to value curiosity. Not everyone has a background that makes it as easy to imagine problems like these, and while you've given some possibilities, I would also be interested in knowing exactly what accounts for the size.

There are far better ways to ask the question than “What does the app even do, just seems like a map with a few dots” which has a heavy implication on the quality of the team that built it..

You may be reading in to it too much. A lot of people would be surprised that Uber is as large as 30 SNES games.

Re: A former Uber engineer's disaster story

#273
post #108

Earlier quoted context omitted.

There are a lot of ways to frame these problems as interesting algorithms but it doesn't really strike me as something that is troubled by scale. I've worked on similar problems where "everything is a special case" in some vein and it takes a few very clever minds to construct the algorithms and datastructures that can come to a good solution. But that's just it, it's the work of a few engineers and not thousands wri…

A good place to start would be to go through the Uber UI and click through every button and every page that exists. Now create a driver profile and do the same thing. Now create the multitude of other special profiles they have and do the same. Now do the same for Uber Eats. Now do the same for Eats but using the restaurants version of the app. And the couriers. Now get in on Uber Freight (and any other projects they…

100mb is an insane size for the executable of an app. You are listing business logic, I mean we all deal with complex bus logic - but only the lucky few get it to 100mb of executable.

Re: A former Uber engineer's disaster story

#274

"Without manual pickup location entry people’s location would just show up as whatever the GPS location was last received. This can be very inaccurate (especially in cities with tall buildings) and drivers would end up on the wrong block. This was a horrible customer experience. So to improve location pickup we changed the location permission to collect signal in the background so we could send the drivers to your cu…

Sounds like a type of kalman filter on the location. Any given reading is likely crap, but combined, you can get fairly accurate.

So, the idea is probably too keep a decent sized history of readings so that your could just add the current to that.

Re: A former Uber engineer's disaster story

#275
post #4

Apple's botched introduction of Swift is easily responsible for billions of dollars in lost productivity across the industry since 2014.

This assumes a major counter factual where all of the same work was somehow more productive otherwise. Seems dubious.

Re: A former Uber engineer's disaster story

#276
post #79
post #6

The biggest engineering disaster Uber had was when it intentionally disabled the automatic safety brakes on their 'self driving' car and killed a person.

I was working at Uber ATG when Elaine Herzberg was killed. They kept the details secret from the other employees, citing fears of "too many cooks". I recall being offered grief counseling. Uber disabled Volvo's automatic emergency braking system, which probably would have saved Elaine, to develop their system on public streets. I left the company and took a pay cut to work on ethical robotics instead. https://www.was…

Whoa. They disabled Volvo safety system. That’s nuts. My Toyota 2016 Rav has saved me a couple of times with the auto brakes and loud beeps. It was totally worth the 2k extra for the 7 radars and 6 cameras.

I don’t care about L4 self driving. I really care about a car that is resilient to human mistakes and fatigue. Uber failed at that.

Re: A former Uber engineer's disaster story

#277
post #148

Earlier quoted context omitted.

Uber actually has a not-so-well-known product for this very problem: the mobile web version (m.uber.com) It doesn't have nearly as much functionality as gregdoesit mentioned, but it's enough to service the use case of getting you from point A to point B when you're stuck w/ crappy connectivity.

Wish they still had what they did when I started using it: send an SMS to a shortcode number with your pickup location.

I actually built this product out (for both Uber and Lyft) - SMS/MMS-based ride requests (MMS only for sending google maps PNGs to confirm pickup location). I was about to convert it from a personal project (I used it to get rides on both services for a few years) to a "real" one open to customers, etc and then ran into snags with both APIs at around the same time. Uber's API changed to potentially require a web flow to confirm surge pricing (IIRC - now it's scheduled to be disabled entirely very soon) and Lyft's API was basically shut off entirely (there's a way to apply but I was unable to make any progress even through internal contacts at Lyft). I'll try and keep an eye out for any changes...

Re: A former Uber engineer's disaster story

#279

Earlier quoted context omitted.

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…

That's why I call idioms idiots. If you have to learn idioms, it's an idiotic thing.

There is no language where full expression is possible without use of idioms that don't have direct translations in every other language.

Re: A former Uber engineer's disaster story

#280

I was part of the team in Amsterdam on this. Insane days. Had some great engineers we hired in AMS. We were moving the whole source code into a monorepo as well which was another crazy project. I think if we had not had some of the engineers we did at those exact times, we would have not gotten out of it. Problem here with Swift came down to - Apple not dogfooding its own tech . Hell they did not even help us or othe…

I was an iOS engineer at Airbnb when we were battling binary size increases caused by Swift. I rewrote the watch app twice; once to migrate to watchOS 2 and once to convert it all to ObjC (which saved ~9mb). While Swift does have its problems (and had a lot more back when we worked on this), there are many factors to why the Uber app (and Airbnb) is getting so large. Airbnb is 75% executables, 9.5% assets and 8% loca…

How do you know all these facts about the Uber app? Can you inspect the binary?
Post reply on HN