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

301–310 of 344 posts

Re: A former Uber engineer's disaster story

#301

Post by lern_too_spel »

_old_dude_ wrote: post #232
lern_too_spel wrote: post #44

Earlier quoted context omitted.

The Android apk is 56.9 MB for my device, while the iOS app is 331.3 MB. What accounts for the 6x difference?

APK is now more a delivery package format than a real executable format now. On recent Android devices, the APK wil be recompiled to machine code on the device after a small number of runs (to gather code statistics). So you are comparing an apple and a robot.

IPA is also a delivery package format. The big difference I am aware of is that IPA encrypts binaries, which will make them less compressible.

Re: A former Uber engineer's disaster story

#302

Post by mpweiher »

_dh54 wrote: post #77

Many engineering horror stories involve an entire system rewrite. My recommendation is to never rewrite a large system. Literally never. If the people proposing the rewrite aren’t capable of adding the features incrementally, they aren’t capable of rewriting the entire system to “easily” support those new features.

I've spent most of my career doing rewrites, each time reluctantly, and each time it was a resounding success.

So easy with the absolutes :-)

Re: A former Uber engineer's disaster story

#303

Post by cbrauchli »

cbrauchli wrote: post #251
nobunaga wrote: post #21

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 the person that actually managed the binary size task force and proved that it was a business problem in the first place. Not all management didn’t care about AMS :) The Amsterdam team 100% played a critical role in solving the issue (at least until apple bumped the limit). No way we would have stayed under it without you all.

Clarification: the engineers on the AMS team played a critical role.

Re: A former Uber engineer's disaster story

#304

Post by jeffrallen »

sokoloff wrote: post #205
bhupy wrote: post #182

Earlier quoted context omitted.

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.

Just because it's a spot on your bingo card does not mean it's not true.

Re: A former Uber engineer's disaster story

#305

Post by orestesgaolin »

sethammons wrote: post #196
linseed_213 wrote: post #169

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

Imagine yourself at an airport and trying to order Uber, but be forced to download new 50 MB app. You would immediately try some other app like Bolt or Lyft.

I'm from EU country and it was so convenient to be able to use Uber in NYC the same way as I would in my home town.

Re: A former Uber engineer's disaster story

#306

Post by Traubenfuchs »

The uber app was never fast and snappy. The uber app crashes regularly, shows fake cars flying across the map, misaligns your drivers car with the black line of the car will take, has spinning cars and countless other bugs.

He ends his "twitter thread" explaining the results of them never properly testing their new UI & UX. Horrible. Another billion dollar company just throwing expensive engineers at narrow, single issue problems. No proper engineering strategy, user centered design or connected thinking visible. Just an overengineered mess having hundreds of megabytes of bloat. I rant, but could my company or me do it better? No.

Re: A former Uber engineer's disaster story

#307

Post by saagarjha »

dap wrote: post #175
saagarjha wrote: post #101

Earlier quoted context omitted.

I think the election of Trump may have made it possible for these cultural problems to come to light, the same way that (for example) women speaking up about sexual assault can empower others to do the same. People saw the issues that were placed on a national stage, then looked inwards and saw similar issues much closer to home, and these things started coming out as people were no longer OK with keeping quiet about…

> I think the election of Trump may have made it possible for these cultural problems to come to light, the same way that (for example) women speaking up about sexual assault can empower others to do the same. > I personally think many companies have issues focusing on non-technical problems...This is not unique to Uber in any way, these problems show up to various degrees across companies such as Apple, Google, Face…

Yes, I think that many engineers can often have a hard time understanding that problems that occur at their workplace don't exist because the media changed attitudes but because it shone a light at internal issues. I remember talking to someone at Facebook privacy and they were somewhat indignant that the media was making them out for being such a privacy nightmare–ignoring the fact, of course, that the tide was turning against surveillance and data gathering in general and Facebook was just one of the most prominent examples of what everyone hated ;)

Re: A former Uber engineer's disaster story

#308

Post by mewpmewp2 »

Groxx wrote: post #234
mewpmewp2 wrote: post #219

Earlier quoted context omitted.

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

You're not always allowed to do that. E.g. Apple requires all code to either be in the bundle or run in a webview (and even then you risk removal if you introduce "significant" features): https://developer.apple.com/app-store/review/guidelines/#2.5... For Android purposes: maybe it's allowed in the Play store? I'm not sure tbh. There are certainly other stores with other rules (and Uber is in many of them too), or th…

Sounds like base things, common for everything should be done using native app code and everything that varies that much should be made as PWA in WebView. You can download this PWA in the background too once app has installed if you are afraid you might not be able to do this on demand. I don't see why not use PWA? The performance implications in this case are minimal imo. And you have all the other fully fledged native features since your app is combination of both. Main arguments against PWA is that iOS doesn't support that well, but hell in this case you skip ALL problems with PWA since you have full capabilities already thanks to being generally native and you are downloading it from AppStore anyway.

In this case it could easily be reused within both Android and iOS without having to create duplicate business logic which I think already is a nightmare.

Airports logic I think should still be something that is defined using JSON/XML or w/e and algorithms should handle parsing that.

Or come on, there must be a way to get airports logic in an easier way. Does user have to update the app every-time when there's some minor airport update?

Re: A former Uber engineer's disaster story

#309

Post by mewpmewp2 »

lhorie wrote: post #241
Groxx wrote: post #234

Earlier quoted context omitted.

You're not always allowed to do that. E.g. Apple requires all code to either be in the bundle or run in a webview (and even then you risk removal if you introduce "significant" features): https://developer.apple.com/app-store/review/guidelines/#2.5... For Android purposes: maybe it's allowed in the Play store? I'm not sure tbh. There are certainly other stores with other rules (and Uber is in many of them too), or th…

There's also something to be said about supporting 60+ versions of a client...

Not following that thoughtline?

Re: A former Uber engineer's disaster story

#310

Post by phink »

quux wrote: post #114

Is this where RIBs came from? My company adopted that and ran into smaller versions of all the same problems. We moved on to something leaner after a couple of months. Lots of interesting ideas in RIBs though.

On top of the discussed complexity and featuritis, I suspect over-engineering, NIH syndrom and "architecture" must have played a role. Misunderstanding, misapplying and blaming MVC to end up with twice the code in 3 or more times more classes.
Post reply on HN