A former Uber engineer's disaster story • Hacker News Board

Re: A former Uber engineer's disaster story

#51

Post by asimpletune » Thu, Dec 10, 2020, 5:06 PM UTC

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…

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.

Re: A former Uber engineer's disaster story

#52

Post by tantalor » Thu, Dec 10, 2020, 5:09 PM UTC

Readable version: https://threadreaderapp.com/thread/1336890442768547845.html

Re: A former Uber engineer's disaster story

#53

Post by jimbob45 » Thu, Dec 10, 2020, 5:09 PM UTC

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

Re: A former Uber engineer's disaster story

#54

Post by secondcoming » Thu, Dec 10, 2020, 5:10 PM UTC

> Some of my ex-Twitter colleges called on me to quit such an evil company that would track you like this.

Twitter owns an company called MoPub that broadcasts user location information to the adtech industry.

Re: A former Uber engineer's disaster story

#55

Post by draw_down » Thu, Dec 10, 2020, 5:15 PM UTC

> The Zealots were in denial about the problems that Swift created. The curmudgeons complained about everything you could imagine without providing much in the way of solutions.

I can sympathize with someone caught between these two factions, but I really dislike this rhetorical move where people say "well you're not providing solutions". Particularly if they were the one who advocated making the mess in the first place. Those people are just galling, the solution would be to fire their fucking ass.

Everything about this originated from people being hotshots trying to use underbaked tech and trying to get promoted (which worked by the way). The "solution" is not running your company/engineering org that way.

The way this ends, in an equanimous "who can say if it was worth it" is totally bonkers to me. Think of the human cost alone. So much of this turmoil could have been avoided by not just simply going balls to the wall. This story is upsetting.

Re: A former Uber engineer's disaster story

#56

Post by microtherion » Thu, Dec 10, 2020, 5:16 PM UTC

nwsm wrote: post #28

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…

Appreciate your insight, and I'm sorry to hear about the AMS team. The OP indicates that a rewrite was necessary regardless. Even if Swift was not yet mature, do you think it was more worthwhile than rewriting in ObjC? Given that the goal was to "sustain mobile development at Uber for the next 5 years". Secondly, I'm not a mobile developer so I don't have much context, and I'm wondering about your outlook on iOS deve…

A complete rewrite of a large project is risky anyway. Doing so in a language in which literally no other project of that size exists yet strikes me as insane.

I love Swift. But I've been adopting it in bits and pieces over the years. It's not just that the language has changed significantly, you also have to get used to the idioms. E.g. my early Swift code often featured Pyramid of Doom patterns, and both language innovations and better familiarity with the idioms have helped a lot with this.

Re: A former Uber engineer's disaster story

#57

Post by overgard » Thu, Dec 10, 2020, 5:16 PM UTC

I know C++ has its warts, but almost every mobile project I've worked on has been C++ with a thin layer of objective c and java interop. IMO it's really not worth it to get so tied up in a single companies tooling even if the developer experience is superficially nicer. C++ has all sorts of awful, but it's familiar awful with mature tooling.

Admittedly the things I've worked on has been games and CAD systems so the internal data models and simulation are a lot more complicated than the UI, but I think that holds for a lot of apps.

Re: A former Uber engineer's disaster story

#58

Post by donmcc » Thu, Dec 10, 2020, 5:17 PM UTC

nineplay wrote: post #46

Not a mobile developer - Was the move to Swift inevitable and they started too early or should they have stayed with - and still be using - Objective-C?

I think it was clear early on that Swift is the future of iOS development. But if you’ve been around long enough, you’ll have observed that it takes about 10 years for a new language and associated tooling to reach “maturity”. What “maturity” means is debatable, but one aspect is that the ecosystem grows to handle the extreme edge cases like very large scale development. And boy was Uber pushing the edges of what was possible on iOS at the time.

So by my way of thinking, they moved at least a couple years too early. (The Swift project started internally in 2010, first public release in 2014, Uber’s rewrite started in 2016.)

Re: A former Uber engineer's disaster story

#59

Post by madeofpalk » Thu, Dec 10, 2020, 5:19 PM UTC

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…

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.

Re: A former Uber engineer's disaster story

#60

Post by pjc50 » Thu, Dec 10, 2020, 5:20 PM UTC

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 that had to run on a MIPS device with 32MB of Flash, of which half was occupied by Windows CE. It's not really clear to me why Uber's app needs to be so large and complicated other than the availability of a large amount of money, high-powered engineers, and shiny new unproven technologies.

(The compact app fit in about eight megs in the end, plus another meg or so for the file which defined all the screens; it was written in the least trendy, unsexiest framework known to man, Windows MFC in C++)