In which I write a much-too-long description of my journey as a software engineer.
A friend asked me to answer some questions (in bold, here) about my career, for a talk to a group of students. I wrote much, much more than asked for. Sorry, friend! Other friends, you probably don’t want to read this unless you’re intensely curious about my career journey. Let’s call it my little memoir, though that makes it sounds like I’m old and retired, rich and self-absorbed. To cut right to the most valuable stuff, skip all the way to the bulleted list at the end.
Let us start at the beginning… Fezzik told me to go back to the beginning, so I have.
When I was in 4th grade or so, my dad got us one of the most exciting Christmas gifts. It was a console of sorts, the TRS-80 Color Computer, affectionately known as the “CoCo.” You hooked it up to your TV, and you could play games on it. It accepted both cartridges and cassette tapes. But it looked like a great big keyboard. And if you booted it without any games plugged in, it would let you program in BASIC.
The CoCo came with a book about programming in BASIC. And my dad, who had a degree in computer science but was working as an engineer in the army, encouraged us to check it out. He helped us type in some of the programs, which drew little pictures and things. I was a bit intrigued, but typing was hard at that age, and my younger brother and I had little patience for it. So mostly we used the CoCo as a console.
In 7th grade I took real typing classes. And I played the CoCo some more, until the real love came into our lives… The Nintendo Entertainment System. Good-bye to the CoCo for a couple more years. By 9th grade, I started wondering if I could make games. At that point I played some simple ones on my dad’s PC. Text adventures were pretty popular, and seemed like something I could make. I dreamed of making a D&D style game, too. So I pulled the CoCo back out, and started coding up some games. I used that little CoCo for all it was worth – its 16K or so of memory couldn’t hold my programs, so I had to store them on a cassette and load the next part of the program in at the appropriate time. Until my cassette was corrupted by random static. That was a sad day.
When you were a senior in HS what did you want to do professionally?
By 10th grade I knew I was going to major in computer science. I wanted to make games, but mostly because that was the only thing I thought one would do with a computer. Back in 1994, most games were pretty simple, pretty easy to see yourself building. Except console games. Through high school I was downloading shareware games off of BBS’s, and getting monthly subscriptions of floppy disks with little games in the mail.
What did you study in school?
When I got to school, I discovered I had a love for math, too. At least, a certain kind of math that I happened to study freshman year, multivariable calculus. We did all kinds of graphs and visualizations, and that really clicked for me. I decided, in addition to majoring in computer science, I’d try to earn a minor in math. Because I thought that’d make me even more employable. So I took lots of classes that counted for both CS and math, things like algorithms and statistics.
Well, I didn’t get the minor. I got 1 class away from it, but that was a linear algebra class that did NOT click for me, and I had to take the super-hard version that all the hard-core math majors were taking. I fell at the bottom of the grade curve, and had to drop the class. The next semester, I took the easier version of linear algebra that all the poor non-math majors (most of them years younger than me at that point) were struggling through. I passed it without even going to class. Part of my college realization was that there were 2 different ways to teach math: one with graphs and visualizations, and one with equations. The former worked really well for me; the latter very little. And I had friends that were the other way around. Shrug. By the time I failed to get my minor, I knew it didn’t matter THAT much. The only loss I felt was the disappointment of not attaining a goal I had set for myself.
Junior year, I had a LOT of disappointments. Most significantly, my parents divorced. I also made exciting plans to live with some great friends, which fell through. I caught mono halfway through the year, which impacted my performance on the rowing team quite a bit. And I lost a chance to participate in an important career program at school.
This was an internship program, where companies from around the country came to interview us. I did probably 10 short interviews. We’d rank the companies we talked to, they’d rank the people they talked to, and if we were matched to a company, they’d pay our tuition in exchange for us working there 2 summers plus a semester doing a master’s thesis. 2 years of free tuition, summer pay, and a master’s degree! That would mean everything; my dad had already been struggling to pay my tuition, but the divorce had put him in real financial difficulty. I was somewhat confident going in, because I was doing OK in my classes. But I figured I needed an edge. I couldn’t just be a generic programmer. I had to have something specific I was interested in. I thought about my recent classes, to decide what I had liked. In truth, pretty much any CS class I took, I liked well enough to want to focus on that for the rest of my career. But (I thought), I had to pick something. So I picked AI. I had all these great interviews. I distinctly remember one where the interviewers said I was the only person all day who could tell them what processes and threads were (I had read it in a book 2 days before prepping for the interviews). If anyone asked me what I was looking for, I said I wanted to work on AI. I was so hopeful. Most of the applicants in the program got a letter that said either, “You’ve matched with Company A,” or “Company B ranked you 4th and Company C ranked you 5th so keep hoping you’re called off the waiting list.” I got a letter that said, “I’m sorry, nobody ranked you.”
Devastating.
I kind-of wish I could go back and tutor old-me, to say, “That’s dumb, nobody in 1997 is doing AI but college professors. At least look at what the companies you’re interviewing with are doing.” These days, in 2019, machine learning and big data and AI are THE BOMB. But in 1997, not so much. So moving along toward the end of junior year, I’m starting to have to figure out what the heck I’m doing for the summer. I’m interviewing. And I see a poster about this Microsoft scholarship program. The only catch was you had to intern there 2 summers if you were selected. Now, at that point Microsoft was one of the most popular companies everyone loved. It was the middle of the dot-com boom. The stock was meteoric and people were getting rich. I had a friend who did an internship at Microsoft the year before, and he came back with stories of free drinks and cheap apartments with tennis courts. I would have given my left leg to work at Microsoft, which is something, considering how much I cared about my rowing team. So I applied.
And I was selected!! One of the most exciting days of my life. That meant the world to me, and the first thing I did was call my dad. Not only would he be greatly relieved to hear about the scholarship, he was really the one who got me interested in computer science in the first place.
So junior year didn’t turn out so badly for me after all. Maybe I got lucky, having all the best students get slurped up by the internship program before that Microsoft scholarship opportunity came out. Who knows. No regrets.
What have you done at Microsoft (did you intern there during college)??
I arrived at Microsoft in the summer of 1997, ready to do whatever people were willing to pay me money for. I didn’t get to pick what I worked on, and I ended up as a tester on a product called Visual Interdev. I wasn’t excited about Visual Interdev. I thought it was sorta dumb. It turns out, they mostly had no idea for what to have me do, too. I found some bugs. The main thing they asked me to do was to build a web page for our test team – which I did, but I didn’t even use Visual Interdev to build it. Hmm. A few weeks before the end of my internship, they came up with a new project idea. They had me spec what they called a “test monkey,” a new idea for a program that could test by randomly clicking around on the screen. I wrote a pretty good spec, or at least I thought so. And they gave me a return offer. In 1997 and the dot-com boom, it felt like they were pretty much happy to let people skate through internships and come back full time.
During my senior year, I knew I had to decide what I wanted to focus on “for real,” and I had at least gotten the hint that AI was not the right choice. I enjoyed some systems-level classes; topics related to compilers and operating systems. I decided to go for that. When the recruiter asked what I was interested in coming back to do my second summer, I said I wanted to be a developer instead of a tester, and I wanted to work on systems. So in the summer of 1998, they put me onto what was then the NT5 kernel dev team.
I had a good summer, and was more productive than the summer before. Though I was heavily intimidated by the fact that the intern at the desk next to me was rewriting the hibernation code in assembly. They asked me to solve a problem nobody was sure how to solve, by asking various people who knew bits of the answer. I solved it. In the end, the solution amounted to just writing an INI file. Not a masterful achievement in coding, but it was an achievement in problem-solving. Plus I wrote some test code and found some bad bugs in NT5. I also learned that men would come out of the woodwork asking if I was single, on an operating system team with no other women. I saw some bad engineering practices – things like header files copied in 15 places and all slightly modified from each other. I saw how large the team was, and questioned how much of an impact little old me could have on this giant product team. So when I got the offer to return full-time, it was not exciting like it was when I won the scholarship. I didn’t want to go back to Windows, or to Microsoft.
So I interviewed. Boy, did I interview. I had 10 flyback interviews and I think I got offers from ALL of them. Maybe not; I can’t honestly remember anymore. I wanted to work at all of them; I was still flattered by being selected. I didn’t pay attention to salaries. All I cared about were the products I’d work on, and where I would live. And I learned something – I didn’t want to work in the Bay area. I wanted to work in Seattle. I started applying for any job in Seattle, no matter what it was. But at that point I could only find one other company in Seattle (a little place that doesn’t exist anymore), and even though they were about to give me an offer too, I didn’t like them as much as Microsoft. I almost chose a file system company in the Bay area, Veritas.
But I got thinking. What OTHER system-level work did Microsoft do? I had heard about some small OS called “Windows CE.” They had to be a smaller team, and their product lean, un-bloated, efficient. Maybe that was the place for me. So I called my recruiter and admitted that I didn’t want to go back to work on NT5, but I wondered if the Windows CE team had any openings. So they flew me back for another interview, and I got an offer for that job. I made their dev manager spend some time on the phone convincing me their team was better than the Windows team. And I accepted the offer. That was a great choice for me.
What have been the adjustments you’ve had to make in terms of career (what led to changes in what you do for Microsoft)?
When I started at Microsoft, my start-up project was to take ownership of this logging tool my manager had just written. With the logger you could record different things that happened over time in the OS. You could investigate tricky bugs and performance problems. I did some initial work on this logger, and taught people how to use it. Then I spent a few years mostly focusing on writing databases, registry code, file system and kernel stuff. Because on a small OS team you do a lot of stuff. I learned a ton. I worked a lot with our Windows CE OEMs, too, answering their questions, blogging, giving talks at developer conferences. I loved that teaching and customer interaction. And all the while, I owned this logger, and was involved in helping people use it to debug things.
After about 5 years of this, I realized I liked working on performance problems, and while our kernel and file system were in good shape, our performance tools were not. So I switched to the Windows CE performance tool team, and I took ownership of my logger with me.
During my time working on tools, the product and team started changing. The team building a generic Windows CE OS for lots of devices, turned into a team building Windows Mobile, and then into a team building Windows Phone. I kept building tools, and investigating important performance and battery problems. But I started to plateau. And I got a new manager, one who didn’t really appreciate my skills or try to grow me. Looking back now, he had put me in a box, and I was bored. I should have left, but I didn’t think to.
Luckily, an old Windows CE friend came along. He now worked on the Windows Phone shell team. I had been thinking that the shell might be an interesting place to work. His team was always in trouble about performance problems, and he needed someone who could keep that under control. Within that single hour of discussing it with him, I pretty much decided to move right away. That was a GREAT move for my career – I learned a lot, and not all of it about technical stuff. I went from being on the central performance team, where everyone lived and breathed performance stuff, to being on a high-level feature team, where everyone was making pretty shiny new interfaces. On that team, the last thing anyone wanted was a performance bug. They were incomprehensible, scary, and sure to take weeks of human energy to get rid of. I learned how our internal customers – the feature developers we’d point out performance issues to – would receive those messages. I learned how to do a better job explaining problems, explaining tools, and being a good partner in bringing them to a solution. I learned the human engineering that was necessary for being a good performance engineer.
Our team and our product went through a lot more changes during that period. We switched from building Windows Phone on top of Windows CE, to building it on top of Windows. We had a whole new tool chain to learn, and a new security model too. I helped my team figure all of those things out, while making our performance better too. I did a lot of good work, honestly. I loved my manager, my team and my product. I helped the people around me get their work done, and mentored them too. Then my overall team got a new dev director. This director started asking why the heck he had a developer set aside for performance work – not much coding. He asked me to justify my existence, and let me tell you, that feels awful. He suggested that if I wanted to work on performance, I should go back to the central performance team. Instead, I pulled up our job-search site, found an interesting-looking opening with another team that I knew would value me, and I was gone within a week. It crushed me to leave the team I loved, but I didn’t want to fight an uphill battle against management that didn’t want me.
He apologized about that, years later.
The team I chose to go to, did nothing with performance. They worked with our Windows Phone OEMs, trying to sort out the messes we make as a big OS team where very few people look at the whole end-to-end solution we give to OEMs. It was an ambitious team, but I was feeling ambitious at that point. I wanted a promotion that I felt was overdue, and this was a good opportunity. I’d be working with OEMs again, which I missed from our old Windows CE days. And I’d get to work for Laura Butler, who is pretty much a goddess. She talked with me for an hour, told me how awesome I was, how much she wanted me on her team, and how much of an idiot my old director was for chasing me away. I floated on a cloud for 2 days after that pep-talk from Laura. From Laura, I learned how important it is to tell people they’re valued.
That move was the scariest move of my whole career. I arrived on a team with ambitious people I didn’t know, and they scared me. I went to meet one of the program managers I’d be working with, and he essentially radiated, “Why are you here, get out of my office.” I had just picked the worst person to start with, but I didn’t know that for a while because he scared me so badly I never even tried to meet the rest of the program managers. I never unpacked the goofy doo-dads and curios I usually kept on my desk. My office was all business, and I tried to radiate that at first.
It took a while to find a niche where I could make a difference, but I found it, and I got more comfortable. I spent about a year working with our OEMs. I got to do some traveling to meet and teach customers, like the good old days. I got my promotion.
Then a re-org eliminated my little Windows Phone OEM team. The program managers went to work with the wider Windows OEM team, but that team had no developers. My job no longer existed.
Our Windows Phone team still wanted me, so I went back to being a dev. My new manager tried to set me up to be an architect for that part of the team, but the immediate work that needed help was… performance. By this point we called it “fundamentals” instead of “performance,” because we now included memory, battery life, and other general OS issues in the purview of the area. I felt a bit “done” with fundamentals at this point, but there was a job that needed doing, and I had the skills, so I did it.
I and a new program manager started figuring out what work needed doing. After a month or so of this, my previous manager, the one who had been running the OEM dev team, came to me to tell me he had figured out what his now-charterless team was going to do. It was going to be the fundamentals team. My response was that *I* was the fundamentals team! His answer, with a smile, was “I know, welcome aboard!” I like to tell people that this was the only time I ever changed jobs, where my team followed me.
Now back with my previous team, but working with a slightly different group of developers, I was still feeling “done” with fundamentals. These new people had no experience with fundamentals, so I expected to help ramp them up and then look for something new. To get the team’s excitement and creative juices flowing, our leadership had us go through a series of brainstorming meetings and proposals about work we should be doing. I learned that this was an excellent way to rally a group of people who’ve just been thrown through a major change. And as I went through it, I realized there were a lot of different problems I would still enjoy fixing. So many, in fact, that I couldn’t work on all of them by myself. So instead of leaving the team, I agreed to lead part of it.
I had never been a team lead before, but I had been asking myself for years whether I should try it. Back on the phone shell team, I had greatly enjoyed being the most senior dev around – my team came to me, I helped and mentored them, and I didn’t have to do any of the icky manager stuff like performance reviews. That was pretty much perfect. I had fun leading this little Windows Phone fundamentals team. Problems were everywhere around us, but we were a small team with modest goals. We fixed what we could, built some tools and telemetry, and learned as we went.
About a year into this, the director of the Windows fundamentals team approached me. He needed a lead who knew fundamentals and Windows Phone, and anyone he asked about these credentials pointed him at me. He asked if I was interested in moving to his team. At this point, I was 8 months pregnant with my third kid. Moreover, the Windows Phone team I was working on was on shaky ground: it was looking like we might be re-orged, reduced in size, or even disbanded. But nothing had happened yet. I told him I was hardly going to change jobs 1 month before having a baby, and my team needed me to stay put to give them some stability. But if anything changed he could look me up.
Partway through my maternity leave, the team size reduction came. I volunteered to jump to the new team rather than forcing someone else to leave a job they wanted to keep. So I came back from my leave to a manager I’d never met, on a team I didn’t know, working on Windows fundamentals.
Back on the Windows team. You know, that team I had avoided so strongly I almost didn’t go back to Microsoft. I thought it was too large in 1998; it was much larger in 2015, and it was responsible for not just Windows but also Phone and Xbox. But I understood the scale of the team better. As an intern I had felt lost in a sea of people; as a much more senior lead I could see the structure of the organization. And there were a lot of people I knew from the Windows CE and Windows Phone days still around across the Windows team. I had also thought the Windows team had bad engineering practices in 1998; well, the whole industry did, frankly. We’ve learned a lot since then.
And luckily, I really liked my new manager. He gave me a team, and the charter of working on storage and memory. We were still responsible for Windows Phone fundamentals, and that’s where storage and memory mattered most. Storage/memory were familiar challenges, but still new and different enough to be interesting.
But oh, getting started on this team was a challenge. We were building Windows 10, and a million things were changing at once. I was still pretty new as a lead. I didn’t know my team, I didn’t know our tools, I didn’t really know our OS. Our program managers could read performance traces better than I could. When it came to fundamentals, I knew what was going on as well as anyone on the Phone team. But on the Windows team, I was a small-town self-taught kid who had just come to the big city. We had fancy tools, big systems, working at scale. I was used to a small team with small ambitions, and this was a bigger team with much bigger ambitions. I was not as *scared* as I had been with my OEM job change, but I was actually more lost.
Four years later, I’m still working on Windows fundamentals. I’m much more comfortable with our tools, systems, and people now. The Windows Phone product has faded away, but we have other interesting devices. I went from being a lead, back to being an individual contributor, back to being a lead again. I tired of working on storage and memory, so I recently changed to working on reliability (crashes). Different problems, similar tools, similar challenges.
Anything else that you think is important?
Here is an assortment of things I’ve learned along the way:
- You are going to have ups and downs. There are going to be times you know you are super awesome. There are going to be times you feel completely useless. Sometimes your rewards will line up with your impacts; other times you’ll be rewarded when you didn’t do much, or ignored when you did amazing work. Take what you can get, with a smile, and treasure your own knowledge that you can do great things. It will hold you through the tough times.
- People-skills are as important as tech-skills. You can build the most powerful tool, but it will fail if nobody but you understands how to use it. You can tell people what they’re supposed to fix, but they won’t fix it if they don’t understand why it’s important, how to fix it, or how hard it’s going to be. If it is your job to influence other people to do the right thing, it is absolutely vital that you are a good partner, not a boss. And the more senior you get, the more your job is going to revolve around influencing others rather than doing things yourself.
- It takes a lot of time to get to know yourself, and it involves getting to know other people. When someone asks you what you value, or what you are good at, it’s hard to answer those questions without understanding how you are similar or different to others. You like X, but everyone likes X, so that answer carries no information. You like Y, and few other people like Y, so that’s useful information.
- Even in software, there are many different ways to specialize. I work with data analysts and coders. I work with database developers, OS developers, tool developers, app developers, full-stack developers. You can write code, you can manage projects, you can work to understand customers, you can fix totally broken messes, you can investigate mysteries.
- Teams need a mix of people who enjoy/are good at a variety of things. The things I like to do are different from the things you like to do. If you and I are on the same team, we might save each other from doing work we hate. If we’re too similar, we’ll compete for the work we both like and neglect the work we both dislike.
- Flexibility is important. You can’t do the same thing forever. It won’t always be there, and you won’t be growing. Be willing to be scared or uncomfortable sometimes. The risks are lower than they seem.
EDIT: if you liked reading this, there’s more – There and Back Again: going back and forth between manager and IC
One thought on “Blathering About My Career”