An iOS developer probably has a similar day to most other kinds of developers – it includes reading and writing code, discussions with teammates, and maybe some meetings. But what exactly does that look like?
Well here’s a rundown of a typical day for me (if I’m not working from home):
7:00 – Alarm goes off. Get up, eat breakfast and make coffee.
7:30 – Leave the house. Head to the train station and start the commute. I live pretty far from work, but taking the train allows me to make use of the travel time and avoid sitting in traffic. I also bicycle from the train station to my office, so I get some exercise in as well. While I’m on the train I read or write, or get an early start on my work for the day.
9:30 – Arrive at work. There is no set start time at most jobs, you arrive at whatever time you want, within some acceptable range as determined by the company culture. In my experience you can always arrive early, but people start to wonder if you’re not in by 10 or so. At a minimum, you need to show up in time for any meetings.
9:45 – Daily standup. In this meeting everyone on the team takes a turn describing 3 things – what they accomplished yesterday, what their goal is for today, and anything blocking them from making progress. This is totally standard practice in the software industry now. I like these meetings, and having them first thing in the morning because they allow me to ground myself and keep me on track.
10:00 – Standup followups. Sometimes a teammate will be blocked by something that I think I can help with, or I will be asking for help from one of them. Other times we realize we don’t agree on an approach and need to clarify the plan, or I want to demo yesterday’s work for my manager or the designer. And sometimes these aren’t needed at all. But these chats can be helpful and lead to changes in direction, so its good to do them early in the day.
10:30 – Code review. A critical part of your role as a teammate is to review the code your peers have written. On a well-functioning team *all* code gets reviewed before it is ever used in production. This is a huge topic for another day. The amount of time this requires will obviously depend on what code has been submitted, but expect it to be an hour of your day – and one of the harder hours. Reading and understanding someone else’s code is one of the hardest parts of the job, and providing useful and kind feedback is equally challenging – but hugely valuable.
11:30 – Work on a task. This can look super different on different days, but usually it’s some variant of sitting at your computer, thinking or reading the code or documentation or task description that’s already there, and sometimes typing. These tasks could be:
- Adding a new feature
- Fixing a bug reported by a customer, or found by someone testing within the company
- Writing test code that tests your “real” production code
- Writing technical documentation for you or your teammates to understand how the code is written
- Writing user documentation for customers to know how to use your product
- Experimenting and developing a “quick-and-dirty” prototype for some future feature
- Helping more junior teammates with their task for the day
- Whatever else your manager needs that day
1:30 – Lunch. Just like there is no “start time”, there is no “lunch break”. You just stop working when you get to a point that makes sense for you, and then take some time to eat your lunch. I always step away from my desk for lunch and eat somewhere else – could be a table in the kitchen/cafeteria or a nice bench outside, or perhaps a restaurant if I didn’t bring a lunch with me that day. But I find the time away from my desk is critical to being able to continue to focus through the rest of the day, and avoiding burnout in the longer term.
2:30 – Back to work. Continuing today’s task, or taking time for something else at the request of a teammate, or starting something new.
4:30 – Head to the train. I have the good fortune and privilege of being allowed to finish my work day on the train-ride home. So at 4:30 I leave the office to go catch my train. On my train ride I’m focusing on some independent task – this is sometimes the most productive part of my day, at least in terms of getting the work done that’s actually assigned to me. I tether my laptop to my phone for Wifi, but I have a limited monthly data allowance, so I don’t want to do anything too internet-intensive. Instead I’m usually writing code and tests.
6:30 – Arrive home. Eat dinner, do something fun, hang out with my wife or some friends.
11:00 – Bed time. Read a book for a bit, watch some YouTube, and then sleep so we can do it all again tomorrow!
Obviously this is just a sample day and every day is different. This is why being a developer is fun – every day you are solving a different problem, working with different people, and learning something new. And this is just my perspective! Yours may be different depending on the kind of company you join, or the industry you’re in.
But no matter what, you’ll settle into your own routine, and odds are it will be not too different from this one.