The biggest disaster about this story is having to read it 2 lines at a time.
Too broken up, didn't read.
A former Uber engineer's disaster story
111–120 of 344 posts
Re: A former Uber engineer's disaster story
#112> So my advice. Everything in Computer Science is a trade off. There is no universally superior language. Whatever you do, understand what the tradeoff are why you are making them. Don’t let it descend into a political war between opinionated factions. I really like this point.
This is a good point, but it's important to be clear about it. There is no universally superior language. There are a number of competing factors which means that optimizing for one sacrifices others. So instead of a single point in space that maximizes all of them, there is instead a volume bounded by a curve and going farther in one direction requires lower values on other axes.
But, there is a lot of space nowhere near that trade-off optimizing boundary. You can absolutely make languages worse in ways that are strictly negative for all users. For historical reasons, all languages contain some amount of that dead weight. So the absense of a perfect language does not imply that all existing languages are right at the edge of the optimizing boundary.
Re: A former Uber engineer's disaster story
#113Great thread. > So said brilliant engineer in Amsterdam, built an annealing algorithm in the release build to reorder the optimization passes in such a way to as minimize size. This shaved a whooping 11 mbs off the total machine code size and bought us enough runway to keep development going. > This terrified the Swift compiler engineers, they were worried that untested complier pass orders would expose untested bugs…
Uber also has a habit of solving problems by hiring a manager externally and building a brand new team of all new hires for them.
There's some upsides to that, but basically even though you're a W-2 employee, you're effectively a consultant in that arrangement. Your job is not secure.
Re: A former Uber engineer's disaster story
#114Is 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.
Re: A former Uber engineer's disaster story
#115Seems 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 would be the intersection of several compounding factors:
- a product team endlessly pushing special-case features which aren't core to the user experience (the twitter thread talks about the rate of new code being added as if it were a foregone conclusion the app would continue to grow without bound),
- an A/B testing framework which leads to the deployed codesize being much larger than what the typical user actually interacts with (worse if they are lax about culling the vestigial A's and B's),
- and reaching a "thermal runaway" point of too many devs x too many lines of code, where code reuse stops happening. Once you reach the point where it takes less time for a dev to write a given feature in a from-scratch fashion rather than doing some codebase archaeology to find existing code structures which can be reused, you've reached thermal runaway. The Facebook iOS app revelation of "18,000 classes" indicates they were likely suffering from this as well https://news.ycombinator.com/item?id=10066338
Was Swift up to the task? Perhaps not. But does a ride-hailing app really necessitate this level of codebase complexity? Uber's iOS app is now over 300MB...
Re: A former Uber engineer's disaster story
#116anyone else think it's ridiculous that this is in a giant tweet thread? :\
Re: A former Uber engineer's disaster story
#117The "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…
Yeah it’s kind of bizarre that after writing everything leading up to that, the author would still frame the ObjC folks in that way. Like, this or that eng. was so brilliant with their hack, but all those obj-c eng. who advocated boring but stable solutions all along were just curmudgeons with no helpful advice.
It's the developer equivalent of "support the troops or get out of the way!"
Don't ask why, just do or die.
But yeah, I would have been pissed off if I was put in this situation by myopic upper management.
Re: A former Uber engineer's disaster story
#118Great thread. > So said brilliant engineer in Amsterdam, built an annealing algorithm in the release build to reorder the optimization passes in such a way to as minimize size. This shaved a whooping 11 mbs off the total machine code size and bought us enough runway to keep development going. > This terrified the Swift compiler engineers, they were worried that untested complier pass orders would expose untested bugs…
Almost every large engineering team has someone with the skills to do terrible, but powerful things like these. You should be scared, not of those people or their work, but the situations in which these people become necessary. Strive to make it so that they are not needed. Too many engineering teams, especially at certain large companies (of which Uber is one), fail to understand this.
Re: A former Uber engineer's disaster story
#119anyone else think it's ridiculous that this is in a giant tweet thread? :\
oh gosh thanks https://news.ycombinator.com/item?id=25375799
Re: A former Uber engineer's disaster story
#120Is 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.
Yes