Calendar and Contacts (2013-2015)

2020-03-25

Table of Contents

All in-depth articles about my Apple career:

Returning to Apple

I interviewed for two teams upon returning to Apple: The Calendar/Contacts team and the Siri team. In retrospect, I dodged a very large bullet by avoiding Siri!

The team I jointed actually had four apps: Calendar, Contacts, Notes, and Reminders. The final two got shortchanged due to the importance of the first two. And it showed.

As an aside, Notes and Reminders have recently moved to a new group and have both become quite nice applications. But it was a lesson in how hard it is to have important, critical apps worked on by the same engineers as less critical ones. You need to have dedicated resources.

My new team

I liked my new team a lot, with a special shout out to Sean Seguin, Sam Cates, and Aaron Thompson. But it did have some drawbacks:

It was quite large at about 15 engineers. I thought I might have trouble with its size and I did. I was used to 5-6 engineers on a team.
It was a very junior team relative to what I was used to. I feel every team should have some very senior talent to guide younger engineers

The job

The job was supposed to be similar to previous jobs I held, where I would be responsible for screening bugs (more on that in a moment), testing, tools writing, and generally being the glue holding the engineering team together. However, due to one major factor, this became a bug screening job, 100% of the time. More like 150% to be fair.

What is bug screening?

Most engineering teams at Apple have at least one person that does bug screening, sometimes called triage. For a small team, it might be a manager or an engineer. A larger team may have a dedicated person and a massive team may have an army of screeners.

When anyone files a bug report (which can include feature requests and enhancements), it goes to the team’s bug screener. This includes the following people:

Anyone at Apple
Anyone in the customer seeding program
Any developer
Indirectly through friends of people at Apple
Automated tools that generate bug reports

I highlighted “any developer” because many developers believe bugs they file go into a black hole. Well, if they do, it’s no more of a black hole than other bugs may end up in. A developer bug goes to a developer screener, who makes sure it has required information and then it goes DIRECTLY to the screener for an engineering team. No exceptions.

A developer bug only has less value if it’s not well written or just deemed less important. The big problem is that Apple doesn’t communicate well with developers about the status of their bugs so they feel short-changed. Trust me, they aren’t.

What happens to incoming bug reports

A bug screener comes into work every day and has a massive pile of bug reports. This is the process:

Read and understand the bug report
Send back to request the necessary information to understand and troubleshoot the bug
Make sure the new bug isn’t already known
If it’s a feature request, determine whether it’s important enough to consider.
Try to reproduce the bug
Assign the bug to an engineer and give it a priority and milestone

A milestone would be something like Catalina or Catalina software update 1 or something like that.

Feature requests

For feature requests, we would get so many that the bar would have to be very high. There are a lot of great ideas but they have to benefit a lot of people and be very important to consider, given limited time. It’s tough to tell people that and is one of the hardest parts of the job. Sorry, your idea is awesome but not awesome enough.

It’s hard for people to accept that a feature request that would make their life amazingly easier won’t make enough people’s lives amazingly easier to spend engineering resources on.

Perfect storm

The day I started on the team, my boss motioned me into his office. It was January of 2013. I sat down and he handed me an iPhone and said “this is what you are working on”

I looked at the screen and played around a bit, and I couldn’t even really figure out what I was looking at. It looked like hell. Everything was white. It was glitchy (to be fair, it was January), the text was huge, what the hell was this?

This was iOS 7. I knew right away that this year was not going to be easing into a new job. They were changing EVERYTHING. I’m not dissing iOS 7 here as I love how it turned out, but at that point, it looked like absolute shit and I could just see the bug reports flying in for every bug screener in engineering.

The next three years

When I started screening bugs, there were over 7,000 existing bugs. As part of my job was making sure incoming bugs weren’t already known… wow, that was going to be fun.

Let me repeat “What does a bug screener do” for a moment:

Read and understand the bug report
Send back to request the necessary information to understand and troubleshoot the bug
Make sure the new bug isn’t already known
If it’s a feature request, determine whether it’s important enough to consider.
Try to reproduce the bug
Assign the bug to an engineer and give it a priority and milestone

Over this 3 year period, I would have anywhere from 4 minutes to 10 minutes to do all of these things for each bug report. The most bugs I got in a month was 3,374—remember that the existing bugs were 7,000 when I started.

The worst part is that it’s an endless inbox. Every night, I’d clear it out and every morning there were 50-100 new ones that came in from Asia overnight. You can’t decide “you know, I think I’ll skip bug screening today and do it tomorrow”

In that way, it’s analogous to ER triage. You can’t have a flood of patients come in and decide to go take a 2-hour nap. They just keep coming in and coming in.

Mistakes

The opportunity for mistakes given that the volume of bug reports was huge:

There could be identical bugs assigned to multiple engineers if I didn’t catch it. Imagine they both are working on the same bug!
I could put an inappropriate priority and milestone on a bug, causing an important bug to not get fixed. Because I was so rushed.
I could harm the reputation of the team by spending so little time on a bug report. If someone takes a lot of time gathering information and I don’t give it the time it deserves, our team looks bad and people may stop filing bug reports against us.

Grueling

The fact that my job was 100% frantic bug shuffling wore on me and I only lasted two and a half years. I begged for help and even recruited and hired some people to help me, but they were snatched away for other teams.

This is where I learned that since I remained caught up despite the workload, management saw that as me not needing help. The teams that needed help promoted their screeners to management and hired a team of screeners under them.

Endgame

Ultimately, many things led me to leave:

The long hours were not good for me mentally
I failed to get the help I needed (see above)
I was unable to do ANYTHING but bug screening, so it got very monotonous. I was used to being able to do a variety of things
My boss was fond of saying “bug screening is easy, anyone can do it” — he later amended that, but it didn’t sit well

In a failed attempt to help my workload, they did get someone to help me out for a few months. I later learned they wanted to get rid of because he wasn’t doing a good job.

So, on top of all the other stuff, I was babysitting someone that simply wasn’t cut out for the job. Adding insult to injury. The person was eventually fired but not until way too many months passed by.

Conclusion

For those that don’t work in Software Engineering, this account may sound like whining, but for those that know what it’s like to be buried in an ocean of bugs, hopefully, there will be some sympathy.

I did enjoy many things about being on this job. The people, the products, and I found the job very challenging and developed many systems to manage the impossible workload. But in the end, my brain was fried.

Overall, I considered it positive for the reasons above and never did I consider leaving Apple over it. Everyone gets their brain friend in software from time to time.

When computers lived in the janitor's closet