Intern to Microsoft Distinguished Engineer in 11 Promotions (Career Story)

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. 𝗘𝗽𝗶𝘀𝗼𝗱𝗲 𝗟𝗶𝗻𝗸𝘀: • Transcript: https://www.developing.dev/p/intern-to-microsoft-distinguished • YouTube: https://youtu.be/d8tRM8RJ52M • Apple: https://podcasts.apple.com/au/podcast/the-peterman-pod/id1777363835 𝗧𝗶𝗺𝗲𝘀𝘁𝗮𝗺𝗽𝘀: (00:00) Intro (00:53) Microsofts leveling system (03:17) Joining Microsoft (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 𝗪𝗵𝗲𝗿𝗲 𝘁𝗼 𝗳𝗶𝗻𝗱 𝗗𝗮𝘃𝗶𝗱: • LinkedIn: https://www.linkedin.com/in/davidfowl/ • X/Twitter: https://x.com/davidfowl 𝗪𝗵𝗲𝗿𝗲 𝘁𝗼 𝗳𝗶𝗻𝗱 𝗥𝘆𝗮𝗻: • Newsletter: https://www.developing.dev/ • X/Twitter: https://x.com/ryanlpeterman • LinkedIn: https://www.linkedin.com/in/ryanlpeterman/ • Threads: https://www.threads.com/@ryanlpeterman • Instagram: https://www.instagram.com/ryanlpeterman • TikTok: https://www.tiktok.com/@ryanlpeterman

Speaker names marked ? are inferred from speaking time and the show’s known hosts — they are not voice-verified.

• 0:00Speaker 00

  It was probably the craziest promotion I've ever experienced.

• 0:03Ryan Peterman?

  This is David Fowler. He got promoted 11 times from an intern to a distinguished engineer, all at Microsoft, and I asked him about everything he learned along the way.

• 0:13Speaker 00

  A lot of things that get you to senior and maybe principal hurt you even further.

• 0:18Ryan Peterman?

  What are the hidden, unexpected perks of getting promoted to a distinguished engineer?

• 0:23Speaker 00

  Okay, the coolest part?

• 0:25Ryan Peterman?

  Also, since he's been at Microsoft for over 17 years, I asked him for his unique perspectives about the company. Did you notice anything internally when Satya became CEO?

• 0:35Speaker 00

  The culture just changed completely, right?

• 0:37Ryan Peterman?

  Before you change roles, ask when the last reorg was. What's the thinking behind that advice? I'm curious what has kept you at Microsoft as long as you've been. Here's the full episode.

• 0:53Ryan Peterman?

  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, you know, two levels per SD1, two levels for SD2, to and senior, and it keeps going on all the way down to distinguished. Can you explain the Microsoft leveling system a little bit?

• 1:23Speaker 00

  Yeah, so 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.

• 1:38Speaker 00

  So when you join from college, you typically start at 59 or 60, depending on like how many times you intern, how well you did, there's different things that go into it. But entry is 59, so that's like sweet one at other companies. And then you progress in level. In Microsoft, there are things called level bands. So when you say there's like two levels per title, the title tends to be the band. So you can say like, I am a junior engineer, you could be 59 or 60. So you can't tell from someone's title which notch they're at.

• 2:14Speaker 00

  So there's no fifty nine, sixty is sweet one, fifty, sixty one, sixty two is two. And then sixty, sixty four is um senior. And then principal is actually three levels. I never really said, I don't, I thought about the why is is done that way. I'm sure people that are really smart came up with those levels and whether that that way. But the like principal level, the the the band is so broad. The depth of experience of the people in that band is immense. So 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.

• 2:57Speaker 00

  Um, and you wouldn't know from looking at their title, so. And then beyond that is like. No one knows, right? It's like levels partner, um, that has three bands. And then there's beyond partners like technical fellow and and extension gender. Yep. So yeah, it's a, it's a broad system, yeah.

• 3:15Ryan Peterman?

  Yeah, thanks for laying that out. So yeah, that's the thing I want to dig into is, I mean, you went through this entire thing. You started all the way as an intern. And you've been there for your entire career and you grew all the way to distinguished. Um, so I kind of want to go over that story. Could you tell me the story behind you joining Microsoft?

• 3:35Speaker 00

  Yeah, so I went to college at Florida Tech. And I'm from Barbados. I left Barbados at like eighteen, like like everyone else that goes to college. Went to college. Funny enough, I was looking for colleges that had career fairs. And I chose one that was closest to like Barbados, one flight home to the Caribbean from Florida. So that was a really convenient place I got in. Um, funny enough, my first major was computer engineering. Cause I thought I wanted to do software and hardware. But in the first class, I was like, no pop for me. I wanna code. I had been coding since I was like ten years old. So that's what I wanted to do. Um, changed majors to computer science.

• 4:15Speaker 00

  Did my first year of programming. I thought, funny enough, I thought people that chose computer science had been doing programming like their whole life and they knew what they wanted to do. But in the first Java class, like no one knew how to code. And I was like, this is kinda crazy. I thought I thought this was like a thing to everyone. That chose computer science, but do before you come here. And that was kinda like being tossed into the pit of computer science, like learning about algorithms. And then. After that, I kinda met one of my best friends. Um, to this day, still, we still are best friends. And we started to make games. And we have been working on like next on weekends, making games for fun at school. And we, by the time the first career fair came around. There were a bunch of companies that came in to kind of, you know, see, see different students.

• 5:01Speaker 00

  And we thought to ourselves, how do we differentiate from other students? So we came in with a laptop showing our game demo. And we, we showed it to all, all the recruiters. Um, and that first year, we got like, I think like four offers for internships. I got Microsoft, GE, a bunch of other small, small companies in Florida. And my friend went to EA. So he, we built a game, he went to EA, you know, interviewed there, got interned there. I went to Microsoft. Um, and that's why I got the internship. Um, I showed them the game. We did interviews on campus, did full-time interviews. You know, before COVID, where it was all in-person whiteboarding. Uh, got my internship and that was kinda like history. Um.

• 5:46Speaker 00

  I interned twice. Uh, two thousand and six and seven. It was eye-opening. It's coming from a small country, going to a big company, experiencing like. Big campus, big technology, um. Talking to people who were like really, really, really smart.

• 6:03Speaker 00

  Absorbing information. It, it, it was, it was kinda, it was great. Um, and I was. Part of the last of the interns that got to go to Bill Gates' house. That was kinda, that was kinda fun.

• 6:14Ryan Peterman?

  What, what was that like, going to Bill Gates's house?

• 6:17Speaker 00

  So historically, every intern group at the end of the summer got to go to look at itself. That that was really the the main event, right? Um, in my time at least. And you would get picked up in a bus. And they would take all your technology, they would take away your phones, take all your stuff, give you instructions. You actually park out, I think at a church, and they would take your stuff so you could take pictures, you get. You know, they would tell you like what you can and can't do at the house. And then all the interns would just go into his his like big, really huge mansion. Um, funny story is, I recall just standing around talking to interns, not paying attention to what was happening.

• 7:00Speaker 00

  And I remember seeing a rush of interns like run towards me and I couldn't figure what was going on. I turned around, he was like, he was behind me.

• 7:09Speaker 00

  There's no kids. I shook his hand, so I I spoke to him once.

• 7:15Ryan Peterman?

  When you interviewed for Microsoft at the time in two thousand and six. Was there lead code or what? What did the process look like at the time? What kind of things did they ask?

• 7:25Speaker 00

  There's a book called, um, How Would You Move Mount Fuji? And it's this classic book, um, doing tech interviews like Microsoft created these like lead code style, um, puzzles that everyone loved to hate, you know, like the puzzles that are like. Why is a man who cover around is one of the most famous ones that people would ask you a question?

• 7:45Speaker 00

  When I, when I was on campus doing the, um, interview. Oh, don't forget, they they were asking me questions and I had been prepped for coding, coding interviews that I had been thinking about like coding stuff. But I hadn't taken all the classes yet because I was in my first year of of university, so I hadn't done like all the courses required to learn about all the things, right? So it was me on my own, my friends trying to figure out how to like what, how to prep for interviews. And they asked me, it's so, it's so visceral, they asked me a pile and jump question, super easy, not not hard. I did it on paper, like with a pencil, working on paper. And then they asked me, did you ever watch Die Hard three?

• 8:25Ryan Peterman?

  No.

• 8:26Speaker 00

  There's a scene where Bruce Willis and Sam Jackson have to stop a bomb from from going off. And there is like water on a fountain in a fountain. And they have um a five gallon jug and a three a three gallon jug. And they have to make exactly four gallons to avoid the the disaster.

• 8:43Ryan Peterman?

  Ah, okay, okay.

• 8:45Speaker 00

  And I had seen the movie, right? But I couldn't remember the sequence of steps required to get that to work. And in the interview, my my after the quoting question, they asked this this puzzle. Right? So you have infinite water and you you want to make four gallons and you have a three and a five jug. And you have to make exactly four gallons. Like, how do you do it? And I sat there and I was like, oh, my God, this is they heard. And I I figured out, but it was it was funny because it to me, it was like, this is like pre leaked code. Not even thinking about solving some sorting question or something. This was just like puzzles, like, can you think through puzzles? Um, and the last question was, how do you count the number of gas stations in Florida? And I sat there and I was like, is this a trick question? And the guy listened to me, he says, no, and I'm like, what?

