I really like this point.
A former Uber engineer's disaster story
41–50 of 344 posts
Re: A former Uber engineer's disaster story
#42Definitely thought this was going to be a story about when their car killed someone: https://www.nytimes.com/2018/03/19/technology/uber-driverles...
Re: A former Uber engineer's disaster story
#43It was also, coincidentally, the company where I most respected the key technical decision-makers, because they had the will to discontinue a product that a few customers already were using, because it wasn't meeting its criteria.
Re: A former Uber engineer's disaster story
#44I want to hear the Android side of this story!
Android was a much easier story, Still had some binary size and method count issues but we were able to overcome them thanks to another brilliant engineer we had in the team in SF who worked on Android.
Re: A former Uber engineer's disaster story
#45My mind is constantly blown away that Uber app needs to be so big.
Re: A former Uber engineer's disaster story
#46Was the move to Swift inevitable and they started too early or should they have stayed with - and still be using - Objective-C?
Re: A former Uber engineer's disaster story
#47I've lost track of the number of "biggest engineering disaster" stories I've read that begin "so we decided to rewrite it..." The story arc is almost always the same: starts out very promising and moves quickly, then at some point the wheels come off but everyone keeps going. Anyway, Joel Spolsky nailed it 20 years ago: https://www.joelonsoftware.com/2000/04/06/things-you-should-...
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…
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 recommend it but since it costs less I'm pushed to evaluate it. I am handed 3 samples and they all work fine, so management convinced themselves that Brand X from China is the way to go.
Once in production the modems started to fail at a 10% rate (10 devices over 100 won't work). And that is a problem you only see only when manufacturing a certain quantity of devices.
Now there are delays, an ongoing battle with the manufacturer of modems and a unhappy customer (that's why I didn't recommended it).
Re: A former Uber engineer's disaster story
#48My mind is constantly blown away that Uber app needs to be so big.
Re: A former Uber engineer's disaster story
#49It's interesting to me that the author feels that things were great with Uber in 2016 pre-Trump and that Trump's election was the catalyst for the negative sentiment. Susan Fowler's famous post was early 2017, and maybe _posting_ it was catalyzed by the issues surrounding Trump, but clearly the serious cultural problems she described at Uber had been going on for some time before that.
I'm trying to figure out what to make about a lot of these mis-steps. On the one hand, many of them seem preventable: you could imagine identifying ahead of time that load time and binary size might be risks for the new app and scale-testing these very early in the process to de-risk it. You could imagine testing the new app long enough (and widely enough) to discover the location issues (drivers going to the wrong blocks, etc.). You could imagine foreseeing users being upset about suddenly needing their location data when they're not using the app. Obviously hindsight is 20/20, but is there also a pattern (that we see all the time, especially in Silicon Valley it seems) of not really thinking through the consequences of a lot of decisions, especially where things like user privacy are concerned?
Re: A former Uber engineer's disaster story
#50Earlier quoted context omitted.
Android was a much easier story, Still had some binary size and method count issues but we were able to overcome them thanks to another brilliant engineer we had in the team in SF who worked on Android.
The Android apk is 56.9 MB for my device, while the iOS app is 331.3 MB. What accounts for the 6x difference?