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

141–150 of 344 posts

Re: A former Uber engineer's disaster story

#141

Post by jimbob45 »

cellularmitosis wrote: post #115
jimbob45 wrote: post #53

Seems like the lesson here is to not adopt new technologies on your flagship products (instead of first testing the waters on smaller products).

> There’s a video somewhere in one of our talks of an Uber engineer typing a single line statement in Xcode and then waiting 45 seconds for the letter to appear in the editor slowly, one-by-one. I'm not sure if you are familiar with Xcode, but this indicates an off-the-charts LOC count. Something isn't adding up -- the user-visible features and screens in the app don't necessitate a codebase this large. My guess woul…

It’s funny you quote that specific line because that one line stood out to me too. I agree that something extremely fishy was going on that couldn’t have been solely explained by “too many linked libraries”.

However, choosing a more mature technology like Java or C# or even Golang would have certainly alleviated a great deal of stress from their process.

Re: A former Uber engineer's disaster story

#142

Post by aaronbrethorst »

saagarjha wrote: post #97
aaronbrethorst wrote: post #38

It was pretty obvious when Swift 1.0 launched that it should’ve been called Swift 1.0 beta 1. Not a knock against anyone who worked on the project, other than senior management at Apple. Speaking for myself, I didn’t add any Swift to any codebase I worked on until after 3.0 shipped because it was pretty clear that the language just wasn’t quite ready yet. I’m genuinely surprised no one ever thought to just email Chri…

Large Swift apps are easy to find; companies would invariably use it as a marketing point on their engineering blog. Even if not, people open up apps all the time, any large app that uses Swift would be found and discussed.

Large Swift apps are easy to find

Sure, if they exist. I'm not talking about the world as it is today in December 2020 with Swift 5.3. I'm talking about 2016.

Re: A former Uber engineer's disaster story

#143

Post by wsinks »

saagarjha wrote: post #129
dntrkv wrote: post #108

Earlier quoted context omitted.

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…

This is a common but specious argument. It is possible to make large, complicated apps without creating a monstrosity. That you are making something like this is a manifestation of an engineering culture that has too many cooks in the kitchen, a lack of specific engineering talent spent on finding issues and telling the teams shipping them to stop, people shipping libraries that they don't need and tech debt that was…

For my own curiosity, what large, complicated apps are not monstrosities in your eyes?

Re: A former Uber engineer's disaster story

#144

Post by offtop5 »

saagarjha wrote: post #106
offtop5 wrote: post #35

Earlier quoted context omitted.

True story , when Swift was announced I started cheering so loudly in the office I had to be told to calm down. I hate objective C with a passion. It's like some archaic language of a bygone era forced to run on a cell phone

I hate to break it to you, but almost all the code running on your iPhone right now was written in Objective-C and C and C++.

You can enjoy coffee without grinding your own beans.

I personally find lower level programing to be frustrating and difficult. I've built an amazing career with JavaScript and C# primarily. My hobbyist projects use C# , JS and Flutter.

I can't wrap my head around things like pointers or memory management

Re: A former Uber engineer's disaster story

#145

Post by saagarjha »

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…

Look, I get it that the app is complicated. I look at these apps from the perspective of a reverse engineer but invariably I find places where there is bloat just for the sake of being bloat. There is code that is provably not used, entire libraries that included just so that one small part of it can be used. I see time-related assets that have existed long past the date that they could have possibly been useful. I have seen apps that bundle entire scripting runtimes, apps that have half a dozen in-house telemetry libraries, apps that have megabytes of files in them in the hopes that they may be useful someday.

At this point it's really hard to believe the argument that "but our app is more complex that you could possibly understand" is valid. Compare your list with a Linux distribution from a handful of years ago: do you have more "screens" than that? Can you do more?

Re: A former Uber engineer's disaster story

#146

Post by mcguire »

carapace wrote: post #124
madeofpalk wrote: post #59

Earlier quoted context omitted.

We won't know because all we have is one glib comment from one person, but I took the comment on face value. I've definitely met the class of developer who is mainly interested in pointing out problems and a stick in the mud, and isnt interested in working together on solutions.

Yeah, but what are the odds of Uber having hired a whole raft of that class of dev?

They're fairly common, and any specific environment attracts those who favor that environment.

Re: A former Uber engineer's disaster story

#148

Post by lhorie »

oefrha wrote: post #96
dreamcompiler wrote: post #68

Earlier quoted context omitted.

Follow-on tweets address this somewhat: Every airport has different pickup locations, every region has different payment rules including cash, etc. Apparently all this location-specific business logic has to be in the app itself and is not downloadable on demand.

Yet, the last time I was throttled to 2G speed due to a problem with my carrier, the Uber app couldn’t even start (getting to the first interactive screen) in like five minutes. What’s the point of distributing the entire world’s data, which gotta change from time to time, when you can download the tiny requisite piece each time, especially considering that a relatively high speed Internet connection is required to u…

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.

Re: A former Uber engineer's disaster story

#149

Post by mcguire »

XorNot wrote: post #37

The "curmudgeon" ending line in this story rubs me the wrong way. The ObjC people were right, basically, and it seems like the problem was essentially no one in the right place was going to drop Swift at that point. Seems less like they weren't offering answers, so much as the answer wasn't "but we'll do some stuff and fix Swift!" Though the 6 library limit and how that wasn't a gigantic red flag on the language is b…

In my experience, the problem with scenarios like fight the ObjC folks in the story is that the "curmudgeons" don't see the need for anything to change. Their arguments are not "We should use ObjC and do X, Y, and Z to make sure the problems are fixed," but rather usually turn out to be something like "We should use ObjC (and throw out the rewrite entirely; everything was fine before)." Which at best only results in kicking the problem down the street a ways and at worst is not possible.

Re: A former Uber engineer's disaster story

#150

Post by sethammons »

lhorie wrote: post #148
oefrha wrote: post #96

Earlier quoted context omitted.

Yet, the last time I was throttled to 2G speed due to a problem with my carrier, the Uber app couldn’t even start (getting to the first interactive screen) in like five minutes. What’s the point of distributing the entire world’s data, which gotta change from time to time, when you can download the tiny requisite piece each time, especially considering that a relatively high speed Internet connection is required to u…

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.

Wow, I had no idea! On app load, maybe checking speed and then displaying a link to the web version for low bandwidth areas would be a good move.
Post reply on HN