• 9:32Speaker 00

  I don't get the point. I don't get the point of this stuff. And I thought I had, I I thought I had like done really poorly. But they had, they called me, so I was okay. I couldn't have filled it miserably.

• 9:42Ryan Peterman?

  That's so funny, because people hate on leaked code all the time. But these puzzles, it sounds like leaked codes better than these puzzles, actually.

• 9:50Speaker 00

  A hundred percent.

• 9:51Ryan Peterman?

  Related to the job.

• 9:52Speaker 00

  I didn't even know if you can prepare for some of these things, like my my last interview, my my second last interview. When I was 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. It was just like, what?

• 10:13Ryan Peterman?

  It's come a long way since then.

• 10:14Speaker 00

  This changed a lot. I mean, like, some for the better, some for the worse.

• 10:18Ryan Peterman?

  So going back to the story then, um, so after you had the internship, say, you committed for full time. And then you had a 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. Kind of want to talk about the story behind those projects. So for instance, maybe we can start with Nugget, which is the package manager. What's the story behind that project?

• 10:43Speaker 00

  That was interesting because Nugget, I think really 10 plus years in now is like the, the package manager for .NET. It was, when I think, think about the impact now compared to what it was when it started, it's kind of jarring. Cause we started off, we were building a brand new web stack. And we were trying to compete with like the lap stack, right? So lap was like Linux Apache, MySQL, PHP. And we were competing with that from a .NET Windows Server standpoint. Whether or not that made sense or not at the time, I didn't, I didn't think about that stuff. Like the bosses above me told me, we're doing that, like, let's do it.

• 11:21Speaker 00

  So we built this whole, this whole new web stack and Ruby on Rails had come out like concurrently at the same time and gems was like this huge deal. Ruby gems, get gems, get packages, you know, run commands and rails. And we had seen that, but there was also a cohort in the company looking at things like WordPress and Drupal. And those are packages too. And I think the consensus was we need to have an a package manager to like pull in packages to extend the platform. And the very first version of Nugget was this in browser package manager that was like a WordPress thing. And I remember we had this meeting with, um, Who is now the EVP Scott Guthrie.

• 12:05Speaker 00

  And it was all about like rails and gems and we have to compete with the package manager. And there was a product manager who had mocked up in screenshots and PowerPoint and experience. And it was me working with the architect saying like, we had built something like, can we just take the start from here? And that, that, that meeting formed the, the new get team. It was me, I was the first engineer, there was an architect, um David Ebel and Phil Hack. And we, we were the, the founding team of, of New Get. There were other open source nascent package managers in the ecosystem, OpenRap and, and New. And we like had a conversation with some of, some of those, those people.

• 12:47Speaker 00

  And we started off this mission to, to build a package manager for this, for, for .NET.

• 12:51Ryan Peterman?

  And so when you were building this, it sounds like it got pretty, uh, critical adoption within the .NET platform.

• 12:59Speaker 00

  Yeah.

• 13:01Ryan Peterman?

  What did your performance review look like when you were, you finished building this thing? Was that like a really incredible success for someone who wasn't even a senior engineer yet?

• 13:11Speaker 00

  Yeah, I got, my first promotion came like eight months in. Wait, when I, when I joined, um, even before New Get, I think like my first year was me. I, I had interned twice, so I had a lot of experience like with just Microsoft as in general. And I would work on the things I, I was assigned. And then I work on more stuff. One of the things I did was I would troll forums, looking for feedback for our products. And I would just build features to, to solve them. And I just did that over and over and over. And they kind of showed product managers and the team and architects and who turns out were my sponsors. Uh, I guess in, in the, looking back on, on how it, how it went.

• 13:53Speaker 00

  And I think that helped me be in a place where I could be the one to build New Get. I, I would, I would basically just look for problems to solve. And I would attempt to code them first. I was very, I mean, maybe I'm still the same way. I'm a code first, ask questions later. Kind of person. So my, my whole thing is code is currency. I can show you a working sample. It's not for our point. It's not a document. Here's a working example of something. Oh, we should start there and then move on to something else. Um. So my review for New Get was like, I, I was getting really good reviews. Early in my career, because I would, I would just grab things. Funny enough, one of my. Directors at the time told me like maybe five years ago that he would just tell people.

• 14:37Speaker 00

  That David has energy. Go talk to him. Maybe I'm way, maybe that's my stuff, stuff came my way.

• 14:45Ryan Peterman?

  You mentioned that New Get grew way past your, what you imagined. And I know at some companies, there's this idea of deferred impact where. Sometimes people continue to get credit for something that they. Built and is continuing to pay out for the company. Did you see anything like that in your subsequent performance reviews?

• 15:04Speaker 00

  Yeah, I, I want to say maybe the bigger ones. The bigger ones felt to me like. A conglomeration of. History, like past success adding up plus. Success. Um, I think at Microsoft in, in general, impact is supposed to be for the year. But I think when you're doing these, I think there are some things we call them band changes, right? So. When you jump across bands, it's a bigger promotion within bands, a smaller promotion. So if I go from. You know, six sixty one to sixty two, I'm still an SD two. But. You know, it's still worth a promotion, but when you jump, when you cross the boundary of going from two to senior or senior principal. You, you require more, more.

• 15:49Speaker 00

  Things to, to more impact to, to make that, that leap. And I think. I'm not sure if, if there's an official deferred in fact, um. Thing in in Microsoft, but I I remember that did come into to play when I when I went to, you know, higher levels of principle and and stuff, because it was. It was definitely not a one off, like, oh, you you did this one thing this year, like, you know, you're promoted. It's like, have have you been showing repeated impact over the last ten years? And do we want to, you know, keep you going forward, et cetera, et cetera? So I think it did. It did matter.

• 16:22Ryan Peterman?

  You mentioned some other larger projects, so um maybe we can talk about some of those. So there was a Signal, Signal R, or is it Signal?

• 16:31Speaker 00

  Signal R, yeah, so that that was.

• 16:32Ryan Peterman?

  Okay.

• 16:33Speaker 00

  That that came from that, the naming, the naming is the timeframe came from the time of Flickr, Web two point O, remove ease from the end of things. That's, I don't know why we called it Signal R. I mean, we we know why, but. That was a fun project. I had been working on nights and weekends on this project. And it was, funnily enough, like, Google Docs came out, and I had been like enthralled with the fact that you could co-edit in a document. I was like, this is just nuts, and it worked super well concurrently. And I was like, can we do this for code? So I had start, I I went off trying to build Google Docs for code, could be rich, but ah, didn't do that anyway. And while doing it, I learned about Web Sockets, which actually hadn't come out yet. I learned about basically how to build those kinds of apps.

• 17:19Speaker 00

  And that led to the creation of Signal R. In the meantime, there was a product manager on the team, Damian Edwards, who was also building a talk to describe how to build long learning streaming apps in .NET. So I had seen his talk, and I was like, hey, I'm building this thing. We should collaborate on this new library, right? So that kind of spawned the like nights and weekends, what we call on Microsoft, you can moonlight and work on things that are not tied to your work. Um separately, officially. So we had been doing that, like, overnight, we just work on this thing stuff until like midnight e- every night. Um, we made it open source, and then people started to use it.

• 18:01Speaker 00

  And we were like, okay, this is interesting, is ca- catching, catching on, becoming a thing now. It was still just two of us wo- working on this e- every now and then, didn't know what we were doing, really, kind of like, just building this thing to make it work. And then at some point, a product manager at Microsoft on the team said, hey, we should make this official. And that's when, I think that was the first thing I experienced, like, building a project from scratch. Previously, I had been working on other people's ideas. You know, someone had a great idea. I was a decent dev. I would come in and be like, funding engineer. This one was like my brainchild. So it was very much.

• 18:41Speaker 00

  I, we built the prototype, built the entire thing from scratch, and now I was being given the chance to have a, have a team to work on it. Um, I was never a manager, but I was the pseudo tech lead. So we, we hired like kids from college. I ended up working on Signal R. I had, we had a team of like. Eight, I think, at one point. And it was surreal because it was like, okay, there is this random thing that I built like. On a weekend and then it kind of turning into this project that's real.

• 19:12Ryan Peterman?

  What was the motivation for Signal R? What made you pull the weekends and the late nights to build this thing? That seems like it was outside of Microsoft.

• 19:21Speaker 00

  I hadn't seen anything like it. Like, when, when Google Docs came out, it was first of its kind to work that well. And it just felt super new and no one, I hadn't seen. Apps do that. And it was like, how do we enable more apps to do the same kind of thing? Node JS, like socket I O and node were super new. And socket I O had just come out and it was like, oh, that's a really cool way of building these apps that are, that are. Chat and, and can send stuff from server to client. And we just, I think that just drove me because it was like, okay, I hadn't, hadn't seen people attempt to do this before. Let's, let's push. It's funny, we, we pushed the boundaries of like the technology a bit.

• 20:05Speaker 00

  We hit limits like all over the place in, in the tech stack that. Became problems to solve deep in the, deep in the core platform too. So that, that was a really good. Um, way to learn, learn more about the overall networking stack and. I think the, the, the amount of problems we got to tackle maybe made it enthralling for like a, a dev that like. I got nurse knighted. It was a catnip.

