Gimbel et al's methodology and limitations are well described. The data is available. And crucially Joshua Kendall's code is available online (https://github.com/Budget-Lab-Yale/AI-Employment-Model). I wish more research was done this way.
The impact is not terrible given active coding takes <25% of engineers time at most companies1. GenAI can't help too much with high level design work, collecting feedback, etc.
I didn't write this post. But I work with the guys
We've been doing data science and ml for years. After iterating on our tooling for a few years, we've finally settled on some tools that we're happy with. A lot of the wins came from spending more time data with DS teams to understand what they really wanted tbh
Doesn't seem a crazy way to start a company. RDS will have scaling problems but is very mature and fairly easy to use early on when you're working on your MVP
I've used CRDB early on at a startup. There was some overhead. You don't get all the nice PSQL features
Although it did save us a giant migration later on
We've been building up CI tooling on top of Nanoscope. The short term goal for this is: make sure that none of our internal libraries (analytics, experimentation, etc) contribute a significant percentage of the time it takes to respond to any tap in the app. We have a lot of internal mobile libraries, so preventing perf regressions in them is a big rock.
If our CI efforts prove stable, then what you're suggesting should also be possible, if I understand it correctly.
> Science is a process and is close to an infallible thing as we have created as humans. There is no problem with science.
Wouldn't you say mathmatics is the most infallible thing human's have come to creating? The level of rigor in mathematics is much higher and there aren't as many repeatability issues.
I would say mathematics is the language of science. Science is the process of extending knowledge; logic provides the tools for inference, and number allow experimentation/reproduction to be quantifiable. I also subscribe to the idea that mathematics exists independently and is discovered.
What is most interesting to me: we prioritized mobile app architecture and saw big wins as a result. Usually its hard to commit time upfront to app architecture. We've made that the norm (ex, 80% of our app code lives inside plugins). And we've seen eng productivity measurably increase over the last year because of these investments. In many cases doubled.
It's definitely a lot of engineers. But we cram a lot of features into the app. I expect that most people will only experience 10% of them. Consider:
1) We exist in a tonne of countries. And different counties often require different product optimizations and payment methods
2) We have our own map provider
3) We experiment with everything
4) We support countries that have terrible networking. That creates lots of challenges.
From an engineering perspective, that sounds uninteresting :)
Terrible networking? how many engineers does it take to implement a few flavors of retries? :)
Uber growth in term of getting drivers, that's what I want to know. It's not just ride subsidies, but the flow of investor honey helps, of course, but they do have some alpha growth managers.
Oh, it goes well beyond retries. You have issues like unpredictable latencies and lost network connectivity. A feature that works great when RTT is 400ms may require an entirely different approach when RTT is 30000ms. There are also issues with clocks due to both fraud and misconfigured cell towers. India for example has notoriously bad RTT times and Jakarta and several cities in LatAm have issues with clocks.
At scale, across so many different markets, with so many different features, things get complex fast. We want the user experience for both riders and drivers to be magical. More magic requires more engineering. The goal is transportation as reliable and available as running water everywhere all the time.
We also use the IMU measurements to detect drivers who aren't using a phone mount and are instead holding their iPhones while driving.
Features like these allow us to advise drivers on how to be safer and get better ratings since not using a phone mount and harsh braking both correlate with negative user ratings.
A lot more goes into the Uber app to make things magical. I used to read the front page of HN daily to read about all the cool things people around are working on. Since joining Uber, I check far less often now because there are so many cool problems being worked on internally that many of the front page stories sometimes seem quaint in comparison (not that many HNers aren't working on awesome things but the quantity and quality of cool problems my colleagues work on easily captures most of my attention these days).
The best way I can describe working at Uber: it's like building that transportation component of sim-city for every city, everywhere, but it's not a simulation. Despite all the click bait negative press, its bar none the best place I've ever worked.
It is easy to get lost in your work and think it is special. Prior to uber, I've seen quite a bit, and I can tell you certain some are good and certain stuff are not that good
Completely agree that not everything is sunshine and happiness at Uber. The quality is highly variable across the company, but my observation has been that this is a feature, not a bug. Some systems need to be built very well such as software defined networking and container infrastructure, so you need to take the time to build it right. Other areas are one off features where speed to market matters most. Faster, Cheaper, Better, choose two. I would say on average there is a good balance between those three across the company, with each team/project making the right trade offs for the short and long term business goals. Most systems that have proven valuable end up being rewritten. I've helped sunset two older systems thus far.
It's easy to drop in and criticize the architecture of some older systems, but it's also instructive if you were around when they were built and knew the trade offs and constraints that existed when they were first conceived. The growth we've experienced has been astronomical and it would have been non-trivial exercise to build systems 2-3 years ago that account for the scale and business needs today. Even today, it's hard to plan farther that 2-3 years out with the growth we are seeing. I work on a system doing millions of QPS and in 2-3 years, it will be handling an order of magnitude more QPS and more business needs. We might scale horizontally or decide a different solution is needed. I don't think there is a silver bullet and the microservice architecture means that rewrites and re-architectures are tractable problems.
