A day in the life of an iOS software engineer

Click the image to view the video instead

I get extremely frustrated whenever I see kids on Youtube make “A day in life” videos. Instead of showing people what they actually do, they just showoff their playground work environment and sip boba in front of the camera. Ugh.

Anyways, this isn’t a rant so let’s cut to the chase.

I currently work as a software engineer at Doordash. For the few of you that don’t know, Doordash is a food delivery app. We have two main apps: one for ordering food (We call it: the Consumer app), and another for couriers (we call it: the Dasher app).

So what do I actually do as a software engineer?

My primary role is to develop our iOS Consumer app — the app that you’re using to get your food delivered while you’re self-quarantined.

Before I dig into my day to day work, let me briefly summarize team structures at Doordash to give you a better context. At Doordash, product teams are formed into what is commonly referred to as Pods. Each POD, if you will, takes ownership and responsibility of certain user experience, product feature, technical domain, and etˈsedərə.

Structures vary across teams but a product-based team is typically composed of a few backend engineers, front-end web developers, Android engineers, iOS Engineers, product designers, a Product Manager, an Engineering Manager, and these… strange creatures… that deal with the business side of things… It’s never clear to me what they actually do. Many consumer product companies these days are structured that way.

The team that I’m currently with is responsible for launching and maintaining our new business vertical: Doordash Convenience. The TL;DR is that we wanna deliver more than just… food. From its conception, Doordash aimed to be the leading last-mile delivery logistics company, so… it makes sense that we want to expand our offering by delivering bananas, apples, and toilet papers.

Alright… Now that you have a better context, let me show you what I typically do as an iOS Engineer in the Doordash Convenience team. We recently launched the first version of the Convenience product. I’ll be using that to show you my work since it’s all public now.

Cool. You can think of my role as a cycle of three phases.

The first phase is when we finalize the product requiremnts. That’s the phase where I code the least and use my soft skills the most. My day to day work will involve me attending meetings with business and design folks to provide my insights and time and effort estimations. Discussions like “Should we allow consumers to add special instructions?” or “Can we use a different API endpoint?” or “How much longer will it take if we wanted to add this carousel?” will take place in this phase.

I’ll also bounce off my coding-related ideas with other iOS folks in the company and give them a heads up about the product that we’re building.

Since, literally, millions of people will be seeing this product, we have to be extremely cautious and plan accordingly. I typically write up a document that details my approach for adding the feature to our existing iOS app. Pretty much everything — from my decision to use certain architectural patterns to the use of any specific iOS components — will be documented and shared with the iOS consumer team.

Coding in the Doordash Mountain View office

Once the product and design requirements, as well as coding decisions, are finalized, the next phase is coding. This is my favorite phase, to be honest. I’ll be given a deadline based on the estimation I provided to complete the project. My day in the life of this phase looks like this:

We kick off the day with daily standups where we talk about what we did the day before and what we hope to accomplish on that day. After the standup, I pretty much… just… code all day. It’s really as simple as that.

To make myself extremely efficient, I reject all calendar invites that aren’t absolutely necessary for my work. That includes events, office hours, and pretty much everything else. I prefer catching up by reading follow up emails after I’m done coding. Since focusing is critical here, I try to say “No” as much as possible. If a person from another team asks for something, I simply refer them to someone else. Context switching can be costly so I try to eliminate distractions as much as possible.

Many of you emailed me questions about my work station so I guess I’ll just answer them now. The only hardware that I use is a 15-inch Macbook Pro that the company gave. It comes with a 2.4 GZ Intel Core i9 processor, a 32 Gig memory, and 1 TB storage. The office is well equipped with monitors, keyboards, and other accessories. Since we’re all working from home for self-isolation, the company also shipped a few accessories such as this monitor. I rarely use it though. I also have an iPhone 8 that I use for testing while I develop apps.

As a side note, I don’t think you’ll be needing any of this equipment if you’re just starting out and want to learn iOS development. You’ll be fine with nothing but a good old 2015 MacBook Pro. Lack of equipment, in my opinion, is just an excuse for most people.

As for the software we use:

- Xcode for app development. I use the Simulator to simulate our apps on multiple screen sizes.

- Github for maintaining our codebase on the cloud

- Atlassian JIRA for project management

- Google Docs for collaboration

- Slack for communication

- Zoom for video conferencing

- We also use Amplitude, Firebase, New Relic and a few other tools for analytics

Here’s how I do work:

Since this is a relatively big project, I’ll divide it up into multiple tasks. This is an important exercise to ensure that the work is neatly organized. I like to categorize the tasks by UI, business logic, network requests, and testing (unit tests, add test cases, etc).

Once a task is complete, I create a pull request and ping my peers to review the code.

After a few… battles, my code gets merged and is ready to be deployed. The iOS engineers in the Consumer App team take turns to be the release managers on a weekly basis. Every week, the release manager will work with a QA person to run the latest version of the code on an iPhone to make sure that all the test cases pass. Once that’s clear, he’ll upload the code to Apple iTunes and Apple will publish that new version to the App Store.

This cycle repeats until all tasks are complete. To control the entry points of the product, everything is wrapped behind an experiment. Once all of the code is deployed and is available on the App Store, the Product Manager will turn on the experiment so users can actually see the new features. The initial rollout is typically available to certain regions before we make it available to everyone.

The product launch is the third phase of the cycle. The first couple of weeks can be very intense because we’ll be closely monitoring the launch by checking the health of the app (ie making sure that users don’t experience any crashes), check the health of the API network requests, study tracking events, and so on. Once this process is complete, it’s time to kick back, relax, and ignore Slack messages from my boss.

Phase three is the most rewarding and relaxing phase. We typically enjoy it for a few weeks before moving back to phase one.

As you can see, my day to day job varies from phase to phase. Some days are relaxing and other days can be intense. I personally like this hunt and feast lifestyle, but it may not work for everyone. Of course, not all engineering roles, teams, and companies are the same so do keep that in your mind. Thank you.

The three phases of the day in life of an iOS Engineer