• 20:31Ryan Peterman?

  That this is so interesting because you grew through this project and it was permissionless, which is that no one handed it to you. There wasn't some manager, some PM that came to you and said, "Hey, your staff's on this project." You just went and you built something and it was so impactful that it actually led to a ton of career growth. I'm kind of curious, maybe we can, is there some way for us to reverse engineer that for others? Like, how, how do you go about starting projects where the motivation comes completely from you within a large company?

• 21:05Speaker 00

  So really good question. If I had to, to boil it down to one sentence, you can just do things. And I think the, the way people talk about it now is you have agency. And it, it often seems like you don't, like it's really hard to find time. And I, I am not recommending people spend like some weekends working on all the projects, but early in my career, I, my, my main goal was to get better at like software engineering. And the way of doing that was to learn everything, like build anything you can build, games, websites, like just build a ton of different things. And you just gain experience from learning how to build those types of software, right?

• 21:50Speaker 00

  So I think that was ingrained in me from really, really early on. And then the other thing I did early on in my career was I found someone that I wanted to, I found someone on the team that I, I wanted their career. So on my team, there was an architect, David Ebbel, and his job seemed really cool. He got to think about the future. He kind of spanned multiple areas of, of the product. He got to build the next wave of what was coming next. So I basically attached myself to him and I mimic his behaviors. And I said to myself, okay, I, I want that role. Let me make sure I, I'm seeing what he does that seems to work and I want to keep doing that. And I would,

• 22:31Speaker 00

  I would be the coder of his ideas, right? For a while. And that turned into learning how to do on my own. So I kind of, I did this gradual thing where I was like, attached myself to people who were like that. And then I found myself in that same position. Okay, here's a new thing. I have some insights. Let me try spiking a thing that will work. And then I, I communicate ideas with code. So I would always build a product first and 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 that a customer was having. I think this solved the problem. Do you think we can turn into something?

• 23:11Speaker 00

  And that, I think that pattern of doing that helped me gain insights into what people, what, what helps people get over the hump of like, should we build a mirror? I, I would build a thousand things and many walls would hit.

• 23:27Ryan Peterman?

  It's, it's interesting that you say agency. I, I think a lot of people who work at big companies or talk about big companies, they feel like it's difficult to have agency. They have all these projects that are assigned to them depending on the team culture. And it sounds like you had that agency through energy. So you were moonlighting, you were doing, going above and beyond. You did your normal stuff, but then on top of that, you had all this extra agency. Uh, am I understanding that's how you unlocked agency at a big company?

• 23:58Speaker 00

  And I think it afforded me, I think, once you build a reputation for being able to kind of perform, build and build things, I think more things come your way. I don't want to say like it is easier or it will happen, but I think in my case a hundred percent like, when I, when I, 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. Like 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, when I think you have a good rep for building stuff.

• 24:37Speaker 00

  I think further in my career, that showed very true for what happened, what happened after Signaler, pretty much.

• 24:45Ryan Peterman?

  You get a lot more of those permissioned opportunities when you have credibility. And permissionless agency is, uh, it's almost this hack to kind of bypass credibility.

• 24:55Speaker 00

  Yeah. And, and the funny story, I think the funny thing is like, you, you get a chance to be more permissionless, the better your track record is. So the more you have, the more success you have, the more leeway you get to fail, which gives you space to try more things.

• 25:16Ryan Peterman?

  Yeah, no, that makes sense. I I've seen that a lot. The the very high, fast-growing software engineers. They're 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. I bet if you were someone who was struggling to meet expectations. A lot more directed opportunities are being handed to you and you're being monitored. So I could totally.

• 25:42Speaker 00

  Yeah.

• 25:42Ryan Peterman?

  Totally see that.

• 25:43Speaker 00

  So true.

• 25:44Ryan Peterman?

  Going to your late-stage promos, you got the promotion to principal, you got the promotion to distinguish that Microsoft. I'm curious, what is the thing that led to the promotion to principal?

• 25:57Speaker 00

  Principal was interesting. So I I had I had one boss, I won't say his name. I had a one boss who who told me. When I got to senior, that my promos would slow down. And I remember that meeting where I sat down and I got this, I got I got the promotion. I was really happy. You know, he kind of gave me this donor link. Don't expect more promotions like from here, because you know.

• 26:16Ryan Peterman?

  I was like, what does that mean?

• 26:17Speaker 00

  Um, and and I really took it took it to heart, but the the jump to principal is a big jump. I had been working on Signal R at the time. I built this, um. If you ever use Heroku, Heroku like pioneered, get pushing and deploy your app like instantly, right? We had built, there's a, there's a tech called App Harbor for for dot net. This this company was doing the same thing for dot net. And we built a similar thing for Azure. This is like super early in Azure timeframe, really. We had built this like brand new, it's actually still there, it's called Kudu. Um, and I had, I had been working with the same architect and I had built it with him.

• 26:58Speaker 00

  Um, and then at some point in that timeframe, I got pulled off of that. And I think this is one of the places where like your track record helps just get set up for the future opportunities. So I had my director tell me, hey, we have this new thing spinning up and we need you to go work on it. And obviously, you know, you're working on something else. You're like, man, I'm I want to finish what I'm working on, but then this thing happens and like, I'll I'll help you with this thing. And that ended up being the beginning of the new Donnet um Donnet Core, the rewrite, those cross-platform and modern and new.

• 27:39Speaker 00

  And it was a big opportunity, like so big, it was scary at first, like, oh, my gosh, like, what do you mean? You're the architect, like, I I I was senior, I was, I was, it it was me, it was me and another principal engineer. That got chosen to be the architects of this project. And I hadn't had an experience working at that scale before, because I think you had like thirty engineers that were working on this this project. Um, we have free reign to kind of build whatever we thought was right. And that was like both amazing and terrifying. Um, and I think through that project, I learned a ton of things, like knowing how to, I don't I don't say we weren't managers, but learning how to

• 28:18Speaker 00

  manage a project and architecture and scale and like initially, I was trying to co-review every single change. You can imagine that Bermuda. Within that, within a year, it was like, okay, I can't, I can't, we can't do this anymore. You have to figure out how to trust people and skill and figure out what's important, what's not, what's not urgent versus urgent, etc. Um, that year I got promoted, actually, I had my first first kid and I got promoted that to principal that same year. I did this um the first year of Donnet Core um design and building it.

• 28:53Ryan Peterman?

  You you mentioned that 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?

• 29:08Speaker 00

  So I learned, I learned some of this during Stigmar. Uh, the the the the smaller version was Stigmar, when you have like seven or eight people overall, right, engineers, techs, product managers. And we had two new hires. And I had never had the experience of delegating in a way where I thought it was like, if I gave you this work, it's to grow you, right? I never thought that way before. I was always like, I'm a senior engineer, I can get this done. I I I can do it faster than you. Like, why would I give you this thing when I can do it faster? Um, we had really smart engineers that we hired from college and.

• 29:46Speaker 00

  It took me a while to kind of get past. It's gonna take them longer at first, but once they understand all the stuff, then we'll we can amplify the impact. And I think once I saw that, it flipped my brain. So I had I had something from from the sigma transfer that was like, okay, if you can invest in people and kind of get them on the same pitch as you, if you are on the same wavelength, if you can delegate more, um, then you can kind of get get more done as a team, right? You you be you begin to be begin to think about outcomes. And less about like the work you're doing individually. I think the the leap from senior principal feels like being able to do more through others than yourself.

• 30:28Speaker 00

  And it's it's where I think a lot of people end up plateauing. Because software engineers are very like, you know, we want to, we want to, we we like coding. We want to be alone. We want to build the things ourselves. Software engineering is a collaborative event. It's like we want to figure out how to get the customer feedback, figure out what to build, figure out how to build it the best way. And I think that change in my in my brain prepared me for like dot net four because it was such such bigger scale, like how do you even begin to manage that many people, that that many facets? We we rebuilt everything from scratch, like we literally rebuilt the package manager, the runtime, the libraries, like everything from the get go.

• 31:10Speaker 00

  And it was overwhelming at first. Um, what I think helped a lot was not treating everything as equally urgent. Like that was a big deal. Like if this change over here went in and it wasn't perfect, I wouldn't be like we can't merge this and these have this interface, these tests. Um, learning how to set foundations for others and to trust others. And like letting people fail was a really hard thing for me at first. It was like, okay, I could I could avoid the failure.

• 31:41Speaker 00

  And and it turns out that the team like, I think a lot of the things that get you to senior and maybe principal hurt you great even further, right? Being a control freak, being someone who like is amazing at their job, getting stuff done in a very specific way. Doesn't really help you when you want to feel it's what those engineers. You have to kind of figure out how to inspire others to do the same as you through different means like one on ones or or you being an example or like more more different techniques, but it's difficult to just be to take you you're not going to take harder and make a bigger impact. So it's like, I shifted my brand to be outcome focused. It was a big, big change.

• 32:25Ryan Peterman?

  You mentioned the architect title or I guess role. What does that mean at Microsoft?

• 32:32Speaker 00

  That's a fun one. Um, when I joined, I saw someone who was a principal software architect. Let me start with myself. That's the role that I want. I don't know what it is. That's what I want, though. It's kind of a semi official role at Microsoft and like a certain levels. The middle principal bands, you can be one of these architects. And to me, it really means you're more breadth rather than depth. You're more overseeing the design of the overall system. That we have different engineering architects, I would say. Even at the highest level, you have someone who's a super quarter. Who is like, I am just gonna build so much stuff. I can impact so many things. There are people who work on really deep technical details that have a huge and probably have

