David Fowler went from an intern to a Distinguished Engineer at Microsoft. That’s 11 different promotions all at the same company. I asked him about everything he learned by going through that process. We covered projects that had a significant impact on his career and his promotions. Also, since he’s been at the company for over 17 years he also shared big company tips he has and perspective on how Microsoft’s culture changed after Satya became CEO.
Check out the episode wherever you get your podcasts: YouTube, Spotify, Apple Podcasts.
Timestamps
(00:53) Microsofts leveling system
(10:18) First successful project
(16:22) Bootstrapping his own project
(25:44) His principal promotion
(37:10) His distinguished promotion
(49:51) Engineers he looks up to
(53:40) Expanding on his top tweets
(1:05:20) Big company tip on reorgs
(1:08:25) What keeps him at Microsoft
(1:17:22) Microsoft culture after Satya
(1:23:04) Career regrets and work life balance
(1:29:51) Advice for his younger self
Transcript
00:00:53 — Microsofts leveling system
Ryan:
[00:00:53] First thing I wanted to go over is, I think Microsoft's leveling system is a little bit unique compared to the other big tech companies. I see on levels FY that the leveling system goes from 59 to 70. And there's almost two levels per title, two levels per SD one, two levels for SD two, two in senior, and it keeps going on all the way down to distinguished.
[00:01:19] Can you explain the Microsoft leveling system a little bit?
David:
[00:01:23] I can't tell you why it starts at 59. I'm sure someone who's been there longer than me can tell you why it starts at 59. I believe there are levels below that that aren't engineering roles and that's probably why it has that system.
[00:01:37] When you join from college, you typically start at 59 or 60, depending on how many times you interned and how well you did. There's different things that go into it. But entry is 59, so that's like suite one at other companies. And then you progress in level. In Microsoft, there are things called level bands.
[00:01:59] So then you say there's like two levels per title. The title tends to be the band. You can say like, I am a junior engineer. You could be 59 or 60. You can't tell from someone's title which notch they're at. So there's 59, 60 is suite 1, 61, 62 is two, and then 63, 64 is senior, and then principal is actually three levels.
[00:02:28] I never really sat and thought about why it's done that way. I'm sure people that are really smart came up with those levels and why they're that way. But the principal level, the band is so broad. The depth of experience of the people in that band is immense. You could be talking to someone who is like the last level of principal band that's been there forever, or someone who just entered the principal band, like just came from senior.
[00:02:57] You wouldn't know from looking at their title. Beyond that is like no one knows, right? It's like levels partner that has three bands and then there's beyond partners, like Technical Fellow and Extension Gender. It's a broad system.
00:03:17 — Joining Microsoft
Ryan:
[00:03:17] So, that's the thing I want to dig into. You went through this entire thing, you started all the way as an intern. You've been there for your entire career and you grew all the way to distinguished. I want to go over that story. Could you tell me the story behind you joining Microsoft?
David:
[00:03:35] I went to college at Florida Tech. I'm from Barbados. I left Barbados at 18, like everyone else that goes to college. I was looking for colleges that had career fairs, and I chose one that was closest to Barbados, one flight home to the Caribbean from Florida.
[00:03:55] So that was a really convenient place I got in. My first major was computer engineering because I thought I wanted to do software and hardware, but in the first class I was like, Nope, not for me. I want to code. I have been coding since I was 10 years old. So that’s what I wanted to do.
[00:04:12] I changed majors to computer science. Did my first year of programming. I thought people that chose computer science had been doing programming their whole life and they knew what they wanted to do. But in the first Java class, no one knew what to code. I thought this was something everyone that chose computer science would do before coming here.
[00:04:28] I met one of my best friends, and to this day we are still best friends. We started to make games and worked on nights and weekends, making games for fun at school.
[00:04:53] By the time the first career fair came around, there were a bunch of companies that came in to see different students, and we thought to ourselves, how do we differentiate from other students? We came in with a laptop showing our game demo to all the recruiters.
[00:05:11] That first year we got like four offers for internships. I got Microsoft, GE, and a bunch of smaller companies in Florida. My friend went to EA, interviewed there, and got an internship. I went to Microsoft. I showed them the game, did interviews on campus, flew out, did full-time interviews, and got my internship.
[00:05:33] I interned twice, in 2006 and 2007. It was eye-opening coming from a small country to a big company, experiencing a big campus and big technology. Talking to really smart people and absorbing information was great. I was part of the last set of interns that got to go to Bill Gates' house.
Ryan:
[00:06:13] What was that like going to Bill Gates' house?
David:
[00:06:14] Historically, every intern group at the end of the summer got to go to Bill Gates' house.
[00:06:23] That was the main event, at least in my time. You would get picked up in a bus, and they would take all your technology. They would take away your phones, give you instructions. You parked out at a church, and they would take your stuff so you could take pictures. They would tell you what you can and can't do at the house.
[00:06:47] All the interns went to his huge mansion. I recall standing around talking to interns, not paying attention to what was happening. I remember seeing a rush of interns run towards me, and I couldn't figure out what was going on. I turned around, and he was behind me. I shook his hand, so I spoke to him once.
Ryan:
[00:07:15] When you interviewed for Microsoft at the time in 2006, was there lead code or what did the process look like at the time? What kind of things did they ask?
David:
[00:07:25] There's a book called How Would You Move Mount Fuji? It's a classic book about doing tech interviews. Microsoft created these lead code style puzzles that everyone loved to hate, like the puzzles that are like, why is a manhole cover round?
[00:07:36] When I was on campus doing the interview, they were asking me questions, and I had been prepped for coding interviews. I had been thinking about coding stuff, but I hadn't taken all the classes yet because I was in my first year of university.
[00:07:53] They asked me a pal and jump question. Super easy, not hard. I did it on paper with a pencil. Have you ever watched Die Hard 3?
Ryan:
[00:08:25] No.
David:
[00:08:26] There's a scene where Bruce Willis and Sam Jackson have to stop a bomb from going off, and there's water in a fountain.
[00:08:36] They have a five-gallon jug and a three-gallon jug, and they have to make exactly four gallons to avoid the disaster.
[00:08:45] I had seen the movie, but I couldn't remember the steps required to get that to work. In the interview, after the coding question, they asked this puzzle.
[00:08:55] You have infinite water, and you want to make four gallons with a three and a five jug. How do you do it? I sat there and thought, oh my God, this is hard.
[00:09:05] I figured it out, but it was funny because to me it was like, this is pre-code, not even thinking about solving some sorting question. This is just puzzles, like can you think through puzzles?
[00:09:16] The last question was how do you count the number of gas stations in Florida? I sat there and thought, is this a trick question? The guy listened to me and said no. I thought I had done really poorly, but they called me, so I was like, okay, I couldn't have failed miserably.
Ryan:
[00:09:42] That's so funny because people hate on lead code all the time. But these puzzles sound like they coach better than these puzzles.
David:
[00:09:51] I don't even know if you can prepare for some of these things. My last interview, my second last interview when I flew out and was on campus, I got asked how do I add two numbers in base negative two? That was my final question.
Ryan:
[00:10:13] It’s come a long way since then.
David:
[00:10:14] It's changed a lot. Some for the better, some for the worse.
00:10:18 — First successful project
Ryan:
[00:10:18] So going back to the story, after you had the internship, you committed for full-time. You had pretty quick career growth on the outset, and I see that there are a few pivotal projects that led to the upward trajectory past senior.
[00:10:34] I want to talk about the story behind those projects. For instance, maybe we can start with NuGet, which is the package manager. What's the story behind that project?
David:
[00:10:43] That was interesting because NuGet, I think we're like 10 plus years in now, is the package manager for .NET. When I think about the impact now compared to what it was when I started, it's kind of jarring.
[00:10:57] We started off building a brand new web stack and we were trying to compete with the LAMP stack, right? LAMP was Linux, Apache, MySQL, PHP, and we were competing with that from a .NET Windows server standpoint. Whether or not that made sense at the time, I didn't think about that stuff.
[00:11:17] The bosses above me told me we were doing that, so we built this whole new web stack. Ruby on Rails had come out concurrently, and RubyGems was a huge deal. We had seen that, but there was also a cohort in the company looking at things like WordPress and Drupal, which are packages too.
[00:11:45] The consensus was we need to have a package manager to pull in packages to extend the platform. The very first version of NuGet was this in-browser package manager, like a WordPress thing. I remember we had this meeting with Scott Guthrie, who is now an EVP, and it was all about Rails and Gems, and we had to compete with the package manager.
[00:12:11] There was a product manager who had mocked up screenshots and PowerPoint, and it was me working with an architect saying, can we just start from here? That meeting formed the NuGet team. I was the first engineer.
[00:12:30] There was an architect, David Ebbo, and Phil Hack, and we were the founding team of NuGet. There were other open-source nascent package managers in the ecosystem, and we had conversations with some of those people. We started off this mission to build a package manager for .NET.
Ryan:
[00:12:51] When you were building this, it sounds like it got critical adoption within the .NET platform. What did your performance review look like when you finished building this? Was that a really incredible success for someone who wasn't even a senior engineer yet?
David:
[00:13:10] Yeah. My first promotion came like eight months in. Even before NuGet, I had interned twice, so I had a lot of experience with Microsoft in general. I would work on the things I was assigned and then I'd work on more stuff.
[00:13:33] One of the things I did was troll forums looking for feedback for our products, and I would build features to solve them. I did that over and over and showed product managers and the team and architects, who turned out were my sponsors. Looking back, I think that helped me be in a place where I could build NuGet. I would look for problems to solve and attempt to code them first.
[00:14:12] I'm a code-first, ask questions later kind of person. My whole thing is code is currency. I can show you a working sample. It's not PowerPoint, it's not a document. Here's a working example of something. Oh, we should start there and then move on to something else. My review from NuGet was that I was getting really good reviews early in my career because I would just grab things.
[00:14:28] One of my directors at the time told me maybe five years ago that he would just tell people, "David has energy, go talk to him."
Ryan:
[00:14:45] You mentioned that NuGet grew way past what you imagined, and I know some companies have this idea of deferred impact where people continue to get credit for something they built that continues to pay out for the company.
[00:15:01] Did you see anything like that in your subsequent performance reviews?
David:
[00:15:04] Yeah, the bigger ones felt to me like a conglomeration of past success adding up plus success. I think at Microsoft, impact is supposed to be for the year, but when you're doing these, we call them band changes. When you jump across bands, it's a bigger promotion; within bands, it's a smaller promotion.
[00:15:26] If I go from 61 to 62, I'm still an SD2, but it's still worth a promotion. When you cross the boundary of going from two to senior or senior principal, you require more impact to make that leap. I'm not sure if there's an official deferred impact thing at Microsoft, but I remember it did come into play when I went to higher levels of principal.
[00:16:12] It was definitely not a one-off, like, "Oh, you did this one thing this year, you're promoted." It was about showing repeated impact over the last 10 years and whether we want to keep you going forward. So I think it did matter.
00:16:22 — Bootstrapping his own project
Ryan:
[00:16:22] You mentioned some other larger projects, so maybe we can talk about some of those. Yeah, there was SignalR.
David:
[00:16:33] The naming came from the time of Flickr and Web 2.0. Remove "er" from the end of things. I don't know why we called it SignalR, but that was a fun project. I had been working nights and weekends on this project, and I was enthralled with the fact that you could co-edit in Google Docs.
[00:16:59] I thought, can we do this for code? While doing it, I learned about web sockets, which actually hadn't come out yet. I learned how to build those kinds of apps, and that led to the creation of SignalR.
[00:17:16] There was a product manager on the team, Damon Edwards, who was also building a talk to describe how to build long-running streaming apps in .NET. I had seen his talk and said, "Hey, I'm building this thing. We should collaborate on this new library."
[00:17:37] We had been working on this thing until midnight every night. We made it open source, and people started to use it. It was still just two of us working on this, not really knowing what we were doing, just building this thing to make it work.
[00:18:14] At some point, a product manager at Microsoft said, "Hey, we should make this official." That was the first time I experienced building a project from scratch. Previously, I had been working on other people's ideas. This one was my brainchild. We built the prototype and the entire thing from scratch, and I was given the chance to have a team to work on it.
[00:18:35] I was never a manager, but I was the pseudo tech lead. We hired kids from college, and I ended up working on SignalR with a team of about eight. It was surreal because it was this random thing I built on a weekend that turned into a real project.
Ryan:
[00:19:12] What was the motivation for SignalR?
[00:19:14] What made you pull the weekends and late nights to build this thing that seems like it was outside of Microsoft?
David:
[00:19:21] I hadn't seen anything like it. When Google Docs came out, it was the first of its kind to work that well. It just felt super new, and I hadn't seen apps do that. How do we enable more apps to do the same kind of thing?
[00:19:42] SignalR was super new, and it was a really cool way of building apps that are chat and can send stuff from server to client. I think that drove me because I hadn't seen people attempt to do this before. We pushed the boundaries of the technology a bit. We hit limits all over the place in the tech stack, which became problems to solve deep in the core platform.
[00:20:18] The amount of problems we tackled made it enthralling for a developer.
Ryan:
[00:20:31] This is interesting because you grew through this project, and it was permissionless. No one handed it to you. There wasn't a manager or PM that came to you and said, "Hey, you're staffed on this project." You just went and built something, and it was so impactful that it led to a ton of career growth.
[00:20:56] I'm curious, is there some way for us to reverse engineer that for others? How do you go about starting projects where the motivation comes completely from you within a large organization?
David:
[00:21:05] If I had to boil it down to one sentence, you can just do things, and I think the way people talk about it now is you have agency. It often seems like you don't; it's really hard to find time, and I am not recommending people spend nights on the weekends working on all the projects.
[00:21:28] But early in my career, my main goal was to get better at software engineering. The way of doing that was to learn everything, like build anything. You can build games, websites, just build a ton of different things, and you gain experience from learning how to build those types of software.
[00:21:48] Right. So I think that was ingrained in me from really early on. The other thing that I did early on in my career was I found someone on the team that I wanted their career. On my team, there was an architect, David Ever. His job seemed really cool. He got to think about the future. He kind of spanned multiple areas of the product. He got to build the next wave of what was coming next. So I basically attached myself to him and I mimicked his behaviors. I said to myself, okay, I want that role. Let me make sure I'm seeing what he does that seems to work, and I want to keep doing that. I would be the coder of his ideas for a while, and that turned into learning how to do it on my own. I did this gradual thing where I attached myself to people who were like that. Then I found myself in that same position.
[00:22:45] Okay, here's a new thing. I have some insights. Let me try spiking a thing that will work. I communicate ideas with code. I would always build a prototype first, then show someone, show an advocate on the team, show the architect, show the PM and say, is this useful? Is it cool? I saw this issue that a customer was having, and I think this solves a problem. Do you think we can turn it into something? I think that pattern of doing that helped me gain insights into what helps people get over the hump of should we build something or not? I would build a thousand things, and maybe one would hit.
Ryan:
[00:23:27] It's interesting that you say agency.
[00:23:30] I think a lot of people who work at big companies or talk about big companies feel like it's difficult to have agency. They have all these projects that are assigned to them, depending on the team culture. It sounds like you had that agency through energy. You were moonlighting, going above and beyond. You did your normal stuff, but then on top of that, you had all this extra agency. Am I understanding that's how you unlocked agency at a big company?
David:
[00:23:58] I think it afforded me, once you build a reputation for being able to perform and build things, more things come your way.
[00:24:11] I don't want to say it is easier or it will happen, but in my case, a hundred percent, the more things I built, the more things I showed people on the team. People would just say things like, Hey David, we're building this new thing. We want to get your take. We want to get your opinion. Should we work on it? Can you help us build this thing? A lot of opportunity comes your way when you have a good rep for building stuff. I think further in my career, that showed very true for what happened after Signaller.
Ryan:
[00:24:45] You get a lot more of those permissioned opportunities when you have credibility, and permissionless agency is almost this hack to bypass credibility.
David:
[00:24:55] The funny thing is you get a chance to be more permissionless the better your track record is. The more success you have, the more leeway you get to fail, which gives you space to try more things.
Ryan:
[00:25:15] Yeah, that makes sense. I've seen that a lot.
[00:25:18] The very high fast-growing software engineers are almost this weapon that management and people around them say, we trust you. Go do that thing that you do, and they can go and try all these risky projects. If you were someone who is struggling to meet expectations, a lot more directed opportunities are being handed to you, and you're being monitored.
[00:25:40] I can totally see that this is so true. Going to your late-stage promotions, you got the promotion to principal, you got the promotion to distinguished at Microsoft. I'm curious, what is the thing that led to the promotion to principal?
David:
[00:25:57] Principal was interesting. I had one boss who told me when I got the senior that my promotions would slow down, and I remember that meeting where I sat down and got the promotion. I was really happy; he kind of gave me this downer. Don't expect more promotions from here, because I was like, what does that mean?
[00:26:17] I really took it to heart, but the jump to principal is a big jump. I had been working on SignalR at the time. If you ever use Heroku, Heroku pioneered git pushing and deploying your app instantly. We built a tech called App Harbor for .NET, this company doing the same thing for .NET.
[00:26:43] We built a similar thing for Azure. This was super early in Azure's timeframe. We built this brand new thing; it's actually still there. It's called Kudu. I had been working with the same architect, and I built it with him. At some point in that timeframe, I got pulled off of that.
[00:27:05] This is one of the places where your track record helps set you up for future opportunities. I had my director tell me, Hey, we have this new thing spinning up, and we need you to go work on it. Obviously, when you're working on something else, you're like, man, I want to finish what I'm working on. But then this thing happens, and you're like, okay, I'll help you with this thing. That ended up being the beginning of the new .NET, .NET Core, the rewrite, cross-platform and modern. It was a big opportunity; it was scary at first. What do you mean you're the architect?
[00:27:46] I was senior. It was me and another principal engineer that got chosen to be the architects of this project. I hadn't had experience working at that scale before because we had like 30 engineers working on this project. We had free rein to build whatever we thought was right. That was amazing and terrifying. Through that project, I learned a ton of things, like knowing how to manage a project and architecture and scale. Initially, I was trying to co-review every single change you could imagine, and that burned me out within a year.
[00:28:29] It was like, okay, we can't do this anymore. We have to figure out how to trust people and scale and figure out what's important, what's not, what's urgent versus not urgent, et cetera. That year, I got promoted; I actually had my first kid, and I got promoted to principal that same year I did the first year of .NET Core design and building it.
Ryan:
[00:28:53] You mentioned that the team grew so much that you had to scale yourself out of necessity. What are the things that you did that allowed you to be an architect for so many engineers without burning yourself out?
David:
[00:29:08] So I learned some of this during Sigr. The smaller version was Sigler only had like seven or eight people overall, right?
[00:29:16] Engineers, tech, product managers. And we had two new hires. I had never had the experience of delegating in a way where I thought it was to grow you. I was always like, I'm a senior engineer, I can get this done faster than you.
[00:29:37] We had really smart engineers that we hired from college, and it took me a while to get past. It's gonna take them longer at first, but once they understand all the stuff, then we can amplify the impact. Once I saw that, it flipped my brain.
[00:29:59] I had something from the Sigma Preprint that was like, okay, if you can invest in people and get them on the same page as you, if you are on the same wavelength, if you can delegate more, then you can get more done as a team. You begin to think about outcomes and less about the work you're doing individually.
[00:30:20] The leap from senior to principal feels like being able to do more through others than yourself. It's where a lot of people end up plateauing because software engineers are very, we want to code, we want to be alone, we want to build things ourselves.
[00:30:40] Software engineering is a collaborative event. We want to figure out how to get customer feedback, figure out what to build, figure out how to build the best way. That change in my brain prepared me for .NET Core because it was such a bigger scale. How do you even begin to manage that many people, that many facets?
[00:31:02] We rebuilt everything from scratch. We literally rebuilt the package manager, the runtime, the libraries, everything from the get-go. It was overwhelming at first. What helped a lot was not treating everything as equally urgent. If this change over here went in and it wasn't perfect, I wouldn't be like, we can't merge this.
[00:31:25] It needs to have this interface, these tests. Learning how to set foundations for others and to trust others and letting people fail was a really hard thing for me. I could avoid the failure, and it turns out that a lot of the things that get you to senior and maybe principal hurt you even further.
[00:31:52] Being a control freak, being someone who is amazing at their job, getting stuff done in a very specific way doesn't really help you when you want to lead a thousand engineers. You have to figure out how to inspire others to do the same as you through different means, like one-on-ones or being an example or more different techniques.
[00:32:13] It's difficult to just type harder and make a bigger impact. I shifted my brain to be outcome-focused. It was a big change.
Ryan:
[00:32:25] You mentioned the architect title or I guess role. What does that mean at Microsoft?
David:
[00:32:32] That's a fun one. When I joined, I saw someone who was a principal software architect.
[00:32:37] I said to myself, that's the role that I want. I don't know what it is, but that's what I want. It's kind of a semi-official role at Microsoft, and at certain levels, the middle principal bands, you can be one of these architects. To me, it really means you're more breadth rather than depth.
[00:32:55] You're overseeing the design of the overall system. We have different engineering archetypes. At the highest level, you have someone who's a super coder, who is just gonna build so much stuff. There are people who work on really deep technical details that have a huge impact.
[00:33:16] We have one of the foremost GC experts in the entire world working on the T.NET garbage collector. You could be someone overseeing a hugely impactful area of the product. There's a lot of space to figure out what archetype you want to be.
[00:33:38] The architect role for me felt like breadth. I was the architect for .NET Core back in those days, overseeing the design of the whole stack, the web framework, web server, how we ship packages, the entire engineering idea. I'm not the engineering lead; I'm the architect.
[00:33:59] I'm trying to vet the decisions that are gonna last for 20 years. If we do this change now, we can't do this thing in five or ten years. I hadn't had experience doing that before, but I had really good mentors who had done this. I had been watching and shadowing and trying to understand through experience how to build systems that last 20 years.
Ryan:
[00:34:24] So as you've grown to distinguished engineer at Microsoft, how has the percent of your time that you spend writing code changed?
David:
[00:34:32] It's funny. I think there is what your job is like. Do I have to code every day to do my job? I don't know if I get rewards anymore for coding. I get rewards for outcomes.
[00:34:46] But for myself, selfishly, I code every day. My team knows that I send lots of pull requests every day to the code base I'm currently working on. I have a new project I'm working on this year, Aspire, and I code a lot. I personally make sure that when I'm working on a project, I'm somewhat involved in coding still.
[00:35:12] I don't want to be the architect who doesn't know the code and is giving people instructions like, you should do this, and I'm gonna go away now and disappear somewhere else. I want to be the person who is a peer on the team. I want to be everyone's peer, and I want to be facing the builds and doing the tasks. There isn't any work that's beneath me.
[00:35:35] When I'm on a team, I typically work as an engineer.
Ryan:
[00:35:44] If you stopped coding right now and just kept leading the team, would your performance review look fine?
David:
[00:35:53] Yeah, I think so. Distinguished engineers are definitely about company-wide impact.
[00:36:01] My day job is making sure the architecture as a whole is sound and good and moving forward. A part of my job is looking forward, talking publicly, inspiring people internally, and mentoring people.
[00:36:25] There are a lot of things I do that aren't like what I used to do that help with impact. For example, I gave four talks internally about how to use AI to do software engineering. That happened because I had been using it myself for a lot of different things, and someone said, hey, you should give a talk to the team.
[00:36:48] Think about the impact of those things. They help when you see engineers who aren't just your boss telling you to go do something for seemingly bad reasons. Engineers who are credible telling you how they do their jobs. I do a lot of that stuff too. A lot of things are not software engineering, to be frank.
00:37:10 — His distinguished promotion
Ryan:
[00:37:10] When you got the promotion to distinguished engineer, what's the story behind that?
David:
[00:37:15] Absolutely insane. Distinguished engineer is the final level of partner. If you go onto the level of FYI, you'll see level 59 to 80. I think the last is 80. Distinguished engineer is 70 on there.
[00:37:35] There's an official process to get that title. It's not a promotion you just get because you did a great job that year. A set of technical leaders have to peer review and decide if you are worthy or not.
[00:37:59] It was probably the craziest promotion I've ever experienced, mostly because of the people at Microsoft. For example, Van Ross, who created Python, is the same level as me. Maximum imposter syndrome. I'm young for that role too. When I was going for that role, I thought that would affect me as well.
[00:38:22] It didn't, but I felt it would. I had all these hold-ups about whether I was really at this level, if I could perform there, if I could do well there. All the work I've done in the past helped because you need a body of work and a good track record to qualify for these kinds of roles.
[00:39:09] You can't just become a distinguished engineer because you had one fun year. Some of the criteria end up being what you have contributed that impacts company-wide things. A lot of it is deferred impact. When I went from principal to partner, the email had .NET Core's impact, and that had been about seven years.
[00:39:38] It wasn't like I did it last year or the year before. I had been the architect to help people adopt the new .NET internally and had done that for a bunch of different teams. There was all of this buildup to deferred impact. I think all those things helped signal how the thing you helped build and mold impacted the industry and the company. Those all come into account when the fellows decide who becomes a distinguished engineer.
Ryan:
[00:40:19] Were you involved in that process at all, or was it a surprise when you got the distinguished promotion?
David:
[00:40:24] I was involved from the point of view of helping my leadership with content. I gave them all of my contributions to things I've written, like papers, and code contributions to various projects. I kind of gave them the raw material. I didn't do anything else.
[00:40:45] What made it impactful for me was seeing the other fellows at knowledge and say, well deserved, and it's about time. Okay, maybe I should be here. This is good.
Ryan:
[00:40:59] You mentioned the lofty expectations of this distinguished engineer level.
[00:41:04] Is that something that you worry about now that you've been acting in the role for a while?
David:
[00:41:08] At first, I would tell people I am a baby d. I've only been here a couple of months, or it's been one year now, and I'm not sure yet. I think now it's been two and a half, three years now.
[00:41:24] I feel pretty confident I can perform at this level and I think I understand what is required. Initially, very much yes. My first review cycle, I felt pressure to document everything and just write down what I thought were all the impacts. It felt very much like, oh my gosh, I need to make sure I'm writing all this stuff down.
[00:41:50] Tell my boss what I'm doing, making sure he knows, because you're almost an executive at the company. You're at the level below being an executive, and it's super scary to think about having to have that impact every year repeatedly.
[00:42:08] I found a pattern for making sure I had the right level of impact, talking to my bosses, making sure I was visible, making sure I'm doing all the right things. I don't feel the pressure as much now, but who knows? Things could change.
Ryan:
[00:42:28] So you went through 11 promotions, which is kind of ridiculous. You went all the way from the beginning to then, and the crazy thing you're saying, Guido, the creator of Python, is at that level as well. I can't even fathom, because apparently there's one last one.
[00:42:48] The technical fellow. What does that Final Boss level even look like?
David:
[00:42:53] So the people who are fellows, tech fellows, I guess the one that everyone idolizes in my division is Anders Helzberg, who made Turbo Pascal, Delphi, C#, and touch grips.
[00:43:10] No one's competing with that dude, because you can't repeat building four successful languages.
[00:43:18] If you think about the archetype of someone who is a fellow, it's that level of impact. The people who built the Windows kernel, there's one guy, Dave Cutler, who came from DEC back in the eighties. He helped build Windows NT, Azure, and the hypervisor for Xbox. He is the only senior kind of fellow. That's just his title.
[00:43:41] At those levels, everyone's a unicorn and everyone has their own path. You aren't trying to follow people's paths one-to-one. You're looking for proxies. To be a fellow, you need industry-wide impact, not just impact in your division or company. You need to do something that impacts the industry.
[00:44:07] I think we hired someone recently who is a fellow who invented RSS. It's that level of thing. You built something that became the industry standard for the internet.
[00:44:31] There was a guy on my team who was the intern for Tim Berners-Lee, and he is on the HP spec. Those are the kind of people that end up being fellows, I think.
Ryan:
[00:44:47] Were there any unexpected perks of getting voted to distinguished engineer?
[00:44:58] At a lot of companies, when you get promoted to a certain level, you get added to special forums that only distinguished engineers have access to.
David:
[00:45:19] The coolest part, there's an email alias called engineer that is all the DEs at Microsoft. That's awesome. That's one of the perks. There is an internal forum where we all meet every couple of months. The way this typically works is you have a sponsor.
[00:45:36] When I was going to be a DE, I told my mentor I wanted to be one. I had mentors who were fellows. One tip: when I became a partner, I told my management that I wanted a mentor who is a fellow because I wanted to be one. I figured if I wanted to be one, I should have mentors who can help me get there.
[00:46:03] One of my mentors, who was very impactful in my career, invented PowerShell, Jeffrey Sno. He was one of the best mentors I've had. He left Microsoft and went to Google recently, but he was really impactful for me. He was one of my main sponsors.
[00:46:24] I ended up going to one of these tech leaders forums where I got to mingle and talk to all the people who were there. It was really interesting.
Ryan:
[00:45:09] You mentioned that mentor was incredibly impactful. What were the things he was telling you that made a difference?
David:
[00:46:34] A lot of people sugarcoat how to get promoted and give you very generic feedback. You have to do a project that's super impactful. He was very direct. We should go talk to the people who decide and ask them where you are. It jarred me because I never thought about asking the teacher for feedback. No one ever tells you, you have to do X to get promoted.
[00:47:14] It never works one-to-one. You have to have more impact. Make sure you're working on something that's super impactful. He was like, let's go to the source, talk to the CTOs, and figure out what it means for you in your role.
[00:47:31] That was super helpful because it helped me understand what I should and shouldn't be doing in a very real way. It wasn't just arbitrary advice. I had a second mentor, and I had done some feedback from different people in the company, your manager, your peers, etc. It gets turned into a package that tells you your strengths, what you're good at, what you're really bad at, and how you act under stress.
[00:47:55] My first reaction was, oh my gosh, I'm going to have to fix all the things I'm bad at. My mentor was like, no, take your strengths and amplify them even more. You could work on the things you're not good at and be average at those, or you can work on things that you're really good at and be superhuman at those things.
[00:48:16] It broke my brain because up until then, I had been thinking about how to make sure I was better at everything to be a well-rounded individual. No one gets promoted to these roles for being average. You have to be superhuman in something that you're really good at.
[00:49:08] If I form a team, I'm not the one that's going to schedule meetings or go through every detail of how we ship. I am super bad at that stuff, and I will make sure I have someone who is really good at that so I can focus on what I'm good at. It helped me reframe how to think about amplifying what I do well to get more impact.
Ryan:
[00:49:37] Makes sense. It's kind of like a power law type of thing. At the top is where there's the most insane returns. Just take those things and go further on that exponential.
00:49:51 — Engineers he looks up to
Ryan:
[00:49:50] You mentioned a lot of impressive engineers, and I think as a distinguished engineer you have a unique perspective because you can see what is impressive with a critical eye of a great engineer. What are some examples of other engineers that you look up to and what makes them impressive to you?
David:
[00:50:10] I can talk about some of the well-known ones and then talk about people that I work with in general that are impressive for different reasons. My current team has five other partner-level engineers who have been here 20 plus years and are really good for different reasons, like experts.
[00:50:31] One person is a super coder; he codes 10x so people complain about others not being 10x. He produces way more code than everyone else combined. There's one guy who seems to know everything about obscure things you would never understand in your life without having seen it yourself.
[00:50:56] There's all kinds of stuff about C, stuff about compilers, stuff about the OS, and you're like, how does he seem to know everything about everything? Then there are engineers who just seem to know what to build and have good judgment. I'm on the design review team.
[00:51:15] We meet every couple of months and review C# features. I'm there with Anders Hejlsberg, who made C#. The way he communicates, the way he gives feedback on what feels good and what does not feel good, he always does it in a way that is not talking down to you.
[00:51:46] This dude invented four languages that everyone uses, and yet he can still talk about it in a way where it's like, you know, some people are really smart and they talk down to you, and you're still dumb. He does it in a very pragmatic, practical way, but then you see the coding commits and you're like, dude, this is technically insane.
[00:52:10] I admire watching people like that spread their impact. Markovich, who's CTO of Azure, famous for his Windows tools, still codes, and it blows me away sometimes. He sent an email two days ago, and I was like, holy crap.
[00:52:37] It was a very dev-centric email. It wasn't high level; it was like, no, I wrote some code, I improved the performance, and here's the result. I think whenever I see high-level engineers still coding like that, I get really inspired.
[00:52:58] It's really easy to fall into the meeting trap. When I went partner, I fell steeply into the meeting trap of being in meetings all day, every day, and I got really sad. My mentor said, as an IC, your job is to think and build stuff. So minimally, on your calendar, block eight hours a week to do that stuff.
[00:53:28] It took me a while to change my brain to say I can just say no to meetings. Decline, decline, decline, decline, decline code.
00:53:40 — Expanding on his top tweets
Ryan:
[00:53:40] So I think the next set of questions I want to ask you, because you have a public presence on Twitter, there are all these top tweets that I think are really interesting short thoughts that I'd be curious to have you expand on.
[00:53:54] The first one is talking about university courses. You said there should be a university course that explains how to refactor code, how to make changes to it without breaking an existing code base. If you were to design that course, what would some of the key concepts be?
David:
[00:54:18] Having been working for this long in the industry, computer science is not software engineering. It's not even close. Computer science is learning the science of computers, bits and bytes, the math and algorithms. You do a little bit of software engineering, but it's nothing like software engineering.
[00:54:39] When you get your first job, you spend a lot of time just trying to understand what's there so you can surgically make your first change and not destroy everything. Don't break the build; don't break everything else. If I were to have a course, you would be thrown into an artificially big code base.
[00:54:57] It would have to change every year because students would just copy the previous year. Your job is to make a bug fix. You have to fix a bug in this code base and write a test for it. The skills you learn being a code architect, a code archeologist, are so different from just writing a code question or doing a homework assignment that is just one thing in a textbook.
[00:55:31] You learn a lot of adjacent skills from just trying to figure out where to put the code in the first place. I think it would be super useful. Every assignment is making one fix, and maybe you can set up the code base such that it's not super hard to figure out what it is.
[00:55:50] Anyone with enough time could figure out and make this one triple change and add one test. A lot of people's jobs are tweaking software that is already there. Not everyone gets to create new software. If you work on Windows, sure, you'll build new components, but you aren't going to change the kernel unless you're doing a new OS. So yeah, super useful skill.
Ryan:
[00:56:16] I think there was another set of tweets that I saw around the idea that tech interviews are focused so much on writing new code. But actually, the real high leverage skill is debugging it. What gives you that thought? Maybe you can expand on that.
David:
[00:56:31] Early in my career, I worked with a ton of engineers on the Donna team, and we had a lot of engineers who just worked at the platform level.
[00:56:42] I got to see firsthand people diagnose crazy crashes, race conditions, threading issues. I had a firsthand seat to watching people's mindset when they go to diagnose issues. I thought to myself, there are kind of two skill sets. Maybe you learn some coding, but they're just not the same skill set.
[00:57:04] If you think about building an application, deploying it, shipping it, and then getting crash reports, trying to resolve issues, there's this second skill set that is just not writing. It's not authoring code. It's how do you even think through debugging issues?
[00:57:27] How do you know which thread caused the exception? What tools do you use? How do you think about it? It would be fun to have an interview where you give someone a crash dump or something like, hey, this app just crashed. Figure out what the problem is. You want to see what they start doing. Do they start adding logs? Do they rerun the program? How do they think about race conditions?
[00:57:47] All these interesting things come out of watching someone try to diagnose problems. I have the highest respect for engineers who can be thrown into a problem situation where they don't know the code base super well.
[00:58:15] Super fun story. I remember being, this is early days in Azure. There was this very, I can't remember what the site was, but there was a very popular site that was going down and was running on Azure. And I'm in like, also, I was up late, it was 1 and my CVP sends me a message like a DM.
[00:58:41] It's like, hey, you free? I'm asleep. What? Yeah, I'm free. I get added to a call that has like a hundred engineers trying to debug why the site is crashing. We called the team who was working on it; it was some other company, but we were helping them as engineers at Microsoft trying to build the issue.
[00:59:05] You could see the different people's skill sets trying to figure out what the issue was. We solved it eventually. It was a concurrency issue somewhere in some dictionary that caused a race condition. I thought to myself, this is one of the skills that you need to have as an engineer.
[00:59:21] Writing code is just a small piece of your overall skill set. Learning how to debug and think through issues is another big chunk.
Ryan:
[00:59:31] As evidence of that being very impactful, I know some companies have different archetypes. You mentioned the super coder, also known as the code machine in some places.
[00:59:44] There's also the archetype fixer, which is really cool because it's been described as someone who drops in somewhere, makes a one-line change after tons of investigation, and it gets two times better, three times better, or something like that.
David:
[01:00:00] Oh my gosh. We have some engineer on the team who, there'll be a thread.
[01:00:05] I get started off all perk issues somewhere in a gRPC call, and I'll add the engineer to the thread and say, hey, can you look at this? Boom, boom, boom, here's a trace, and I'm just asleep. Oh my gosh. It's solved.
Ryan:
[01:00:20] So impressive. Another tweet that you had I thought was really interesting says, lukewarm take: the lower on the technology stack you sit, the less mistakes you're allowed to make. What made you think of that? Did something break super low level in the stack somewhere?
David:
[01:00:40] I work on the platform, so the way we think about software is way different from higher-level services or even web printers. A lot of things break that are just kind of insane.
[01:00:57] The things that we change that break services are absolutely unheard of. We will change the order of how things come back in a method, and it just snaps some company's website down. When you work at that level, you get an appreciation for the kind of changes you can and can't make.
[01:01:24] I think that tweet was inspired by one of these bugs because at that time, I had been working on first-party adoption of .NET, and we had seen a couple of people upgrade and hit issues that made us completely shocked. It was like, how did you find that bug? No one has that. What do you mean you have 400 arguments to a method? That's not normal; there are some limits in software that can be a real problem.
Ryan:
[01:02:00] There's another tweet here and that is really interesting. It's about promotions. You said that when you got promoted to a senior software engineer at Microsoft, you remember thinking that other people were smarter than you and should have been promoted first.
[01:02:13] You would've thought they would be angry, but the opposite happened. Actually having good coworkers matters a lot and people weren't. Yeah. What's your thought there?
David:
[01:02:26] This is bringing back some good memories. I remember when I was going to senior, I was actually a little worried about getting promoted before other people because I had it on a really fast path and I thought maybe it would make people jealous.
[01:02:43] When I joined my team, I think there were four people from MIT and two from CMU and I had gone to Florida Tech. I was like, okay, these people are way smarter than me. My way of working through imposter syndrome was just to work really hard and be a busy bee doing stuff.
[01:03:05] I think I understood that when I got promoted to senior, impact was not about being intelligent. It was not just about getting the highest grade or being smart. It was about whether the things you were working on were impactful. That was the shift where I began to understand that it's not just about what I know.
[01:03:27] It's not just about this person on the team being really smart in area X. It's about taking all that and producing something impactful. That promotion helped me see that was the new GET thing, the SignalR thing. That's how you get promoted. That's how you add impact for the team.
[01:03:46] It's not just about knowing this feature or this area or this OS because I always felt like I didn't know enough about technology X or area X. I had to go deeper and learn more. The question was always, is that for you or is that for your career?
[01:04:03] Right. What's it for? You don't have to know how, I don't know. Maybe you should, but you don't have to know how TCP/IP works to get promoted to senior. I'm sure people don't know the details of how it works. I think that promotion helped me separate being smart from making an impact because promotions impact these promotions.
[01:04:31] Being smart is just knowing more stuff and being helpful for solving problems. The second part was my coworkers were happy for me, at least outwardly. I was really worried at the time because it was like a new person joins, team gets promoted really fast. Do people see that as why not me? Or do they see it as, yeah, that makes sense?
[01:05:17] When I asked questions about other people who kind of went up really fast during my period at the time, they would say things like everyone knew it was gonna happen. There are certain people where people kind of know when it happens and you never know if that's the case for you or not, or if people are just like, I don't think that person deserves it.
01:05:20 — Big company tip on reorgs
Ryan:
[01:05:20] So you've been working at Microsoft for over 17 years now, and one of the tweets you have is talking about big company tips. It says before you change roles, ask when the last reorg was.
[01:05:37] What's the thinking behind that?
David:
[01:05:39] Big companies are a machine. I remember someone telling me really early on that when you're an executive vice president at these companies or a CVP, you show that you're doing something like it's motion, like reorgs are motion.
[01:06:04] Motion means you're changing stuff. The only constant is change in these big companies. There's always a reorg plan, there's always a reorg coming, and there's always a reorg that just happened. You're trying to figure out in between the reorg moments who the leaders are, what the impetus was, and what caused it to happen.
[01:06:26] You can never know when the next one is coming, but learning about the previous one is super important just to understand where you would be heading in that dimension. My org had a big reorg recently; the previous meta person now runs my org.
[01:06:45] I think it's super important to know that because it helps you figure out what the purpose is now. If it just happened, it tells you a lot about where the org is heading, where the team is heading, and where things are going. It's easy to change teams or move around without thinking about the overall direction the org is going within Microsoft.
[01:07:10] Every new org is a whole new company. It's definitely worthwhile trying to figure out what the goals are of that org and what happened last time. I tweeted that after talking to a mentee who had been through four reorgs in a row or something like that, something crazy.
Ryan:
[01:07:36] I see. So you're saying you should read the behind the scenes of the reorg and what that means for your career in the future.
David:
[01:07:43] I heard someone say something to me recently that was really good advice. When you're looking to change jobs, don't think about the things you love because they'll be easy to do.
[01:07:54] Think about the things you hate. What can you not stand about working in the area or environment? If you see that, that'll be the thing that will be hard to get around or work through. Let's say you hated open space and wanted a closed office. If the company was open, don't go to the company that is open space because then you'll be unhappy. There are better examples that are probably more relatable, but that's a simpler way of describing it.
01:08:25 — What keeps him at Microsoft
Ryan:
[01:08:25] You've been at Microsoft for a long time, your entire career, even including your internships.
[01:08:30] I'm curious what has kept you at Microsoft this long.
David:
[01:08:35] Every time, I think about this myself a lot. What keeps me here? I think I am part of the generation of millennials who brought the curse of our boomer parents trying to stay in the same place forever.
[01:08:52] I have a lot of friends who jumped around and got paid for it, and it was really good for them in their careers. I want to say I maybe didn't take the same path and it kind of worked out. I had a couple of times where the most impactful time I almost left was when I was senior.
[01:09:12] My boss left and went to Twitter, pre-IPO at Twitter, and a year in she pings me and tells me to go interview at Twitter. I actually interviewed at Twitter and GitHub at the same time. I got both offers, and the offers were pretty good.
[01:09:36] It was the first time in my career where I was at a crossroads because my career had been going fine. I was working on SIGIR; I was on the up and up, but then here's this offer that seems a lot better. They were pre-IPO companies. Should I go? There was a lot of deliberation about whether I should go or stay.
[01:09:57] I ended up staying, and it worked out. But I will say the morning Twitter went public,
[01:10:10] instant depression, I was depressed for like a week.
Ryan:
[01:10:21] What kept you at Microsoft? It sounds like those offers were better than what you were making at the time.
David:
[01:10:27] Yes, they were. They countered, and the counter was fine. Looking back now, it was pretty good, but it was fine.
[01:10:38] They had me talk to our executive vice president, and he was like, you're gonna be a distinct engineer in five years. He definitely oversold, but for me, it wasn't just the money that made me stay. I had been working on something that had built up, I had been getting a lot of autonomy at Microsoft, and leaving would've been like starting over.
[01:11:05] One of the things people don't talk about when changing roles or leaving for a better offer is you build up a network, a network of people, a track record. I could work on what I wanted to work on at that time. I think I had been given more autonomy. When you're weighing whether to stay or go, money is one thing.
[01:11:31] The other is the people. Are the people good? Not just good engineers, but good people you want to work with? The people aspect, the money aspect, the network aspect, all these things matter. I think I stayed because at Microsoft I had been getting my fix of working on a new thing every couple of years.
[01:12:12] If you look at my LinkedIn, there's a new project every two years. That was by design. I think it helped me not get bored. I didn't feel the need to go somewhere else to do what I wanted to do because I felt like I could do it at Microsoft. That kept me here for this long.
[01:12:33] I won't say I hadn't thought about leaving every now and then. It does connect in my brain every now and then, but so far the people, the pay for me is fine. The people, the pay, the project, and the impact I get to have working on what I work on is a big thing for me as well.
Ryan:
[01:12:55] Do you think that if you had a mentee today facing the same decision, they're at Microsoft, they're doing well, and they have a pre-IPO OpenAI offer or something better than what they have now, would you tell them to stay at Microsoft or would you say maybe go with the risky thing?
David:
[01:13:18] I would tell 'em to go.
[01:13:23] So, fun story. I actually had a mentee who got an offer from a different company, but they weren't in a place where they could do their best work. So the combination of the offer plus that, I was like, you have to go. I said, they're gonna counter. You have to go. You can't stay here. You should go.
[01:13:46] If I had that for myself, maybe I would've been gone for that.
Ryan:
[01:13:53] You had this interesting tweet on job hopping that I thought was maybe relevant now, which is that you said once in your career you should work on a project long enough to see the long-term impact of your decisions.
[01:14:07] It's a humbling experience.
David:
[01:14:09] That's a good one.
Ryan:
[01:14:09] That's a good one. So it could be better for long-term growth in some cases.
David:
[01:14:16] Yeah. So that tweet was inspired by my career, which has always been this, work on a thing and move on. I would still have ties to the thing I worked on, help people that are working on it now whenever things go wrong.
[01:14:30] But the thing that I have worked on for 10 years, .NET Core, was the longest I've ever worked on anything in my career. And I think it was a good change because it really helped me appreciate deciding to do something in the first two years and then seeing the impact of that decision, whether it be bad or good.
[01:14:56] It gives you a whole new skillset and perspective on how to make decisions. For some things, it is obvious and you can say, okay, well we didn't understand at the time the scope or the scenario, but things that didn't seem important became important. One of the jokes I make about working on something for 10 years is that all the small issues you thought were small, that you could do later, will become big issues at some point.
[01:15:26] Like somebody will hit everything that you punted, and it all happened. I think maybe if you think about 10-year projects, 20-year projects, who knows if it's good for career growth? Maybe not. If you work on the same thing for 20 years, it might not be great, but it'll teach you a different skillset. You get to understand the implications.
[01:15:54] You get to understand if you were gonna put the next version out, you would have much more insight into what you messed up. It's really hard to appreciate what you messed up when you do a thing and leave. You should be on a new project. But I don't fault anyone for doing both things.
Ryan:
[01:16:13] Yeah. I could see it better for developing judgment. But I could also see it being, you know, imagine a career that's a leg of jumps. Assuming every jump is higher than the other, that person's probably gonna have a lot of career growth. But if all the projects they start just kind of go downhill once they leave, I wonder what it does for their pattern recognition judgment.
David:
[01:16:38] Yeah, exactly. It's funny, I told someone I don't know exactly how to describe the ingredients that make up a successful project, but I can tell you when I'm working on one versus when I'm not, and that is built up over time and experience, seeing which things work out and which things don't work out.
[01:17:01] It's kind of fine-tuning, I guess, an internal model in my head. Like, okay, this has the smell of something that can be stressful versus not. There are some things here that I'm seeing that work out well and some things that are not working super well.
01:17:22 — Microsoft culture after Satya
Ryan:
[01:17:16] Coming to the end of this, I kinda wanna ask you some high-level reflections and things.
[01:17:22] One thing I'm curious about, because you're so high up at Microsoft at this point, and you've been there for so long too. I know the common perception is pre-Satya, Microsoft was very different from post-Satya, at least in terms of stock performance. Did you notice anything internally like the culture shifting when Satya became CEO?
David:
[01:17:44] Huge. I always tell new hires that it's really hard to think about the culture shift between Satya and Balmer because I lived it. It's hard to see the big jumps from where we are now to where we used to be because it literally happened gradually. Things were rolled out, and there's a lot more collaboration.
[01:18:14] The culture just changed completely. One of the biggest changes I noticed was that when I joined, there were teams competing on the same project. Microsoft used to do this thing where two teams could work on the same end state, and then one would win. There was a big focus on collaboration over just being the first to do something. I never experienced it myself on my team, but I definitely worked with teams who were building solutions before knowing what the problem was.
[01:19:00] There was a lot of that. I was an observer early in my career, observing how people interacted, and the culture changed. Meeting culture, how meetings were conducted, emails, things that seemed so obvious. If I look at how people would communicate in meetings now versus emails versus how I used to work, like remote friendliness versus how people work in teams. I remember being in a meeting and someone raising their hand on Teams, and I was like, raise your hand to talk? What? This is not Microsoft.
[01:19:46] I had grown up in a culture where you just talked. You waited for a pause and you talked. You don't raise your hand to talk. Maybe it sounds crazy. There was a lot more consideration for everyone else. It wasn't just about the highest paid person's opinion.
[01:20:04] I think that's how Microsoft felt when I joined. If you were in a meeting with very senior people, it was hard to get a word in sometimes. If the most senior person was loud and aggressive, people who didn't think that way in the moment would not get a chance to speak. One of the big changes was in how we communicated as a company. Collaboration became a part of your review. If you were not trying to use things that other teams built, you were dinged for it. If you were gonna copy and create a clone of someone else's thing because you thought you were special, the incentives pushed you in the opposite direction.
[01:20:53] I think that's probably the most impactful change. The style of communication was a big change that I observed during those times.
Ryan:
[01:21:07] I see. Okay. So the culture shifted through performance incentives and some of the stuff that was messaged top down?
David:
[01:21:15] Yeah. And the behaviors that were being modeled by the leaders, like literally in meetings, people raising their hands, people calling on those who haven't spoken. Imagine you're in a meeting and there's someone really quiet who has really good thoughts, but maybe they don't like to speak up in meetings, pulling that person into the conversation.
[01:21:40] I remember when that first happened, I had never seen it before. I had never seen someone say, "Hey Ryan, you're quiet. You've been quiet the whole time. What's your opinion on this matter?" There were just people talking, and then you would leave. Now there's a lot more consideration for others.
[01:21:58] A lot less shouting. Early in my career, people were shouting, and I remember thinking to myself, is this normal? Am I gonna have to shout at some point?
Ryan:
[01:22:12] There's a famous XKCD comic about the culture at different companies, and if I recall correctly, the Microsoft one is a drawing of people with guns.
[01:22:21] The guns pointed at each other.
David:
[01:22:23] The guns. Yeah. I think that picture is funny, and it's definitely not guns at all. It went from guns to ambivalence, like "don't bother me," to collaboration. I think that progression is probably the biggest change between Balmer and Satya. The joke about the guns to "I don't have a gun at you, but as long as you aren't gonna disturb my situation, we're good to go." You're over there, I'm over here, it's all good to collaboration. We incentivize collaboration. You get rewarded for collaboration. I think that was the biggest shift and change I saw in the culture.
01:23:04 — Career regrets and work life balance
Ryan:
[01:23:04] When you look back on your career so far, do you have any major regrets that people can learn from?
David:
[01:23:11] That's a good question. Major regrets, maybe not. I would say early in my career, I was very arrogant. You could probably find my GitHub comments and the tone; I was lacking some empathy in a bunch of different places.
[01:23:35] One of the big shifts that I think my brain made over time learning how to build teams and impact through others was patience and empathy. Those two traits helped a lot with growing teams and influence in people. Being right means nothing. It's just not important. Being right is one of many things. I used to think, I'm right, therefore everything else will follow. Learning over time that this doesn't really matter as much, because there's a lot of things that are great when you're in software engineering.
[01:24:19] This is not the most important thing. Early in my career, I was very much like, yeah, I'm right. I didn't really understand why we were still talking about this. Every now and then it'll creep out, but I have a lot more self-awareness now. I know whenever that's not the most important thing for the moment. I learned over time how to dial it back.
[01:24:37] In general, maybe the fact that I didn't leave and go to Twitter because I would've gotten a ton of money as a senior engineer, or go to Facebook. I had a bunch of opportunities; I just didn't take them super early on. One regret that I do have that is not directly career-related, but maybe in the same ballpark, I had a friend in 2008 who sent me a message he was going to do a Bitcoin company. I was like, I love this crypto thing. Dude has so much Bitcoin though.
Ryan:
[01:25:32] When you look back on your career, what was your work-life balance like throughout?
David:
[01:25:37] I used to answer this by saying there was no balance. There was just work hard, play hard.
[01:25:44] Someone told me recently that work-life balance isn't nine to five, I'm stopping. It's about what things give you energy and what things drain energy from you. Early on in my career, I was working all hours. I still do because I enjoyed what I was doing, maybe a little too much. I would just have to dial back every now and then.
[01:26:09] I enjoyed what I was doing, so I worked a lot. Programming for me was not just my job; it was my passion. I'll never forget one summer I came back from vacation. I started making games just for fun. I learned a lot of Lincoln games and took that into things at work. For me, it was always about building stuff, so I wanted to build more stuff.
[01:26:34] What I find draining now is meetings that don't feel purposeful. If I were in meetings all day and felt drained after work, that felt like no balance because I want to do stuff that isn't meetings. I'm not doing that during the day, and then I'm going home after hours doing more work that feels like burnout quality.
[01:27:07] Balance was always that I work a lot. I love this career. It’s kind of insane that I get to code for a living. I see that as a privilege that I'm going to keep doing until I can't do it anymore.
Ryan:
[01:27:28] Yeah, I think when I look at a lot of people's careers who have been as successful as you, that's one of the unfair advantages I see. Almost everyone has this innate, intrinsic motivation. They work a ton of hours, just nonstop, and a lot of people love it. That is such an unfair advantage.
David:
[01:27:51] It is. I saw one of Andrew's talks, and he said 10,000 hours to get good at anything. Maybe it's not true, but early in my career, I wanted to become a very good software engineer.
[01:28:11] People always ask me, what book did you read? What did you do to become a good software engineer? I'm like, I wrote and read a lot of code, just anything you can get your hands on. There's so much more code you can read, consume, and write. I'm not sure if it's good advice, but what I know is that I did not get good at software engineering or building from seeing something online or reading a blog post. It's just do it; build everything—databases, distributed systems, games. Everything you build will teach you a new skill that you don't even know you have until later on.
[01:28:57] My GitHub is a graveyard of projects. I just build stuff and put it on there. I wanted to learn how to build a fighting game when I was 16. I got all the art from somewhere online and started to build a Street Fighter clone. It wasn't for any real purpose; it was just to learn how to build a fighting game.
[01:29:17] That pattern of needing to know how something works has served me to this day. I need to understand how the thing I'm doing works. I love what I do, and I think that has helped me do it more and get better at it.
01:29:51 — Advice for his younger self
Ryan:
[01:29:51] And then last question. If you could go back to yourself when you were just graduating college and entering the industry and give yourself some advice, what would you say?
David:
[01:30:01] Negotiate your salary. When I got my job, I did not know that I could even negotiate. I would've gotten more offers. Looking back, it doesn't matter right now, but if I was going to talk to a new college hire getting a job, get multiple offers and bump up that money.
[01:30:25] I watched my friends do it. I was in shock. From Barbados, I go to the States, get an internship, and get a job. They give me the most money I've ever seen in my life. Thank you for the money. I have my job to hear kids talk about. I said no, or I'm going to check out Google first or Facebook and get offers.
[01:30:49] What? That just became normal. It blew my mind. I couldn't rationalize what was happening. I do think it's definitely worthwhile doing that. I've seen kids do it so well. This kid is telling us no. I've been on enough hiring committees now to hire interns, and I'm watching the back and forth between this kid and the recruiter. This kid's in genius mode; it's amazing.
Ryan:
[01:31:24] Awesome. All right, well thank you so much for your time, David. I really appreciate it.
