Top comment [1] from another good HN discussion [2] about this from late last year. Worth repeating
Here's some of my learnings about getting promoted for those that really want to play that game:
- Only the perception of your work matters
- Attend the social events and get in good with the bosses
- The countability of your major achievements is important. Make the list long, too long to hold in the mind
- At the same time the gravitas of your best achievement is also important since that will be the soundbite that is shared about you behind your back
- Get allies who can proselytize about you behind your back
- Be the best. The difference between one and two is bigger than that between two and three, as far as promotions go
- Take credit for your work (use pronouns I and Me when talking about your work, not We) and do not allow others to take credit for your work
- If it's a teamwork situation with other people on your level, don't do most of the work, because the credit will end up being split 50/50 in the eyes of the bosses even if you did most of it
- Make a very good first impression
- Shape the narrative around the role you played in the success of the mission/team/company
- Get the bosses to make a soft public commitment regarding your competence
- Even if you have a really good boss, all of the above is still important, because they are fallible humans and aren't omniscient
- Actually do good work, it'll make the above easier
Former Uber engineer/EM here: I worked on the Rider app.
The “there are only a few screens” is not true. The app works in 60+ countries, with features shipped in the app that often for a country, and - in rare cases - a city.
The app has thousands of scenarios. It speaks to good design that each user thinks the user is there to support their 5 use cases, not showing all the other use cases (that are often regional or just not relevant to the type if user - like business traveler use cases).
Uber builds and experiments with custom features all the time. An experimental screen built for London, UK would be part of the app. Multiply this by the 40-50 product teams building various features and experiments outside the core flows you are talking about (which core flows are slightly different per region as well).
I worked on payments, and this is what screens and components are in the Uber app:
- Credit cards (yes, this is only a a few screens)
- Apple Pay / Google Pay on respective platforms
- PayPal (SDK)
- Venmo (SDK)
- PayTM (15+ screens)
- Special screens for India credit cards and 2FA, EU credit cards and SCA, Brazil combo cards and custom logic
- Cash (several touch points)
- AMEX rewards and other credit card rewards (several screens)
- Uber credits & top-ups (several screens)
- UPI SDK (India)
- We used to have Campus Cards (10 screens), Airtel Money (5), Alipay (a few more), Google Wallet (a few) and I other payment methods I forget about. All with native screens. Still with me? This was just payments. The part where most people assume “oh, it’s just a credit card screen”. Or people in India assume “oh it’s just UPI and PayTM”. Or people in Mexico “oh, it’s just cash”. And so on.
Then you have other features that have their own business logic and similar depths behind the scenes when you need to make them work for 60 countries:
- Airport pickup (lots of specific rules per region)
- Scheduled rides
- Commmuter card functionality
- Product types (there are SO many of these with special UI, from disabled vehicles, vans, mass transport in a few regions etc)
- Uber for Business (LOTS of touchpoints)
- On-trip experience business logic
- Pickup special cases
- Safety toolkit (have you seen it? Very neat features!)
- Receipts
- Custom fraud features for certain regions
- Customer support flows
- Regional business logic: growth features for the like of India, Brazil and other regions.
- Uber Eats touchpoints
- Uber Family
- Jump / Lime integrations (you can get bikes / scooters through the app)
- Transit functionality (seen it?)
- A bunch of others I won’t know about.
Much of the app “bloat” has to do with how business logic and screens need to be bundled in the binary, even if they are for another region. E.g. the UPI and PayTM SDKs were part of the app, despite only being used for India. Uber Transit was in a city or two when it launched, but it also shipped worldwide.
And then you have the binary size bloat with Swift that OP takes about.
1. I define a set of possible moves (eg. straight ahead, left turn, junction, etc). One possible move is a dead-end, which looks a bit like a house in my interpretation.
2. Each move is assigned a relative weight (eg. continuing straight ahead 10x more likely than turning left).
3. Each iteration, for each of the roads under construction, a random move is selected. Some moves are impossible (based on other roads already drawn on the map) and so it will ensure not to select one that would result in a collision. At worst, it will terminate the road with a dead-end.
4. Repeat forever, until every road has terminated in a dead-end.
Most of the script itself is dealing with the rendering logic. To avoid collisions I maintain a 2D array of all visited points.