• 33:17Speaker 00

  um, one of the foremost GC experts like in the entire world, right? Working on working on um, the dot net garbage collector. So you have that kind of impact. Um, you could be someone overseeing a hugely impactful area of the product. So there's a lot of space to kind of like figure out what architect you want to be. And I think the architect role for me felt like breadth. So I am architect for SPNet Core back in those days and I am like overseeing the design of the whole stack, the web framework, web server, web server, how we, how we ship packages, like the entire engineering idea. And I'm not the, the engineering lead, I'm the architect. So I'm

• 34:00Speaker 00

  trying to vet the decisions that are gonna like last for like 20 years. If we do this change now, we can't do this thing like five or 10 years. And I hadn't had experience doing that before, but I had a really good mentors who had done that. So I had, I had been watching and shadowing and trying to understand through experience, like, how do you build systems that last 20 years? Like, silly crap, right?

• 34:24Ryan Peterman?

  So as you've grown to distinguished engineer at Microsoft, how has the percent of your time that you spend writing code changed?

• 34:32Speaker 00

  It's funny, I think, I think there is what your job is, like, do I have to code every day to do my job? I, I don't know if I get rewards anymore for coding. I get rewards for outcomes. But for myself selfishly, I code every day. So my team knows right now that I, I send lots of poor requests every day to the code because I'm, I'm currently working on, um, I, I have a new project I'm working on, this shirt, um, aspire and I code a lot. So I, I personally make sure that when I'm working on a project, I am somewhat involved coding still. I don't want to be the architect who doesn't know the code and is giving people instructions like,

• 35:17Speaker 00

  you should do this and I'm going to go away now and disappear somewhere else and, and anyone see me again. I want to be the person who is like, you, I'm a pair on the team. I want to be your, everyone's pairs and I want to be facing the builds and do it, facing the tasks and not, there, there isn't any work that's beneath me. It's kind of what, what, what I'm thinking. Um, so I, when I, when I'm on team, I typically work as I'm, as an engineer on the team.

• 35:45Ryan Peterman?

  If you stopped coding right now and you just kept leading the team, would your performance review look fine?

• 35:53Speaker 00

  Yeah, I think so. But distinguished engineer is definitely about company-wide org organizational-wide impact or company-wide impact like. So I think even though my my day job is definitely making sure the architecture of of done as a whole is is sound and good and moving forward and we're doing the right things and pushing. It's a part of my job that is like looking forward and you know, talking publicly and like.

• 36:22Speaker 00

  Inspiring people internally and mentoring people. And so there's a lot of things I do that aren't like why I used to do way before. That I think helped with with impact.

• 36:35Speaker 00

  As an example, I gave. Four talks internally about how to use AI to do software engineering. And that happened just because I had been using it myself for a lot of different things. And someone said, hey, you should give a thought to the team. You think about the impact of those things, they they help. When you see engineers who aren't just your boss telling you to go do something seemingly for bad reasons. Engineers who are credible. Telling you how they do their their jobs. So I do a lot of that stuff too. A lot of things are not.

• 37:08Speaker 00

  Software engineering to be to be frank.

• 37:10Ryan Peterman?

  When you got the promotion to distinguished engineer, what's the story behind that?

• 37:15Speaker 00

  Absolutely insane. First of all, distinguished engineer is. The final level of like partner. If you go up to the levels FYU, you see. Level fifty-nine to eighty, I think the last is eighty, but the final level. Distinguished engineer, I think is seventy on there.

• 37:35Ryan Peterman?

  Right.

• 37:35Speaker 00

  And there's a there's an actually, there's actually an official process. To become to to get that title. You don't just, it's not a promotion that you just get. And because you did a great job that year. It is. A set of technical leaders have to peer review. And decide that, decide if you are, if they're worthy or not. They said if you're worthy or not of that title. Um, it was probably the craziest promotion I've ever experienced. Mostly because of the the people that are there at Microsoft. Just as an example, um, Guido, Guido Van Rossum, who created Python. Is the same level of me.

• 38:18Speaker 00

  So like, impasse syndrome, right? Impasse, and Guido's great, like, he's, he's, he's great, he's really fun, cool guy. Maximum impasse syndrome. I'm, I'm young, I think I'm young for, for that role too. So like, when I was going for that role, I, I, I felt, I still, that would affect me as well. It, it, it didn't, but I felt it would, it would affect me. So I had, I had all these hold up, hold ups about like, am I really? At this level, can I, can I perform there? Can I do well there? And then with, with all of my, I think this is probably where all the work I've done in the past helped. Because you do need a body of work and you do need um, a good track record.

• 39:02Speaker 00

  To qualify for these kinds of roles. You can't just become a D E because you had a one fun, one fun year. Um, I think some of the criteria ends up being like, what have you contributed? Like, that, that impacts company, why, like, things, what have you contributed that has? So it is, a lot of it is like deferred impacts. I guess, I think it makes sense, because um. Dot net, remember, when I, when I went to from principal to partner. And the email, it had the dot net course impact. And that was a, by then, it had been about seven years. It wasn't like I did it last year or the year before. It was like this is built up impact. And then like,

• 39:44Speaker 00

  I had been the architect to help people adopt the new dot net internally. And I had done that for a bunch of different teams. So like there's there was all this kind of build up to to like I guess deferred impacts of that. You're really good at saying it. Um, and I think all those things helped new get signaler like how did it? How did the thing that you helped build a mold and raise like grow? How did it impact the industry, the company? And those all come into a company when um the the I think the the there are fellows who decide who becomes the E.

• 40:19Ryan Peterman?

  Were you involved in that process at all? Or was it a surprise when you got the distinguished promo?

• 40:24Speaker 00

  I was involved from a point of from the point of view of helping my leadership with like content. So I I gave them all of my contributions to things. Things I've written like papers are written. Code contributions to various various projects. I kind of gave them the raw material. I didn't do anything else.

• 40:45Speaker 00

  Um, but what what made it impactful for me was seeing the other fellows like our knowledge. And say like, well deserved. And this is about time. And we okay, let's do it. Maybe I should. Maybe I should. Maybe I should be here. This is good.

• 40:59Ryan Peterman?

  You mentioned the lofty expectations of this distinguished engineer level. Yeah. Is that something that you worry about now that you've been acting in the role for a while?

• 41:08Speaker 00

  At first, I I I would tell people I am a baby D. I've only been here like a couple of months or or it's been one year now and I not sure yet. Um, I think now it's been two, two and a half, two and a half, three years now. Um. I feel pretty confident. I can perform at this level. And I think I understand what is what is required. Um, I would say initially, very much yes, my my first review cycle. Um, I felt pressure to like document everything and just write down what I thought was all the impacts, right? Was it? It felt very much like, oh, my gosh, I should I need to make sure I'm

• 41:49Speaker 00

  we don't write all stuff down, um, tell my boss what I'm doing, like making sure he knows and because I think you're you're you're almost an executive at the company. Like you're you're you're at the level below being an executive and like. It's super scary to think about how having to have that impact every year repeatedly over and over. So I think I found a pattern for kind of like making sure I had the right level of impact. Talking to my bosses, making sure I had, I was visible, making sure I'm doing all the right things. So yeah, I don't, I don't feel the pressure as much now. Um, but who knows? I mean, things can change.

• 42:28Ryan Peterman?

  So you went through, it looks like 11 promotions, which is kind of ridiculous. You went all the way from the beginning, all the way to then. And the crazy thing, you're saying Guido, the founder or the creator of Python is that level as well. I can't even fathom, because apparently there's one last one, the technical fellow. What, what does that final boss level even look like?

• 42:53Speaker 00

  So the people who are fellows, tech fellows, I guess the, the, the one that, you know, in my division that everyone acknowledges, Anders Helsberg made Turbo Pascal, Delphi, C sharp and touchscreen. So like, no one's competing with that dude, because like, no, you can't repeat building for successful languages.

• 43:19Speaker 00

  But I think if you were thinking about the, the archetype of like someone who is a fellow, it's that level of impact, right? Or the people who built the Windows kernel. Actually, there, there's one guy, Dave Cutler, who came from DEC back in like the eighties or whatever, and he helped build, he built Windows NT, he built Azure, the, the OS. He built the hypervisor for Xbox. He is the only senior technical fellow.

• 43:48Speaker 00

  That isn't even a real title. That's just his title.

• 43:53Speaker 00

  So it's kind of like, I think at those levels, everyone's a unicorn and everyone has their own path. So you weren't trying to follow people's path one to one. You're looking for proxies for, for impact. To be a fellow, you need industry-wide impact, not just.

• 44:12Speaker 00

  Impact in your division in your company. It's like you need to do something that impacts the industry. I think we hired someone recently who is a fellow who like invented RSS. It's like that. It's like that level of like thing, right? It's like you built something that became the industry standard for, you know, the internet like. There was a guy on my team who was the intern for Tim Berners-Lee. And he is on the HCP spec. Like is that?

• 44:42Speaker 00

  Henry, yeah, so yeah, the this, those are the kind of people that end up being fellows, I think.

• 44:47Ryan Peterman?

  Were there any unexpected perks of getting promoted to distinguished engineer?

• 44:53Speaker 00

  Besides more money?

• 44:57Speaker 00

  Let me think.

