4 ms·
All of those probably have huge tech. Imho engineering wise, Uber really needs tech. If you read uber tech posts, you can see the challenges they face. Even if
by mping 7y ago
All of those probably have huge tech. Imho engineering wise, Uber really needs tech. If you read uber tech posts, you can see the challenges they face. Even if you want to apply so called best practices you need an above average tech team at the very least. The proof is in the failure rate of our industry.
- goatinaboat 7y agoyou want to apply so called best practices you need an above average tech team Actually, the opposite is true. To apply best practices you need people with attention to detail who can follow a runbook precisely. You need relatively few to keep the runbooks up to date. Traditionally the former were referred to as “operators”.
- NeverFade 7y agoBest practices are guidelines, not exact and fully-specified recipes that an ant could follow. If only implementing complex tech solutions was so easy.
- marcinzm 7y agoRulebooks only work perfectly when everything is static. Even then they only work when you also know all failure cases perfectly which you almost surely don't. Uber is in a competitive market and can't freeze features for years at a time. Furthermore, it in a growing market which means scale alone will cause new failure points to come up.
- geofft 7y ago> If you read uber tech posts, you can see the challenges they face. Even if you want to apply so called best practices you need an above average tech team at the very least. The proof is in the failure rate of our industry. This is one possible interpretation. The other possible interpretation (which I favor) is that good engineers like working on hard problems, and will gravitate towards places where they can work on hard problems—whether or not the business actually fundamentally requires hard problems. There could be simpler architectures. (Remember that pre-Uber, nobody really said that the problem with the taxi industry was that you had to call a dispatcher on the phone and that system couldn't scale. Dispatchers were bad at things, sure, but we didn't think that phones were fundamentally too low-bandwidth to handle the request rate.) Some recent posts on Uber's tech blog: - A zero-downtime migration from a payments architecture with eight microservices that needed a code update every time they launched something like Uber Eats, which was "an unsustainable use of development time," to one that was generic across new businesses Uber might launch in the future. - A tool to automatically generate an iOS app with the same build structure as their current app or a slightly modified one, to see if certain approaches would speed up their build times. - A new web interface, with feature parity to their mobile interface, based on the JavaScript framework previously developed by Uber Engineering and also using fancy new web platform features like service workers. - A new framework for automatically submitting data analysis jobs to their scalable computing environment with the ability to update configs to match changes to which databases exist, which computing clusters exist, how to access them, etc. - A conversational AI platform. - An AI ant that walks around in better ways. None of these, I think, fall into the category of Uber really needing tech. They're all cool, they all have long-term business value, but you could just declare that you're tech-skeptical and don't want to make platforms for platforms for platforms and still deliver Uber's core business - matching users with cars and moving money around - just fine.