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

211–220 of 344 posts

Re: A former Uber engineer's disaster story

#211

Post by bsaul »

elliottkember wrote: post #100
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…

Thank you for all these details. I think it's a good sign when people think your app is simpler than it really is - the Uber app does a good job of hiding this complexity.

I had a theory about why very very skilled people aren't promotted as they deserve : because they make hard problems look simple.

On the other hand, the not so skilled ones...

Re: A former Uber engineer's disaster story

#212

Post by renewiltord »

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.

No, that's why it's beautiful product design. They know something about me. I am at location A and I have a problem: I want to be at B. They then solve that problem smoothly with reasonable defaults. They know this is the prime problem I have and that I have some top few variants on this.

Speaking of the defaults, the auto-suggests these guys have are fucking ridiculous too. Both Lyft and Uber. It's 4 AM in the morning and I've opened the app at home: offers me a ride to SFO. It's 11 PM in the evening on a Friday/Saturday and it offers me a ride to my friend's place. It's midnight and I'm at that friend's? They offer me a ride to my favourite club. I am one-click touching everywhere. These guys are good.

Superb user functionality.

Re: A former Uber engineer's disaster story

#213

Post by dntrkv »

ForHackernews wrote: post #201
dntrkv wrote: post #194

Earlier quoted context omitted.

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.

Just like Alphabet is just a search engine, and Microsoft is just an operating system, and Amazon is just an online store.

Companies grow into new products, services, markets, etc.

Re: A former Uber engineer's disaster story

#214

Post by qntty »

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

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.

Re: A former Uber engineer's disaster story

#215

Post by madeofpalk »

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?

I think reasonably high!!!!

Re: A former Uber engineer's disaster story

#216

Post by favorited »

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…

Aside from ObjC garbage collection, those things are all still good. Bindings enabled you to create things like complex editable tabular UI without writing any code. And the recommendations about how to use GCD efficiently have changed over the years, but it's still the foundational solution to concurrency on Darwin platforms (including being the basis for the new async/await runtime for Swift).

Re: A former Uber engineer's disaster story

#217

Post by mewpmewp2 »

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…

It seems like most of these things should be downloaded on demand or at least after the initial install and in background.

Same with dev experience. You shouldn't have to compile things you are not using to dev.

This would give pretty much infinite scaling.

I do think Uber requires tons of engineers, but I disagree that all of this has to be downloaded immediately or bundle size has to be this big.

All of what can be logic wise should be server side. For instance Airport logic seems like one.

Re: A former Uber engineer's disaster story

#218

Post by WSSP »

offtop5 wrote: post #144
saagarjha wrote: post #106

Earlier quoted context omitted.

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

post-ARC, Objective-C and Swift aren't very different in terms of memory management. retain and release are handled for you, and you only need to worry about retain cycles. structs in Swift change things a bit, but not that much

Re: A former Uber engineer's disaster story

#219

Post by mewpmewp2 »

ufmace wrote: post #209
ForHackernews wrote: post #203

Earlier quoted context omitted.

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

Initial install bundle should be minimal and only have code that is required everywhere and or for downloading/installing more stuff.

It's not about creating 10,000 different permutations of an app, but downloading/installing content on demand.

If we are afraid that there might be problem that user later on has not enough bandwidth or issues like that, we'll start immediately downloading/installing after initial bundle in order we think this user might need them.

This means much faster initial usage, much less bandwidth used in total.

Same with developing experience. You shouldn't have to compile code that is not important for your development exp. This way compiling wouldn't take much time, dev productivity would be increased tremendously.

Re: A former Uber engineer's disaster story

#220

Post by aaronbrethorst »

saagarjha wrote: post #156
aaronbrethorst wrote: post #142

Earlier quoted context omitted.

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.

My point was that there was no need to ask Chris Lattner back in 2016: you could just look around the landscape and see that there were not many, as they would be easy to see if they did exist.

Lots of companies don’t speak publicly about their product strategies, like certain former employers of his.
Post reply on HN