• 44:57Ryan Peterman?

  Well, for instance, I guess the thing that I'm curious about is. 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.

• 45:09Speaker 00

  Okay, the coolest part, here's the coolest, the coolest part. There's a, there's an email alias called engineer. That is all the D E's on Microsoft. It is just the coolest alias of the engineer on Microsoft, like all those.

• 45:23Ryan Peterman?

  That's awesome.

• 45:24Speaker 00

  That's one of the perks. Yeah, but there, there is, there is, there's a, there's internal, um, there's a forum. Where we all meet, I think every, every couple of months. The way this typically works is you have a sponsor, right? So when I'm, when I'm, when I was going to be. I told my mentor, I want to be a D E. I had, I had mentors who were fellows. Okay, so one, one tip. When I became a partner, I told my men, I, I told my management. That I want a mentor, I want helpfully a mentor who is a fellow. Cause I want to be one. So I figured if I want to be one, I should have people who are mentors that can help me get there. And my, one of my mentors was, was very impactful in my career.

• 46:09Speaker 00

  Um, he invented PowerShell, Jeffrey Snowver. And he was one of the best mentors that I've had. He, he actually left Microsoft and I went to Google recently. Uh, but he was like really, really impactful for me in my career. He was one of my, one of my main sponsors. And I ended up, um, getting to go to one of these. Tech leaders forums, I got to mingle and talk to all the people who were like there and it was really, really interesting, really cool.

• 46:34Ryan Peterman?

  You mentioned that that mentor was incredibly impactful. What was the things that he was telling you that made a difference?

• 46:41Speaker 00

  A lot of people, I wanna say, sugarcoat like how to get places, how, how to get promoted. And they'll give you very generic feedback. Um, you have to do a project that's super impactful. He was very, very much directly. We should go talk to the people who decide and ask them like where you are and then, and it was jarring to me because I, I never thought about asking the teacher for why, why it, it like, no one ever tells you, um, you have to do X to get promoted, exactly. And, and it never exactly works one way or twice. It's like, you have to have more impact. So make sure you're working on something that's like, you know, super impactful. And maybe you aren't now and change.

• 47:23Speaker 00

  He was like, let's go to the source, go to the holes. Let's go talk to the CTO. Let's go figure out like, what it means for you and your, and your role. And I was like, that is super helpful. And cause it helped me, it helped me understand what I should and shouldn't be doing in a very like real way. It wasn't just arbitrary advice that just happens to you. It was like very explicit. I had a second mentor. I had done some, there's this thing where you can get feedback from different people in, in the company, your manager, um, your peer, et cetera. And it gets turned into a package and they give you feedback. And it tells you your strengths, where you're, what you're good at, what you're really bad at, where you're, what, what, how you act under stress, all these things.

• 48:09Speaker 00

  And my, my first reaction is, oh my gosh, I am gonna have to fix all the things I'm bad at. I gotta figure out how to, you know, get leveled. And my mentor was like, no, no. Take your strengths and amplify them even more. You, you could have worked 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 super human at those things. And it, it broke my brain because up until, and that was like, I wanna say five years ago, up until then, I had been thinking about, man, how do I make sure I am better at everything? So I can like be a well-run individual. I think it was like, No one, no one gets promoted to these roles for being average.

• 48:54Speaker 00

  You need to, you, you get to be superhuman in something that you're like, like you're really good at that people aren't. Right. So that helped me refocus to, to thinking about. Finding ways to make up for things that I'm not good at. So as an example, if I form a team. I am not the one that's going to schedule meetings or I am not going to. Go through every detail of how, how we ship and all the, all the checklist. I am super bad at that stuff. And I will make sure I have someone who is really, really good at that stuff. So I can focus on what I'm good at. Right. So that helped me reframe how to think about, um, amplifying why I do well to kind of, um, get more impact.

• 49:37Ryan Peterman?

  Makes sense. I mean, it's kind of like, uh, 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.

• 49:48Speaker 00

  Exactly. It's exactly that. Yep.

• 49:51Ryan Peterman?

  Uh, you mentioned a lot of these, you know, 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?

• 50:10Speaker 00

  I can, I can talk about some of the well-known ones and then talk about like these people that I work with in general that are impressive for different reasons. My current team, they're like five other partner level engineers. That have been here twenty plus years that are just really, really good for different reasons. Like experts and the G C, one person is like a super coder, like just. He just codes ten X. So people complain about engineers aren't ten X, he's ten X.

• 50:44Speaker 00

  He just produces way more code than everyone else combined, right? Um, there's one guy who like literally seemed to know everything about obscure things you would never understand and you're like having to have seen it yourself. There's all kinds of stuff, stuff about C, stuff about compiler, stuff about the OS and you're like, how does he seem to know? Everything about everything, right? Um, and then there are there engineers who just seem to know what to build and have a good eye judgment. So I I'm I'm on the C sharp, um, the review, design review team. So we meet every couple of months and we review C sharp features, right? New features coming to language and I'm on there with Anders Halsberg, who made C sharp. So like, well, I say it doesn't matter. Well, he says matter. I mean, it it does, it counts.

• 51:29Speaker 00

  Um, but the way he communicates, like the way he gives feedback for what feels good and what does not feel good. He always does it in a way that is very much like he is not talking down to you. I mean, this dude invented four languages are just like what what 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 feel dumb because he's like, oh, he's super smart and I'm dumb. He does it in a very pragmatic, practical way. Then you see the code he commits and you're like, dude is inventing types and theory that we haven't even seen before technically insane.

• 52:12Speaker 00

  Um, so I admire a lot of like watching people like that spread their impact. Um, Mark Resonovich, who's CTO of Azure, famous for his Windows tools. Um, he still codes and it blows me away sometimes like he he's he actually is working on something right now. Um, and he sent an email two days ago. And I was like, holy crying and and and it was it was very dev, a dev centric email. It wasn't a high level. We should do X. It's like, no, I wrote some code. I improved the performance. I'm like, here's a result. Now it's like, obviously I have to do stuff. So I think whenever I see high level engineers or ICs still coding like that,

• 52:57Speaker 00

  I get really inspired. It's really easy to fall into the meeting trap. Um, actually, when I went partner, I fell super steeply into the meeting trap of like, I was in meetings all day, every day, and I got really sad. And my mentor said, as an IC, your job is to have like, you you need to think and to build stuff. So minimally on your calendar, block eight hours a week, minimum, to to do that stuff. And it took me a while to change my brain to say, I can just say no to meetings.

• 53:34Speaker 00

  Decline, decline, decline, decline, decline. My my code.

• 53:40Ryan Peterman?

  So I I think the next set of questions I want to ask you, um, because you have a public presence on Twitter, there's all these top tweets that you have that I think are really interesting short thoughts that I'd be curious to have you expand on.

• 53:53Speaker 00

  Yeah.

• 53:54Ryan Peterman?

  So I think the first one is um, talking about university courses and you said that, you know, there should be a university course that explains how to refactor code, how to make changes to it without breaking an existing code base. My question to you is, if you were to design that course, what would some of the key concepts be?

• 54:18Speaker 00

  Having been working for this long now in industry, computer science is not software engineering. It's not even, this is not even close, right? Computer science is like learning how to learn the science of of computers and bits and bytes and the math and algorithms and you do a little bit of the things that are software engineering like, but it's nothing like software engineering. So 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, right? Like, don't break the build, don't break everything else. So I think if I were to have a course, you would be thrown into an artificially big code base. We would, we would have a, maybe

• 54:59Speaker 00

  it would have to change every year because students will like just copy from the previous year. So it would change every year, different code base. And your job is to make a bug fix. You got to fix a bug in this code base and write a test for it. And just the The the skills you learn being a code architect, a a code archaeologist is so different from just just writing by by an early code question or doing a homework assignment that is just like this one thing in a textbook. You learn a lot of adjacent skills from just trying to figure out where to put the code in the first place. I I I think it's funny. I think thinking now, I think it would be super useful.

• 55:40Speaker 00

  Like every every assignment is making one one fix. And maybe you you can set up the code bit such that it's not super hard to figure out what it is. Anyone with enough time, like, you know, we could figure out and make it this one triple change and and add one text. Um, but I think a lot of a lot of people's jobs are tweaking software that that is there already. Not everyone gets to create new software. Like, if you if you work on Windows, sure, you'll build new components, but you aren't going to change the kernel unless you're going to do a new a new a new OS. Um, so yeah, super useful skill.

• 56:16Ryan Peterman?

  Yeah, I think there was another set of tweets that I saw that was kind of around this idea of that tech interviews are focused so much on writing new code, but actually the real high leverage skill is debugging it. Yeah, what gives you that that thought? Maybe you can expand on that.

• 56:31Speaker 00

  So early in my career, um, I worked with a ton of engineers who were and on the on the Dona team, we had a lot of engineers who just worked at the platform level. Um, so I got to see firsthand people diagnose crazy crashes, risk conditions, spreading issues. I got firsthand a firsthand seat to even watching people's mindset when they go to diagnose issues. I thought to myself, like, this kind of two skill sets are may maybe you learn some coding, but they're just not the same skill set. And if you think about building an application, deploying it, shipping it, and then getting craft reports, trying to resolve issues, like trying to figure out what's going on in production.

