Other articles about my Apple career:
My first 12 years at Apple, I held three different jobs that were just amazing. Mail edges out the other two, but it’s very a very close contest.
My position on the Mail team was really two jobs in one:
- Be an on-call support person for all of software engineering as well as important people in other organizations. I was the public face of Mail and also monitored the “help” mailing list (this article)
- Serve as the lone quality assurance engineer that was fully dedicated to Mail. This included managing incoming bug reports, analyzing, root causing, and prioritizing them (this article)
I’ll cover the support part of the job here. The reason for needing this was a mandate that everyone in software engineering live and work on Apple Mail as their only email client. Some of the executives were also heavily “encouraged” to do so.
This was my first exposure to the dogfood concept. Essentially, having everyone use the product would tease out edge cases that stemmed from the wide variety of workflows and usage patterns that people have for email.
Mail was not in very good shape when I started. I don’t think any of the engineers at the time would take offense at that statement. The codebase stemmed from the NeXT email client that would read messages from a local UNIX spool file. POP was added later and IMAP was just getting fleshed out when I started.
The support part of the job started out to be well over half the job. My phone was very active, people would stop by for help, or send email. There were so many benefits to this being part of my job, which I’ve split into two buckets: software engineering and important people.
I got to meet everyone in software engineering due to this job. The benefits of that were reaped even many years after I left the job. Other than the networking aspect, I got to learn how people used Mail more than anyone else at the company. This helped tremendously when fielding bug reports, testing, and also participating in design discussions for the next versions of the product.
Some people that became long-time friends sprung out of this part of my job. Having a phone and in-person technical support background helped me out a lot here and I later found this was a big reason they hired me. Quite honestly, I had virtually no experiene doing any of the other parts of my job.
I learned the importance of having a public face for a team. If people know that a team listens and is responsive, they are more likely to write good bug reports and be cooperative when more data gathering might be a drain on their time.
I also learned the app inside and out, in ways I probably never would have if my job had only been to test the application. I was very proud of the skills I developed and so grateful to my team members for all the time they gave to me to learn what I needed to learn. It’s good to work with people that understand the need to invest in people and have it pay off later.
I had prior experience dealing with executives and potentially difficult people in jobs prior to Apple, so it was not intimidating to provide support to high-level people including executives. Again, this was profound for networking benefits. If I can send an email to an executive and have a higher chance of being listened to because of a positive support experience they had with me, that benefitted me greatly.
I also have some good stories that came out of it.
The head of the Mac OS 9 (“Classic”) team was challenging to help because there appeared to be a lot of bitterness there towards the Mac OS X team. So, while I’m trying to help, I would get an earful about how crap Mac OS X was compared to Mac OS 9. Not everything was unfounded, but it was challenging to be diplomatic because I understood how people feel when a company buys another company and essentially gets replaced by it.
Some of the people I dealt with like Fred Anderson (CFO) and Avie Tevanian (SVP of Software Engineering) were always very nice and enjoyable to talk to. It was nice to get to spend time with people several rungs of the ladder above you and to be granted some time for chit-chat or brainstorming.
Sometimes I’d deal with executive admins rather than executives. On the plus side was a wonderful woman named Bambi Fernandez. She was Avie’s admin and she sometimes had issues of her own or she would supervise me in Avie’s office. She would have a list of mailboxes with juicy, enticing names like “board meeting notes” and “emails from Steve”—I would threaten to click on the mailboxes and she would freak out but I never did.
Steve’s admin was someone whose name I’ve since forgotten, but I got many an earful from her over the years. I had experience dealing with yelling people so I was cool with it, but nonetheless, this is Steve’s admin not just a random yelling person.
One of my favorite stories was going to Jon Rubenstein’s office to troubleshoot. He was the executive in charge of Hardware Engineering at the time. One day I was sitting at his desk with him behind me and I was mousing and clicking and noticed that the mouse felt weird. Heavier. Then I noticed no cord coming out of it. This was before the wireless mouse had been announced.
I was surprised to see this so I looked back at him and he was just holding his index finger in front of his mouth in a shushing gesture. Good times.
I later realized that combining so many skills into one job made a whole that was better than the sum of its parts. Unfortunately, as software gets more complex, you can’t realistically have someone doing all these jobs at once.
When I started on Mail, we hadn’t even shipped Public Beta yet, so we effectively had a few hundred Mail users in the entire world. Nowadays, there are probably thousands of active bug reports and tens of thousands of internal users. The app is far more complex.
I have some thoughts on scalability, but it’s a difficult task. In any event, the support part of my job was really fun and challenging and I feel proud of the work I did.