Why Uber Drivers Make Great Software Engineers

Leon Noel of Resilient Coders and 100Devs often says that his mentees and students who ride-share (Uber/Lyft)—along with teachers—make some of the best engineers. I always wondered why this was. So…eventually, the universe forced me to learn why—like the universe often does when I’m really curious about something. In the midst of layoffs, this software engineer became a fudging Uber driver! Because I have experience as a software engineer, I’m seeing how skills you gain as an Uber Driver can be transferred to Software Engineering.

So I decided to document my hypotheses on why Uber Drivers make the best engineers and what transferable skills you gain as a ride-share driver that you might not get in a university computer science program, a BootCamp, or even on your first year on the job as a software engineer (but should)!

Uber Drivers have to deal with ambiguity

Uber drivers sometimes have to deal with ambiguity with passenger location and other mysteries. And software engineers have to deal with it around product or technical requirements. The best software engineers are really good at driving clarity 🚙 (no pun intended) in the face of ambiguity.

For example on the ride-share side, sometimes the rider has more context than you as the driver. If they live in an apartment or have you pick them up at a confusing shopping center, they might text with instructions on how to get them like “I’m at the leasing office” like i know where that is…I mean I know leasing offices are usually at the front of the building but sometimes where the front of the building is exactly isn’t obvious. Or “Come around the corner.” When there are two corners I could go around…Which corner?

For engineers specifically, we have this issue: product managers, clients, and other stakeholders sometimes have the same habit of assuming engineers have context that they have but we don’t. Because product managers in particular work all day defining product features and business goals, sometimes they take the context of these things for granted and forget to explain. They forget, we didn’t go to the strategy meetings they had with the CEO or didn’t see the Figma mockups they have in their heads. Just like passengers forget that Uber drivers don’t live at their apartment complex or have never been to that shopping center where they’re waiting.

As software engineers or ride-share drivers, it’s our job to make sure we get on the same page as PMs or customers respectively. To not be afraid to ask questions that might seem silly. To realize that just because something seems obvious to the person we’re communicating with doesn’t mean it will be obvious to us. As Uber drivers in particular, we have to not only drive clarity in the face of ambiguity, but we have to do so with a frustrated and impatient rider (I’m just speaking from my experience, product managers with unclear asks tend to be a lot more patient than riders who give unclear directions).

The ability to calmly clarify things under pressure is underrated and essential in engineering too. And it’s a skill I teach in one of my workshops “Communications Skills for Software Engineers” (feel free to send me an email if you want to book this workshop).

Uber drivers set boundaries/push back on requirements

Uber drivers set boundaries/push back on requirements…just like software engineers

With Uber driving, you’re given alerts on rider needs. Sometimes the app wants you to drive a full hour just to get $10 or drive all the way out to the middle of nowhere making it impossible for you to get home. You sometimes have to say no, even though Uber will penalize you in a sense…as in you won’t get to Uber Pro Gold the more you deny rides (ok…💅🏽), but also…you get in the habit of knowing that even when pushing back on requirements and setting boundaries, you can still keep your job. With software engineers, it’s the same. Sometimes passengers want to make extra stops but they’re a Share rider (Share riders can’t add extra stops). Sometimes Share riders want you to skip picking up a passenger because they are late for work and their job is down the street (shouldn’t have gotten a shared ride then, babes). Sometimes a rider will, after sitting in silence for 30 minutes, ask to take you out on a date.

Or you may have a rider with 3 kids and no car seat—or an unaccompanied minor. You’ll have to deny them if you’re a driver in the US because this is illegal.

As an Uber/Lyft driver, you learn quickly how to say NO to protect your time and money and sometimes even safety.

For junior engineers specifically, saying NO is a hard skill to learn because you want so desperately to seem competent. So you end up saying yes to everything, heads down and you drown or you end up working 80 hour-weeks and make things more difficult for your whole. I know this from experience, but it’s better to set clear expectations with product managers and other stakeholders. With Uber driving you have to learn to calculate the feasibility of a task and whether it’s worth the time.