• 57:15Speaker 00

  There is this second skill set that is just not bringing like not authoring code. That is, how do you even think through? Debugging issues. How do you know which thread caused the exception? What tools do you use? How do you think about how it got there is like? I thought to myself. It would be fun to have an interview where. You give someone a crash dump or something like. Hey, this, this, this app just crashed, like, figure out what the problem is. And you aren't trying to see if they can solve it. You wanna see what they even start doing. Like, do you start adding logs? Do you run the program? How do you think about risk conditions? Do you like print thread IDs and try to figure what you're leaving like?

• 57:59Speaker 00

  All these, all these interesting. Things come out of watching someone try to diagnose problems. I, it's funny, I have the highest respect for engineers. Who can be thrown into like a, a, an, a prompt situation where they don't know the codebase super well. Um. And they can kind of solve the issue. 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, I was running on Azure. And. I'm in like also, I was up late, it was one AM. And. My CBP. Sends me a message, like a, a DM, it's like, hey. You free? I'm asleep.

• 58:44Speaker 00

  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. And. You know, we, we, we called the, the, the team who was working on it. It, it was some other company. But we were helping them as, as engineers, from our yourself, trying to debug the issue. And you could just see the different people's skillsets trying to figure out what the issue was, and we solved it eventually. Um, it, it was a concurrency issue somewhere in some dictionary that caused a. Risk condition. And. I thought to myself, like, this is one of the skills that you need to have as an engineer, like. Writing code is just, it's just, it's a small piece of your overall. Skillset.

• 59:26Speaker 00

  Learning how to debug and think through issues is like another big, big chunk.

• 59:31Ryan Peterman?

  Yeah, and as evidence of that being very impactful, I know some companies, you know, every company has their different archetypes. And you mentioned like super coder, also known as code machine in some places.

• 59:43Speaker 00

  Code machine, yep.

• 59:44Ryan Peterman?

  There's also, I've heard the archetype fixer too. And that's, that's a, that's a really cool one because it's been described as someone drops in somewhere. They make a one line change after tons of investigation and it gets two times better, three times better, or something like that.

• 1:00:00Speaker 00

  Oh my gosh, we have some engineer on, on the team who there'll be a thread I get started off. Oh, perk issue somewhere and GRPC call. And I'll add the engineer, the thread, say, hey, can you look at this? Boom, boom, boom, here's a trace. And I'm just like, oh my gosh, it's solved. It's solved.

• 1:00:20Ryan Peterman?

  So impressive. Another tweet that you had, I thought was really interesting is it says lukewarm take. The lower on the technology stack you sit, the less mistakes you're allowed to make. What, what made you think of that? Did something break super low level in the stack somewhere?

• 1:00:40Speaker 00

  I have to be working on some, so I work on platforms. So the way we think about software is way different from, you know, higher level services or even web, web printers or whatever. I think maybe I have been working on something that broke. I mean, a lot of things break that are just kind of insane. The things that we change that break services are absolutely unheard of.

• 1:01:05Speaker 00

  We will change the order of how things come back in a method. And like it just snaps, some, some companies website goes down. So I think when you work at that layer, it's that you gain an appreciation for the kind of changes you can and can't make.

• 1:01:25Speaker 00

  I think, I think that tweet maybe was inspired by one of these bugs. Cause I, I work on, I think at, at that time I had been working on, um, first party adoption of, of, of .NET. And we had seen a couple of people upgrade and hit issues. That made us just come to be shocked. It was like, how did, how did you find that bug? Like, no one gets that. What do you mean you have 400, 400 arguments to method? Like, that's not.

• 1:01:56Speaker 00

  There's some limits to where that like, that can be a real problem, right?

• 1:02:00Ryan Peterman?

  There's another tweet here, and that was 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. And you would have thought they would be angry, but the opposite happened, that actually having good coworkers matters a lot and people weren't, you know. So yeah, what's your your thought there?

• 1:02:26Speaker 00

  This is, you are, you are bringing back some good memories. So I remember when I was going to senior, I actually, I was actually a little worried about getting promoted before I could, because I had it on a really fast path. And I thought, I mean, maybe, maybe it would make people jealous. It was like, why not me? And, and, and when I joined my team, I think there were four people from MIT and two from CMU, and I had gone to Florida Tech, and I was like, yeah, these people are like way smarter than me. So my way of working through imposter syndrome was just to like work really hard and like be a busy bee doing stuff.

• 1:03:06Speaker 00

  I think I understood that when I got promoted to senior, that the impact was not about being intelligent. It was not just about like getting the highest grade or being smart. It was like, are the things that you're working on being impactful to the business? And that was the shift where I began to understand, like, okay, it's not just about why no, it's not just about that this person on the team is really smart in area X. It's like, can I take all that and produce something that is impactful? And that promotion helped me see, okay, that was the new get thing, the signal thing, that's how you get promoted, that's how you, you, you know, you, you add impact for the team. It's not just about knowing this thing about this,

• 1:03:49Speaker 00

  this feature about this area about this OS. Because I always felt like, man, I don't know enough about, you know, technology X or about area X. I gotta go deeper and learn more. And the question was always, is that for you or is that for your career? Or what's it for?

• 1:04:06Speaker 00

  You don't have to know how, I don't know, maybe, maybe you should, but you don't have to know how TCP IP works to get promoted to the senior. I'm sure people don't know the details of how it works, right? I think that, that promotion for me helped me separate like,

• 1:04:24Speaker 00

  Being smart from making an impact. Okay, promotions, impact these promotions. Being smart is something else. It's just like knowing, knowing more stuff and being helpful for solving problems. Um, and the, the second part was my coworkers were happy for me, at least outwardly.

• 1:04:46Speaker 00

  It was, but I was, I, I was really worried at, at the time because it was like new person joins team, gets promoted really fast, like. Do people see that as why not me? Or do they see it as, yeah, that makes sense. Right. When I ask questions about other people who kind of went up really fast to my period at the time. They would say things like, everyone knew it was gonna happen. Like there's certain people where people kind of know where it happens and you never know if that's the case for you or not. Or, or people are just like, man, I don't think that person deserved it.

• 1:05:20Ryan Peterman?

  So you've been working at Microsoft for over seventeen years now and. One of this tweets that you have is talking about big company tips that you have and it says, before you change roles, ask when the last reorg was.

• 1:05:37Ryan Peterman?

  What's the thinking behind that advice?

• 1:05:40Speaker 00

  Uh, big companies are, are a machine and I remember someone telling me really early on that league. And maybe it was, it was tongue in cheek. It was like, when you're, when you're, when you are, uh, an executive. Vice president at, at these companies or a CVP or whatever you are.

• 1:05:59Speaker 00

  You show that you're doing something like it's a motion, like reorgs are motion, emotion means that you're, you're changing stuff. And the only thing constant is change in these big companies, like there's always a reorg plan. There's always a, there's always a reorg coming. There's always a reorg that just happened and you're trying to figure out in between the reorg moments. What were like, who were the leaders? What was the, the impetus? What caused it to happen? I mean, you can never know when that's what's coming, but learning about the previous one is super. I think it's super important just to understand like where we are, where, where you would be heading, right? In, in that dimension, my org had a big reorg like recently.

• 1:06:40Speaker 00

  Previous meta person now runs, um, Jay now runs, um, my, my, my org and.

• 1:06:47Speaker 00

  I think it's super important to know that because it helps you figure out what the purpose is now. Right? If if it just happened, it tells you a lot about where the org is heading, where the team is heading, where things are going. Um, I think it's easy to kind of change teams or move around and not think about the overall

• 1:07:08Speaker 00

  place that org is going. But then Microsoft is big enough that is like every new org is a whole new company. So it's definitely worth while trying to figure out where what the goals are of that or where it stands now, what happened last time? Kind of thing. I I bet I I tweeted that after you did talking to a mentee. Um, who had been reorg and I think they had been like four in a row or something like that. That's crazy. Um, or or it happened to me, but yeah.

• 1:07:36Ryan Peterman?

  I see. So you're saying you you should read the behind the scenes of the reorg and what that means for your career in the future?

• 1:07:42Speaker 00

  Oh, yeah. Hmm. Oh, yeah. I heard someone say something to me recently that was really good advice. It was where you're looking to change jobs, don't think about the things you love. Because they'll be easy to do. Think about the things you hate. Like, what what can you not stand about, like, working in the area or an environment or whatever it is? And go look for that. If you see that, that'll be that that'll be the thing that will be hard to to get around or work through. Let's say you hated open space and you wanted a closed office. If the company was open, like, don't go to the company that is open space because, like, then you you'll be unhappy, right? Um, there there are better examples that are probably more toxic about like people, but that's a simpler um way of describing it.

• 1:08:25Ryan Peterman?

  You you've been at Microsoft for a long time, your entire career, even including your internships. I'm I'm curious what has kept you at Microsoft as long as you've been?

• 1:08:35Speaker 00

  Yeah, every every time. Yeah, I I think about this myself a lot, like, what keeps me here? And I think I am part of a generation of millennials who brought the curse of like our boomer parents, like, trying to stay in the same place forever. I have a lot of friends that jumped thrown and they got paid for it and it was really good for them in their careers. I want to say I maybe they didn't take the same path and and it it kind of worked out. Um, I had a couple of times where probably the most impactful time where I maybe almost left. Was when I was senior, my boss left and went to Twitter, pre-IPO Twitter.

• 1:09:18Speaker 00

  And a year in, she tells, she pings me and tells me to come like go interview at Twitter. And I actually interviewed at Twitter and at GitHub, so I get about Twitter um at the same time. And I got to, I got both offers and the offers were pretty good. And it was the, probably the first time in my career where I was like at a crossroads. So because my career had been going fine, I was working on Signaler, I was like on the up and up. But then here's this offer that like seemed a lot better and they're pre-IPO companies like, should I go? Um, and there, there was a lot of deliberation as to like if I should go or should stay or not or whatever.

• 1:10:01Speaker 00

  Um, I ended up staying and it worked out. But I will say the morning like Twitter went public. Instant depression.

• 1:10:17Speaker 00

  I was depressed for like a week. Say, oh my God, oh my God.

• 1:10:21Ryan Peterman?

  What, what kept you at mark? Cause it sounds like those offers were better than what you were making at the time.

• 1:10:27Speaker 00

  Yes, they were, they were. So when I, I, I got, they, they, they countered and the counter was fine. It wasn't like, I mean, I guess looking back, no, it was pretty good, but it was, it was fine. Um, but they, they had me talk to like our executive vice president. And he was like, you're going to be like a design engineer in like five years. I mean, he definitely oversold.

• 1:10:53Speaker 00

  But I was, I think maybe for me, it wasn't just the money that, that made me stay. It was like, I had been working on something that had built up some path full that was like built permissionless.

• 1:11:07Speaker 00

  I had, I think at the time I had been getting a lot of autonomy at Microsoft and leaving would have been like starting over. Um, probably one of the, one of the things that people don't talk about when changing roles or leaving or getting a better offer somewhere else is you build up a network, a network of people, a network of, of, you know, a track record. I can kind of work on what I want to work on at, at the, at the moment. At that time, maybe not so much, but I think I had been given more, more autonomy. And when you're weighing the, the like, should, should I stay or should I go is like, money is one thing. Um, the other is like, are the people like, are, are people good?

• 1:11:51Speaker 00

  Not just good engineers, but like good people that, that, but, but you want to work with. So there's the, the people aspect, the money aspect, the network aspect, all, all these things kind of matter in, in the soup. And I think I stayed because at Microsoft, I had been getting my fix of working on a new thing. Every couple of years, every, if on my LinkedIn, there's like a new project every two years. And now it's like by design. Um, I think it helped me not get bored or not like, kind of like be, um. I didn't, I didn't feel the need to, to go somewhere else to, to do what I want to do because I felt like I could do it on Microsoft. So that, that kept me here for this long.

• 1:12:33Speaker 00

  Um, I mean, I, I won't say that I hadn't thought about leaving every now and then. It does, it does come with my brain every now and then, but I think so far the people. Um, the pay for me is, is fine. Um, the, the people that pay the project. The impact I get to have working on what I work on is a, is a big, big thing for me as well.

• 1:12:55Ryan Peterman?

  Do you think that if you had a mentee today facing the same decision, so they're, they're at Microsoft and they, they're doing well? And then they have, uh, you know, pre-IPO, OpenAI offer something better than what they have now. Well, would you tell them you should stay at Microsoft or would you say, you know, maybe go with the risky thing?

• 1:13:18Speaker 00

  I would tell them to go.

• 1:13:23Speaker 00

  So fun story, I actually had a mentee who got an offer from a separate, a different company. But they weren't in a place where they could do their best work.

• 1:13:36Speaker 00

  So the combination of the offer plus that, I was like, you have to go. I said, they're gonna counter. But you have to go, you can't stay here. You should go, you should go. If I had that for myself, maybe I would have, I would have been gone.

• 1:13:54Ryan Peterman?

  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. It's a humbling experience.

• 1:14:09Speaker 00

  That's a good one.

• 1:14:09Ryan Peterman?

  So I, it could be better for long-term growth in some cases.

• 1:14:16Speaker 00

  Yeah. So what I would say, so that one, that tweet was inspired by, my career has always been this like, work on a thing and move on. I always still have ties to the thing I worked on, help people that are working right now, whenever things go wrong or whatever. But the, the thing that I'm, I have worked on for 10 years, Donnet Core, was the longest of ever, was not anything in my career, ever, ever. And I think it was a good, it was a good change. Because it really helped me appreciate like, deciding to do something in the first two years. And then holy crap, seeing the impact of that decision, whether it be bad or good, right?

• 1:14:57Speaker 00

  It, it gives you a whole new skill set, perspective on how to make decisions. And for, for some things, it's, it's obvious and you can say, okay, well, we didn't understand it at the time, the scope or the scenario or whatever else, but things that didn't seem important became important. One of the jokes I make about, you know, when you work on something for 10 years, all the small issues you thought were small, that were just like, we can do it later, will become big issues at some point. Like somebody will hit everything that you planted. And it, it, it happened. It, it, all of it happened. And I thought like, I think maybe if you think about 10-year projects, 20-year projects. Who knows if it's good for career growth?

• 1:15:43Speaker 00

  Maybe not, like maybe if you work on the same for twenty years, like, oh my gosh, not, not great. But it'll teach you a different skill set. That is like, you get to understand the implications, you get to understand, you know, if you were going to build the next, next version, you would have much more insight into like what you messed up. It's really hard to appreciate what you messed up when you like do a thing and you, you leave. You, you, you should be one, all good, new project. But I don't, I don't fault anyone for like doing both things, because I've done both too.

• 1:16:13Ryan Peterman?

  Yeah, I could see it better for, I guess, developing judgment. But I, and I could also see it being, you know, imagine a career that's a, a leg of jumps. That could, and if, assuming every jump is higher than the other, that person's probably 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.

• 1:16:38Speaker 00

  Yeah, yeah, exactly. It's funny, I, I told someone, I don't know exactly how to, 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 and like seeing which things work out, which things don't work out. Um, it's kind of fine tuning, I guess, an internal model in my head. Okay, this, this has the smell of something that can be successful versus, versus not. And there are some things here that I've seen that work out well and some things that are not working so well and yeah.

• 1:17:16Ryan Peterman?

  Coming to the, the end of this, I, I kind of want to ask you some, um, just high level reflections and things. Well, one thing I'm curious, 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 Microsoft, at least in terms of stock performance. Did you notice anything internally, like the culture shifting when Satya became CEO?

• 1:17:43Speaker 00

  Huge, I mean, I, I always tell new hires that it's really hard to.

• 1:17:55Speaker 00

  Think about the culture shift between Satya and Ballmer. Because you, I lived it, right? You like, I was in it. And it's really hard to see the big jumps where we are now to where we used to be. Um, because it literally happened gradually. It was like things were rolled out and there's a lot more.

• 1:18:14Speaker 00

  The culture just changed completely, right? Probably one of the biggest ones I I noticed. Cause I I I experienced this when I joined there was. Teams competing.

• 1:18:26Speaker 00

  On the same. And and go like two different teams that I think I think historically, there's been a. Microsoft used to do this thing where two end teams could work on the same end state and then one would win. And the other, who who knows what happened, the stand and regard, something else. Um. There was a big focus on collaboration. Over like, just like being the first, the first to do something. I never experienced it myself on my team, but I definitely worked with teams who. You could tell we're kind of building the solution before knowing what the problem was. There's a lot of that um that I saw when I was and. I was, I I was, I was an observer. I was like very early in career.

• 1:19:09Speaker 00

  Like observing how people interacted and culture wise and. Just the way people interacted changed. Like meeting culture, like. How means with with a pair or emails, things that seem so obvious in hindsight. Like if I look at how people would communicate in meetings now versus emails. Versus how I used to work, like remote friendliness versus like how people work in teams like, I remember being in a meeting. And someone raising their hand on teams, I was like.

• 1:19:42Speaker 00

  Raise your hand for talk, what this is not itself. Cause I I had, I had grown up in a culture where you would just talk, right? You just talk, you you don't, you wait for a pause and you talk, you don't, you don't raise your hand to talk or you don't like. Maybe it sounds crazy, there's a lot more consideration for everyone else. It wasn't just. What's it called? Um, highest paid person's opinion?

• 1:20:04Ryan Peterman?

  Hmm.

• 1:20:05Speaker 00

  I think that's, that's kind of how Microsoft, when I joined, like. If you were in a meeting with people that are very senior, um. Hard to get worded sometimes. And if and if the, if the most, the most senior person was. Load and like aggressive like people that people that didn't think that way in the moment would not get safe.

• 1:20:25Ryan Peterman?

  Wow.

• 1:20:25Speaker 00

  I think one of the big changes was in like how we communicated as a as a company, as a team. Collaboration became a thing that was part of your review. So like if you were not using, if you were not trying to use things that other teams built, like you were dinked for it. If you were gonna copy and create a a clone of someone else's thing because you're special. No, the incentives push you in the opposite direction. I think that's probably the most impactful change that and. That and the. Style of comms was like a big change that I observed. Just like existing in those time, those times.

• 1:21:07Ryan Peterman?

  I see. Okay, so the culture shifted through performance incentives and maybe just some of the stuff that was messaged top down.

• 1:21:15Speaker 00

  Yeah. Yeah, and and and the behaviors are that were being modeled by like.