To go from a good to a great software engineer or to move from junior to senior, one skill you have to learn is pushing back on requirements. The director of engineer might want your team to only focus on building features to meet KPIs but you want to focus a little on technical debt so you have to explain why focusing on technical debt will help your team ship features faster. Or your UX Designer says customers want the hover state of a button to be different and you have to explain why this seemingly simple task might take longer than expected (because Bootstrap makes getting access to child components difficult).

For more information, check out 20 TIPS New Uber Drivers Need to Know.

Uber Drivers practice handling edge cases under pressure

Uber Drivers practice handling edge cases under pressure…just like software engineers.

As hinted under the “Uber Drivers have to deal with ambiguity” section, Uber drivers often have to deal with edge cases. Sometimes there are road closes that the Uber app is unaware of. Or there’s a parade Uber didn’t know about.

One time I was driving a rider to work and once we got 2 minutes away from the warehouse, there was a train blocking us and it wouldn’t move!!! It was standing still. Every time, I tried to turn around, the Uber directions wanted to take me back to the train tracks that were blocking us. I had to pull over, ask the passenger for the exact address (because sometimes Uber doesn’t like to spoil the surprise), and put it in Google Maps…which also kept bringing me back to the train tracks that were blocking us.

So I had to pull over once again and look at the map to problem solve. Ok. I know I need to get to Sycamore Ln (that’s not actually where I was going but I’m changing the names to protect passengers and myself). I saw that if I could make it to this Jamaican Restaurant if I went down Sesame Street (again fake name…or is it? 😉) then I could get to Sycamore Ln.

It’s the same with software engineers. What if you’re designing an algorithm that takes an array and a target and returns the indeces of the two elements that sum up to target (i’m describing the two-sum problem)? What if none of the elements sum up to the target? How can I deal with that? Should I return an empty array? And array with two elements both being -1? Sure in an interview, they might tell us that the array will always give us an answer but it is it good practice to assume their will never be an error?

In a real-life example, as a freelance engineer, I have built scheduling tools for clients for their clinical practices. Sometimes I have to deal with edge cases like time zone differences (what if one of their patients has to drive into Atlanta which is on EST from Birmingham which is on CST)? What about daylight savings time? What if they’re scheduling a telehealth appointment with a patient in Arizona which doesn’t have daylight savings time?

Edge cases are where real software is tested—and real engineers are made.

Uber drivers know the importance of optimizing distributed systems

Uber drivers know the importance of optimizing distributed systems…like a software engineer (who’s working on a product that needs to scale).

The app sucks! No shade to Uber and I am grateful to them for providing me with an income while I am looking for a new role but the app often glitches making it harder for us to do our work as drivers. The fact that it doesn’t work well 100% of the time is a great lesson the importance of large distributed systems well. Uber is considered a distributed system because:

1. It has a lot of data ✅ (the whole world map is stored in Uber’s app)

2. It has a large user base ✅

3. It’s being updated frequently ✅

4. It’s expected to work at all times ✅ (even if it doesn’t work all the time in reality—again no shade)

As Uber drivers, we see firsthand what can happen if a distributed system fails. Riders don’t get to work on time, they miss their flights, and drivers miss out on cash (and so does Uber as a whole). And this is why system design matters so much. It not only benefits the users but the business and the engineers. For more information check out this video on system design.

Uber Drivers have to know when to ask for help

Uber Drivers have to know when to ask for help…like software engineers…

So because Uber drivers who use this driving as their main source of income drive so much, their cars go through a lot of mechanical issues. Sometimes they can fix themselves with a lot of Google and watching Youtube videos. Sometimes they may have to hire someone else to fix it.

Recently my check engine light came on. I texted a mechanic my friend recommended. He told me to go to AutoZone and ask them to check my engine. I did this. The problem was the VVT Solenoid. As an engineer, I was curious about this so I Googled the “VVT Solenoid [my car’s make and model]”.