• 1:21:23Speaker 00

  The leaders. Like literally in meetings, people raising their hands, people. Calling people who haven't spoken like imagine you're in a meeting. And there's someone really quiet that has really good thoughts, but maybe they don't, they don't like to speak up in meetings. Pulling out that person in in the meeting like I remember when that first happened, I had never seen it before. I had never seen someone say. Um, hey, Ryan, you're quiet. You've been quiet the whole time. What's your opinion on on this matter like that? There was just. People talking and then you would leave. Now there's a lot more. It's much better, much more considerate for others, um. A lot less people screaming, shouting. I was in me like really early in my career, people were like shouting. I remember thinking to myself like, there's no.

• 1:22:11Speaker 00

  I'm gonna have to shout some point.

• 1:22:12Ryan Peterman?

  There's a famous X K C D comic about the culture at different companies. And if I recall correctly. The Microsoft one is a drawing of people with guns.

• 1:22:21Speaker 00

  The guns.

• 1:22:21Ryan Peterman?

  Point at each other.

• 1:22:23Speaker 00

  The guns, yeah, I it's so funny. 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. So I think that progression is probably the biggest change in between Bomber and Satya, the the joke about the guns. To, I don't have a gun at you, but you know, as long as you aren't gonna like disturb disturb my. My situation, like, we're good to go. You're over there, I'm over here, it's all good. To collaboration, where like, we incentivize collaboration, you get rewarded for collaboration also. I think that was the biggest, the biggest shift and change I saw in the culture.

• 1:23:04Ryan Peterman?

  When you look back on your, your career so far, do you have any major regrets that people can learn from?

• 1:23:11Speaker 00

  It's a good question.

• 1:23:14Speaker 00

  Major regrets? Major? Maybe not. I, I would say, early in my career, don't say super arrogant, I, I was, I was very arrogant. Um, you could probably find my GitHub, if, if you, if you look at some of the. GitHub comments and the tone, I would say I was lacking some empathy in a bunch of different places. One of the big shifts that I think my brain made over time, learning how to build teams and kind of impact with others. Was like patience. Patience, empathy. Um, those two traits helped, help a lot with like growing teams and growing like influence and people, right? It's not just because.

• 1:23:58Speaker 00

  You're right, being right means nothing, this is not important, right? Being right is like, one of many things. Um, and I, I used to want, I used, I used to like. I'm right, therefore, everything else is like, will follow along from there. I think, learning over time that this, that doesn't really matter as much, because there's a lot of shit that's great. When you're in top range areas, this is not the most important thing. So I think, early in my career, I was very much like. Yeah, I'm right. Like, I don't really understand where we're, where we're happening this. Why are we still talking about this thing? I'm right. Uh, and every now and then it'll creep out, but like it, I think I, I have a lot more self-awareness now whenever

• 1:24:38Speaker 00

  that's not the most important thing for the, for the moment, even though it's like a thing still, I learned over time how to dial it. Um, but in general, yeah, maybe the fact that, that I didn't leave and go to Twitter because I would have gotten like a ton of money as a senior engineer. Um, or go to, or go to, or go to Facebook. I, I had a bunch of opportunities. I just didn't, I didn't take it super early on. Okay. One regret that I do have that is not directly career related, but like maybe in the same ballpark. Um, I had a friend in two thousand and eight who sent me a message. He was gonna do a Bitcoin company. And I was like, I love this crypto thing. Dude has so much Bitcoin though.

• 1:25:25Speaker 00

  What, what? Oh my God.

• 1:25:29Ryan Peterman?

  That's so funny.

• 1:25:29Speaker 00

  Yeah, that, that one.

• 1:25:32Ryan Peterman?

  Um, when you look back on your career, what was your work-life balance like throughout?

• 1:25:37Speaker 00

  I used to answer this by saying, um, there was no balance. There was just like work hard, play hard kind of thing. I would say no, someone told me recently that work-life balance isn't about nine to five and stopping. It's about what things give you energy and what things drain energy from you. So early on in my career, I was working all hours. I still do. Because I enjoyed what I was doing. And maybe a little too much. So I would just like have to dial back every now and then. But I enjoyed what I was doing. So I worked a lot, like at work, after work, like on different things. Um, because programming for me was not just my job. It was like my passion. So I,

• 1:26:21Speaker 00

  I never forget one, one summer I came back from vacation. I started making games. Just like for fun. Um, and I learned a lot of making games. I took that into things that worked. I was doing and more stuff. And for me, it was always, I just love building stuff. So I want to build more stuff. Um, what I would say is draining now is like meetings that just don't feel like they have a purpose. If I were in meetings all day and I felt drained after work and I kept doing more work, that to me was feeling no balance. Cause I, I want to do stuff that isn't meetings. Um, I'm not doing that during the day and then

• 1:27:01Speaker 00

  then I'm going home after hours doing more work. That is like burnout quality. So I would say like balance was always, I work a lot. I'm absolutely over calling for me. This, I, I love this career. It is, is, is kind of insane. I, I get to code for, for a living. So I, they, I see that as like a privilege that I'm going to keep doing until I can't do it anymore.

• 1:27:28Ryan Peterman?

  Yeah. I think when I look at a lot of people's careers who have been, you know, as successful as you, the, that's one of the unfair advantages I see almost everyone has is they have this innate intrinsic motivation. So they, they work a ton of hours just nonstop and, and a lot of like, like you, a lot of people love it. And that is such an unfair advantage.

• 1:27:50Speaker 00

  It is. I, I saw, um, one of Andre Karpathy's talks and he said 10,000 hours to get good at anything. And maybe it's not true, but I, early in my career, and maybe even now, I wanted to become a very good software engineer. Right? And people always ask me, hey, what book did you read? What did you, what, what did you do to become a good software engineer? And I'm like, I wrote and read a lot of code, like just anything you can get your hands on. And there's so much more code no there you can read, consume and write.

• 1:28:31Speaker 00

  Um, and I'm, I'm not sure if it's good advice, but why no is that I did not get good at software engineering or building, building or programming, whatever you want to call it. From like seeing something online or reading a, a blog post or it's like, just do it, like build everything. Database, distributed systems, games, like every, everything you build will teach you a new skill that you don't even know you have until later on. Um, my GitHub is a graveyard of projects. I just build stuff. And put it on there and it's like, I want to learn how to do. Um, multi, I don't, I don't, I don't forget. I, I tried to build a fighting game when I was sixteen. I wanted to build Street Fighter. So I got all the art from somewhere online.

• 1:29:15Speaker 00

  I started to build a Street Fighter clone. And it wasn't for any real purpose. It was just to learn how to build a fighting game. Where do you make key combos work and how, like, how do you make that stuff work? Um, and that pattern of like, I need to know how this thing works. Has served me like to this day, right? Like I need, I need to understand how the thing I'm doing works. How do I get this thing to be on that thing? Um, yeah, so I, I love what I do and I think that has helped me um, do it more and get better at it.

• 1:29:51Ryan Peterman?

  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?

• 1:30:01Speaker 00

  Oh my God, negotiate your freaking salary. When I got my job, I did not know that I could even negotiate. I would have gotten more offers. I mean, looking back, it doesn't matter right now, but if I was going to talk to a new college hire, getting a job, like get multiple offers and like bump up that money, bump it up. Um, I watched my friends do it. I was, I was just like in shock. Like I'm from Barbados, I go to this place, I get an internship, I get a job. They give me the most money I've ever seen in my life and I'm like, thank you.

• 1:30:38Speaker 00

  Thank you. Um, thank you for the money. I'm, I have my job to hear kids talk about, yeah, I, I said no, or I said, I'm gonna go check out Google first or Facebook and get offers. Now it's just like, what? And that just became normal. That became the norm and it just, it blew my mind. I couldn't rationalize what was happening. I, I do think it's definitely worthwhile doing that. I, I've seen kids do it so well. I'm like, this is so impressive. This is just like, this kid is, is telling us no. And, and, and I've been, I've been like on enough hiring committees now to the hire interns. And I'm watching the back and forth between this kid and the recruiter. And I'm just like, this kid's a genius. Bump it up. It's offering. It's amazing. Mass respect.

• 1:31:24Ryan Peterman?

  Awesome. All right. Well, thank you so much for your time, David. Uh, really appreciate it. Um, is there anything that you wanna say now, or maybe where can people find you?

• 1:31:34Speaker 00

  Uh, I am available on X, Discord, um, Blue Sky. Are those the main socials? Are, are there more?

• 1:31:41Ryan Peterman?

  Yeah. I mean, there's LinkedIn. I don't know if you use it.

• 1:31:43Speaker 00

  LinkedIn, LinkedIn. Yeah, you're right. LinkedIn, David.

• 1:31:45Ryan Peterman?

  Yeah.

• 1:31:46Speaker 00

  It's funny. LinkedIn has become a social network is the most bizarre thing ever. I am on all these things. Tweeting about dot net and AI and all kinds of programming stuff.

• 1:31:54Ryan Peterman?

  Awesome. I'll put it in the links in the show notes. Thanks so much, David.

• 1:31:59Speaker 00

  Awesome.

• 1:32:00Ryan Peterman?

  Thanks for listening to the podcast. I don't sell anything or do sponsorships, but if you wanna help out with the podcast, you can support by engaging with the content on YouTube or on Spotify. If you wanna drop a review, that'll be super helpful. And if there's any guests that you wanna bring on to, please let me know. I feel like sourcing very senior ICs. There's no well-studied list out there on Google that I can just search this up. So if there's someone in your org or at your company who you really look up to and you wanna hear their career story, let me know and I'll reach out to them.