I found a video where this race car driver said that the VVT Solenoid might not even be broken, it might just be really dirty if you waited too long to get your oil changed (which I did 🤦🏽‍♀️) so you can clean it yourself with the right tools. But I didn’t have those tools. I had to think “Would it be worth it to buy these tools or just pay the mechanic who has all these tools already?” I could borrow some of these tools from my brother or the buy-nothing community.

I could get a new VVT Solenoid but the [My Car’s make] dealer said that it would cost $300 just for the car part. That’s a car payment for me. So I thought back to the video and although I didn’t want to pay lots of money for a new Solenoid just yet, I wondered “What if the Solenoid is good but it’s just dirty? I could save money by just cleaning?” I also thought “But what if it’s not just dirty? It’s bad but I spent money cleaning it and now also have to spend money to get a new one in addition to the cost of cleaning?” Or “What if I try to fix it myself and get an injury that makes it hard to drive or program? Then I won’t be able to make any money let alone save it?”

When you are a software engineer, you have to do a lot of troubleshooting and Googling things yourself. Eventually, you may hit a wall and need to ask for help. You also have to make technical decisions in collaboration with a team which is kinda what I was doing with my mechanic.

For example, my first time working on A/B testing. If you don’t know A/B testing is a process by which you create a new feature test if users will react differently to the feature. It works by 1. splitting up users into a control group (that has the old feature or lack of the new feature) and an experimental group (the new feature) 2. Measuring analytics to see if there’s a correlation between having the feature and a particular (usually desired) behavior. At this particular startup we used a third-party to create A/B tests using Launchdarkly to set up a feature flag that could be turned off or on depending on whether the user was in the control group or the experimental group. For the data collection part of this experiment, the third-party to use was unclear. The Jira ticket told me to use Heap to collect data. Whereas my team’s official documentation on A/B tests told me to use Warehouse. I Slacked, an engineer I felt comfortable with (whom I considered my work best friend) which one should I use. He told me that he wouldn’t be helpful with this issue (which now makes sense because we started at the same time).

As a junior engineer, who again, wanted to seem competent, I was too scared to ask for help.

In my work journal entry from 10/28/2021, it says:
It felt like those situations where in class, you’re too embarrassed to ask the teacher for help in front of everyone so you either ask her in private or you ask your friend who studies more than you do.

But Arthur [Berman] told me that it was more so a situation where you had a really good question that would benefit the whole class and would impress the teacher if you asked. So he coached me a little bit in asking.

And Arthur was right! This issue ended up being really controversial but he was right. Engineers who had been on the team for a long time said they always used Heap, but I pointed out that the data science team had changed documentation back in August and it was only October so we may not have been alerted to the change.

There was also a lot of back and forth between our Product Manager and the Staff Data Scientist but we finally came to the conclusion that Warehouse was what we should use and our team adjusted to the change, all because I had asked a question.

It was a issue simple looking back, but this made me feel more component as an engineer and really highlighted how important it is to ask questions as an engineer. That asking questions might be a more important skill for an engineer than being able to use recursion to flatten an array or traverse through a linked list.

Uber driving forces you to make quick decisions on when to ask for help without hesitation whether that be from a mechanic who can help you fix your car, your brother or roommate whom you can borrow tools from, or even a passenger who might be able to give you a better route. Asking questions faster can help you to save time and money as both a ride-share driver and an engineer.

Conclusion

As a software engineer, Uber driving taught me a lot more than I expected. It reminded me that problem-solving, boundary-setting, debugging, asking questions, asking for help, and real-world systems thinking aren’t just tech skills—they’re life skills.

And it turns out, the road makes a pretty great classroom. 😎🚗💻 [Plays “Life is a Highway” and drives off into the sun]🌞

If you’re a rider share driver turned software engineer (or vice-versa like me), please comment with why you think we make good SWEs.