Getting a remote position at Microsoft with Scott Hanselman

About Scott Hanselman
Scott Hanselman, is a partner product manager at Microsoft. Since years, Scott is one of the most successful tech bloggers, he has three podcasts and actively works on making tech a more diverse place.

Read the whole episode "Episode 2: Getting a remote position at Microsoft with Scott Hanselman" (Transcript)

[Improve this transcript on Github.]

Michaela: [00:00:00] Hello, and welcome the Software Engineering Unlocked podcast. I'm your host, Dr. McKayla and I opened the doors to software companies and thought leaders around the world. Today. I speak to Scott Hanselman about how it is to work remotely for Microsoft. How to get such a position about making tech and more welcoming place, open-source and productivity. I'm super thrilled for this awesome second episode. I hope you enjoy it. If you like it, support my work by spreading the word. Tell your friends about this podcast, shared Twitter, LinkedIn, Facebook. I promise you I will do a happy dance each time you do it. So I'm really happy that, uh, today I have Scott Hanselman on my show. He's a real role model to me. And I think to many others as well. If you look at his profile, you're probably just left wondering how does he do it all? Yes, three podcasts. He writes books, he live codes and he teaches and has a day job at Microsoft. He also has plenty of side projects, but the main reason why I admire him so much is that he actively works on making Tech, more welcoming place for everybody. I've never came across a more diverse podcast that inspires me over the years. So, yeah, I'm a big fan of Scott and I'm super happy that he joins me today. So welcome Scott. Thank you for being here.

Scott: [00:01:15] Hi, thank you. That was a very kind introduction.

Michaela: [00:01:18] Yeah, really a big fan. So Scott, there's so much that I want to talk with you and maybe let's start with the fact that you're actually working remote from your home office for Microsoft. You did that already many years before it was sort of cool. Right. And yeah, I listened to many tips that you actually had online, how to make that work, but. I also want to pick your brain today because I'm also working remote and, um, I'm a big remote advocate. What I wondered is how did you actually come to work remote for a not really remote company? So how did you manage to get that remote job?

Scott: [00:01:56] Well, it really kind of depends. I mean, Microsoft is 130,000 people. I think it was 90,000 when I started. And, um, it isn't fair. I think, to take a company that big and say, Oh, it's remote friendly or, Oh, it's not remote friendly. Microsoft is like a hundred thousand person companies, or it might even be a thousand hundred person companies and each one, yeah, it has their own kind of like style. Well, there's the larger Microsoft you know culture. Different groups are remote friendly. Are they and others. And I happened to work for the developer division. We're about, I think the numbers are 22% of our folks are remote and I just happened to be one of them. I was one early because I work here in Portland and I just did not have any interest in moving to Seattle. All my people are here. My parents are here, grandparents. My wife's family is here. So leaving Portland would mean leaving 20-30, you know, relatives. So it wasn't, I just insisted basically I think is the, the, the, the answer. And I was fortunate enough that the bosses, uh, agreed with me insisting.

Michaela: [00:03:07] So I'm also working remote from Microsoft, but my story was a little bit different. I actually joined the team for some time and then I went to work remote it's even a little bit more complicated than that, but yeah. So you started already applying for a remote position at Microsoft, or did you have sort of a time where you were actually on a team and then you started working remote?

Scott: [00:03:29] So I have, I started remote and have always been remote, uh, but it is worth pointing out that I, I happened to be about 250 kilometers away from Microsoft headquarters, maybe 300, so I can drive up there in about four hours. So. It's a long drive and it takes, you know, a good part of the day, but I'm remote, but I wouldn't say I'm like remote, like a New Yorker or I'm not Germany remote. Right. It's not a full day and a half of travel. So, well, it's inconvenient if I left my house around six, uh, I could get there by lunchtime. So if my boss called me, like right now, come and have a meeting with Scott Guthrie, uh, you know, I could probably get there before the middle of the year. Yeah. So that is a bit of luck that I've got in my location.

Michaela: [00:04:13] Okay. Yeah, that sounds much easier than for me working from Oregon. And you're working from your home office and you said you're, you could actually drive there, but how often are you driving to the Microsoft headquarter?

Scott: [00:04:27] Well, like I said, four hour drive is a long drive. Right. And it's, it's also quite bad with traffic. So it's about six hours on the way back. I think I go there maybe every six weeks, maybe every eight weeks. It really depends. Right. I mean, like what kind of thing has to happen in person? That's the question you have to ask yourself when you're doing it. Remote work, white boarding, you know, collaborating, really seeing someone leaning forward and seeing their eyes in more than just a web cam. When, when do those conversations have to happen? Certain, certain HR conversations, certain, you know, deep collaboration, long, you know, full day architecture sessions can, can work better in person, team building. But most day to day what I call administrivia, you know, administrative work, trivial work, uh, I don't need to be there to delete email. Yeah,

Michaela: [00:05:18] that makes total sense. And while you are also a lot on the road, I imagine, um, how much of your work day is actually traveling and giving presentations probably throughout the United States or even the world.

Scott: [00:05:32] That's, that's funny that you mentioned that because there's a little bit of a, like a. I think there's a perception when you follow people on social media, that they travel more than they do because time compresses. So there's people in my neighborhood, my family and who, not my, not my family in the house, but like my parents who think I'm on the road every other week, I'm on the road about three to four days a month. So that's about 10%. Michaela: [00:05:58] It's okay not that much Scott: [00:05:58] about 10% of the time. Thrice month is 30 days. It's about three days, you know, sometimes four, if I'm going to go somewhere farther, but I'll go to Europe and I'll be there for four days and I'll come back. But if you don't think about me for three weeks, and then you see me on Facebook and then you don't think about me and you see me on Facebook and I'm in another country. You go, Oh my goodness. That Hanselman is always on the road. What's the deal. Exactly. Yeah. So I think there's a little bit of a, of compression of time, but no, I wouldn't say on the most, most, most busy time would be a week a month. And that would be for something like build or ignite or one of those kinds of things. So I find it quite manageable.

Michaela: [00:06:36] Okay. And, um, if somebody would like to interview for Microsoft, do you think that their standard chance for interviewing for a remote position from the beginning on

Scott: [00:06:47] Oh yeah, definitely. It just, again, it depends on the, the hiring manager and it depends on the group. If you go to careers.microsoft.com and you search for the word remote though, very often, you won't find anything. I don't think that our careers website has caught up. With the things it needs to do to be friendly to remote. I recommend that people interview the regular way, get as deep as they can into the process, convince them that, that you're you're necessary, that you're required. That you're the best. And then, you know, as you move your way forward into the process, bring the remote issue up. And if they love you so much that they can't not, they can't imagine not living without you then. Then they would hire you as remote. Michaela: [00:07:35] Then you have your remote position, right? Scott: [00:07:37] Yeah. Yeah. I'm not saying it's going to be easy, but you know, that's what I think. Michaela: [00:07:42] No, I think that's a good, a good strategy. What I was wondering, especially for the hiring is. Well, you also talked about that in one of your blog posts and you're, I think you're talking openly about that, that sometimes people have these imposter syndrome or they feel like a phony and especially for hiring, or if you're, if you're on the job hunt, you have to present yourself in the best light. Right. You have to give the impression that you can handle it all that they can't live without you. And then, well, even for. Applying to jobs maybe are not a hundred percent fit to the job description, but you still should still apply. I think hiring being in this job hunt position is a really hard one because you have to overcome this imposter syndrome, that feeling of being a phony and just present you in a very. Positive light, even though that can be sometimes a little bit tricky. What's your thought on that? Scott: [00:08:37] Yup. A hundred percent Michaela: [00:08:40] just get through it. Scott: [00:08:41] Um, no, I'm agreeing with you. Like I'm feeling like you understand the challenge and the problem with this kind of thing. If you do well in an interview, I had to, well, let me, let me give you another, let me back up, I'll give you an example of someone who just got hired. I've had about 14 people that I've encouraged to come to Microsoft and about 11 of them, Memphis and remote, and will most recently, one of them got halfway through the interview process. They were starting to get an offer. They brought the remote thing up. They thought the offer would disappear. But then they, he said, well, I could come and live in Redmond for two months in an apartment, and then I will be remote. So they, they compromise, they negotiate. And then that worked out. Does that make sense? Michaela: [00:09:18] Yeah, that makes sense. Yeah. It, that, you're also showing that you're well understanding the problems that come with the remote world, because if you're starting with a team and you don't know them, right. It's, it's quite a challenge. You don't, you don't get it as easy if you're onsite and you can work through like those two months and get to know everybody, get to know the processes. I mean, Microsoft isn't, it's a big cooperation. So you have to also understand. How people work, how the organization works and all of that. I think it's much easier if you are onsite than if you're in your own home office and trying to catch up, uh, what's actually going on around there. Scott: [00:09:58] Hmm Exactly. Michaela: [00:09:59] So are you, are you hiring, bring yourself, are you involved in the hiring processes at Microsoft? Scott: [00:10:05] So there's, there's two different things there there's that when people say, are you hiring Microsoft, always hiring. Um, because there's always people coming and going. There's always this seasonal come and go. Like we're coming up on review time right now. And that's a very common time for people to move to other, other projects, other divisions, or sometimes leave the company. Uh, am I personally hiring? No, I have a team of four, but I do get involved in the hiring process. So I'm very often on, what's called an interview loop. So if you come to Microsoft and do an interview, they call it a loop. Cause you're kind of going around and talking to lots of different people. So I am a very often when one of the loop, the looping interviewers Michaela: [00:10:48] and what are you looking for? Um, in interviewee, what are you looking at qualities? Are you looking for in a person that interviews at Microsoft? Scott: [00:10:57] I've always said that I cared about problem solving. And everything else can be taught. You know, if you come in, you're able to break problems down. I am not interested in trivia or that, you know, MSDN or you've memorized and API or, you know, everything there is to know about some keyword. You know, I want to know that you understand systems thinking and how systems work together and the recognition that there is a system. Um, I gave an example recently where I was, I was helping volunteer at a, uh, an event for some young people and they thought we were going to talk about coding and keywords and public class, this and JavaScript that. And instead I said, my toaster's broken. Can you tell me how to fix my toaster?
Michaela: [00:11:46] That's a good one Scott: [00:11:47] and all the ten-year-olds are like, um, what, uh, okay. You know, and, and then one of the little girls says, well, does it, if you plug a lamp in to the same place that toaster's plugged in, does the lamp turn on? And I knew, right. That's a programmer, isn't it? Yeah. Right. Yeah. I mean, she's never program, she's only 10 or 11 or whatever, but she's like, well, hang on. Is there power? And then they started as a group. Debugging the problem, you know, they don't know about fuses, but they know that mom or dad has a switch in the garage and they go and they figure out the fuses. And then one of the kids says, does the neighbor's house have power? Wow. What a good one? Like is the power out in the, uh, in the entire city? You know? So then we start working our way through this. So I thought that was kind of cool. Michaela: [00:12:38] Yeah, that's really cool. And would you also do that in an interview loop at Microsoft? Did you give a similar example? That's a little bit far from, well, from the day to day job of a developer for example. Scott: [00:12:51] Yeah. So, so there's actually, if you go and Google for John Montgomery interview, John Montgomery is. Program manager of Mesa manager of program managers PM of PM's, uh, at the developer division. And he works for Julia, who is the VP of visual studio and all of the developer vision. So John basically owns visual studio and he is, uh, rolled out recently on all new kind of interviews system, by which rather than a. Random parade of random people asking you random questions. Instead, you're given a larger problem to solve as if you were kind of a consultant and we make up a problem. And then you spend time working with the actual people that you would work with and you. Brainstorm solving that problem and tell towards the end of the day, you have a more complete understanding of the problem and the idea isn't that we're interviewing you so that you have the solution to the problem we're interviewing you to see if you're a person who can help solve problems with. Right. The idea is that when you ask questions, people always assume that there's a correct answer, but really the right answer might just be a really good question. That moves the rest of us forward. Cause we don't necessarily know, you know, the answer to these things. Michaela: [00:14:05] So how old are you actually described this interviewing process? Somehow also reflects a little bit on my, my question that I have. What do you do if you feel like a phony or have this imposter syndrome? Because if you don't have to get the whole thing completely right. Or to know exactly all the technologies that are on the job profile, but it's more about the way you're thinking and the way you're approaching a problem than somehow becomes at least in my mind, more accessible, more, a more doable as well. Scott: [00:14:38] Well, one of the things that we figured out when we started changing, how we interview at the developer division was actually recognizing that not everybody does their best work. In high pressure situations, right. And interview, it was very high pressure. You have a bunch of strangers asking you questions, and if you do have imposter syndrome or you're anxious or whatever, you're very likely to be thinking. This is a nightmare, right? So we want to put together that if, if we recognize that some people have this feeling, and if you, the interviewee also recognizes that, then how can we make it comfortable? How can we not make it a, a thing where I'm on one side of the table with a bunch of scary people. And you're on another side of the table with a bunch of scary people, and we're going to just throw questions at you and really make it not a fast paced. Thing, but somehow a let's sit down and have a cup of coffee quietly, slowly, low pressure brainstorm. Talk about the topic and see what is the ideal way to work with this person. Like maybe we write some things down. We, maybe we share the interview in advance. Wouldn't you love being prepped for the interview by the interviewer. Michaela: [00:15:49] I mean, that would be awesome. Scott: [00:15:51] Yeah. We can tell you the problem. We're going to work on. In advance. Like the idea is that going to an interview right now is a surprise, right? Surprise. We're doing Ruby today. Surprise. We're talking about, you know, you don't know you, you can guess, but it's like you spend all this time thinking that, but not going to work every day. Isn't always a surprise. Why does an interview need to be a surprise? Michaela: [00:16:13] Yes. Sure. Yeah. So is that actually as something that you are already doing that you're prepping people. Scott: [00:16:19] Yes, that is absolutely how the, how the program managers at the developer division are interviewed right now. So what, what we do, we, we share the interview in advance. We give them an actual problem and, uh, often we'll give them a real problem that the team is trying to solve something we're actively working on that way. They don't feel like it's some like, Hey, we're going to make a tic TAC toe program in C#. We'll also give them some data, you know, give them some customer research, some mockups and stuff. And we want them to understand that it's not, we're asking you questions. It's we want to work with you because we're going to work with you for years, right? Uh, we want to find out what it's like to work with you. So we're, we're in a, we're working on a problem together as opposed to we're looking to you for the one solution. Michaela: [00:17:06] Yeah. That sounds really a good process. Is that because at Microsoft are several stages as well. Is that before you're actually onsite or is that already, when you have an invitation to come onsite and interview with the team? Scott: [00:17:18] Well there's phone interviews. Some of our interviews are remote and interviews on, uh, on teams on Skype. We also have avoided, we're starting to avoid one-on-one interviews now. So we always have two people per, per interview. Like. Uh, rather than one-on-one where like one person talks to one person and then they bring another one person. We try to pair up interviewers. Uh, sometimes that's remote sometimes that's not, it really just depends on the situation. Michaela: [00:17:44] Okay. And one of the things that I also wanted to talk to you about, and I think it's fitting into dad hole. Topic that we just discussed is culture. Right? And well, especially with interviewing sometimes there's this need or this feeling that you want to have actually a cultural fit. You want people that are like minded, but I think for having a more diverse workforce, sometimes you have to look out of the box. Scott: [00:18:09] Hmm. Michaela: [00:18:09] Okay. I know what I mean. So obviously yeah. Resonating with somebody and that's a good, it's a good sign, right? If you're resonating and you're thinking in the same direction and it's clicking, um, that are all good signs, especially for interview or also for working environment. But on the other hand, if you want to make it a more diverse workplace and have be more welcoming for people that are maybe thinking in a different way, it can be really hard to overcome that urgent. It needs to have those. No relations with each other. I sometimes feel that it's, you know, there are two forces that are pulling into two different directions. Scott: [00:18:45] Can you talk more about that? Michaela: [00:18:47] It's not only interviews, it's also working environment. Sometimes it's people want other people to think out of the box or, you know, be creative, but on the other hand, if you don't have this. Immediate response of Oh, via resonating or I know where she's heading or he is heading towards, then we also start building up boundaries and say, well, we are actually not fitting together that well. And I always see that, you know, as something that makes it difficult to build very diverse workplaces. And if we reflect about that more openly, maybe just give more time. Maybe it's all that it takes us some time to be open and say, well, I really don't know where you're heading, but you probably have good reasons for the direction that you're going. And let's just look where, you know, but the whole thing ends. Scott: [00:19:40] I think that the point about how people think differently, you might think differently because of your gender or your age or your, your environment or your background, or any of a thousand different, right? There's a pie chart of all the different things that make you up. And it's very easy for someone to say, Oh, our team is five men and one woman, and she thinks differently. But the team might be two young people and two older people and a veteran and a disabled person. And, you know, there's a thousand different things. You can be different about different people. Um, but when, when, when there's an obvious. Thing that can be othered. Where someone can say, Oh, she's different. She's the other. Then they can use that too. Subconsciously miss your ideas because they don't flow like two people who went to grew up in the same town who went to the same university who taught from the same teachers. They speak the same language. So if they're trying to solve a technical problem, they go, duh, duh, duh. Oh yeah. I said, Oh yeah, great. Sounds good. And then you're like, Whoa, Whoa, Whoa, what happened? And you try to make your, your argument and then they get maybe one minute, two minutes in and then they start to dismiss you because it's not because they're dismissing you. Necessarily, although it's possible specifically because you're a woman is because you're not going there. You don't speak their language because you didn't grow up with them in the same town and go to the same school. So we all in tech have to be patience. With each other. And in the example, we just gave it's really on them to be patient and give you some time to present your ideas. Think consciously that your thinking process is different. And then if you can have like an ally or a person who can be with you, who can back you up in a meeting, hang on, hang on. I think she's making a good, good point. Hear what she's saying? Duh, please continue. And then that's really team collaboration. And then they'll learn your language. And then ideally the whole team will build a new language. Right? When I say language, I mean, just kind of the, the, the shortcuts that we use. To express ourselves to communicate the three letter acronyms, you know, all the Microsoft isms or whatever. Michaela: [00:21:58] Yes, that's exactly my point. I think that sometimes it's just the time that we have to give others and also some patience and some, you know, also put some trust forward first, like thinking that what person has to add to the story or to the, to the problem is actually valuable and not dismiss it at the beginning. One of the things that goes also into that direction is I try to, for example, get into open-source recently. And well, I searched for how to pick the right project, the right technologies and things like that. And I came across also your First Timers Only website where you line out this process and try to make it easier for people to work with open-source. And I think here something similar is happening. You're an outsider. It doesn't matter who you are, but if you haven't worked in open-source yet, you're sort of, sort of an outsider and you have to really understand the whole processes that happened there. So I went through those whole steps and this guide, and I think that's really helpful to understand how to make a commit and pick issues and things like that. But one of the things that I came also across is there are several people raising their hand saying, Oh, I want to work on that. Michaela: [00:23:13] And then nothing happens. And then another person says, Oh, I want to work on that. And then nothing happens. It didn't do a very exhaustive search, but I saw pattern over and over. And what I started to think about is what's the best way the approach to help people get into open-source. But on the other hand also, Being able to identify who are the people that actually follow through or why aren't some of them following through, is it, is it because nobody raises their hand and says, well, I help you with that. You want, and to help you, are you waiting? You know, I was wondering, are you waiting? But he says, Oh, I help you with that. And that's why nothing happens. Or. Oh, or the other way around that people helping and then they are not following. Scott: [00:23:55] Well, I do think that there is a certain thing in open-source that I, I have you ever heard the term, their eyes are bigger than their stomach. You know, when you want some cake and you have a piece of cake and you. Give a nice big giant piece, but then you realize after the fact, Oh man, this cake is too big. I think the same thing, very common problem. I think often in the space of open-source, people's eyes are bigger than their stomachs. Uh, it's easy to say, I'll take that feature, you know, I'll take that bug and then you realize that maybe you've gotten in over your head. Uh, so the, the easiest thing to do is just to do, to do that nothing. And I'm not trying to blame anybody. I'm just pointing out that that's just. How things happen. It happens in all things in life. It's, it's the same thing that happens with that. You know, that email that's been sitting in your inbox for three months that you really need to spend time on. It's really, really important email, but it's still been there for three months and nothing's happening because it's just so big. It's such a big deal. I think that if you're. In a community already. And you know, the people, I do think that coaching, helping some accountability. Hey, do you need any help on that feature? I noticed it hasn't moved forward is helpful. If they are total strangers, that's hard. Like if a total stranger has said, I'll help you that feature, and then they've done nothing. It's kind of difficult to go and say, Hey, total stranger. I thought you were going to help me with this free thing that we're doing for free in our spare time for free. Right. Okay. Yeah. So I think that, yeah, the best way to get people involved in open-source is small stuff. Get them, get them working on docs, get them doing tests, help them do things so they can have an early, uh, an early win. Right? If the first thing you do on open source is a complete feature or a complete redo of something. That's asking an awful lot, I think. But if the first 10 things you do are tiny bug fixes or one liners, I think you'll be more likely to kind of get the open-source bug. Then you'll be known. And they'll say, Oh, there she is. She's helpful. She's helped us in the last, last month with a half dozen things. Uh, and then you're going to feel appreciated and like someone who can ask for, for help and they're going to go, Oh yeah, of course. You know, she has reliably shown up for small things. Now we'll help her with this medium thing. And then you'll do the same because now that you're doing medium things, you'll look backwards. Down the ladder and you'll help people come up the ladder by helping them with small things. Michaela: [00:26:27] Yeah. I like that. I like that a lot. Actually, when I looked at that, that's also what I thought it's probably the best approach is to consistently show up and while do your work, and also build those relationships with the people that are working on that open-source project already so that they also know that if they invest their time in you, it's not sort of wasted. Yeah. Um, one of the things that when I look through your profile and what you all do is, I mean, as I said, at the beginning, it looks like, well, how do you do it all? And I also watched your, some of your talks about productivity and how you focus on, well, the things that have to be done or that. You know, bring your closer to your end goal and be able to cut out all of the distractions and say no to things that are not helpful. I think that's and you also made this, um, this point that you noticed this efficiency and effectiveness and you can run, you made this point that you can run really fast if it's the wrong direction. Yeah. And that would bring you closer to your goal, but how are people, do you have some thoughts on how you actually find your goal? Sometimes, especially if you're new to something while it's, it's more like a fly going in a little circles and trying to get, you know, to Indoor And so it's, it's not always Linear, I want A to B because you actually don't know where B is. So you don't even know if you want to be. Scott: [00:27:55] Right. But you look busy and you feel busy cause you're moving, right? Yes. The fly who's running in a circle trying to get to the window. Sure. Feels like it's busy. Michaela: [00:28:03] But how can we cut through those search times? So how can we make that more efficient? How can we know what we are actually looking for? What we should work towards, especially. Yeah. If it's unknown, like say you're really new in Tech, and then you look through all these technologies that they are, and then you look at the different companies that there are. And you're just wondering, you know, should I learn JavaScript or should I learn C# should I learn react? Should I. Just pick a company that I want to work for and then learn their tech stack. You know? So there are many different angles. I think it's easier if you know where you're heading to, how can we make it easier for us to understand where we are heading? Scott: [00:28:43] That's a tough one. There are things that will happen in your life that will happen simply because you were lucky and you were in the right place at the right time talking to the right people. And if you over plan, then those spontaneous things don't necessarily happen. But I think it's more likely for people to under plan a there's a lot of folks that let their lives happen by default and whatever happens happens. I tend to not only plan more, but also try to sit down and think about what the plan is. One of the examples that I give in some of my talks on productivity is when was the last time that you sat down and made a meeting with yourself? To think about your day and what you need to do. So like how often does one say, you know, I'm going to put a meeting on the calendar for one hour to sit down and make a plan. But instead we rushed from meeting to meeting, to meeting, to meeting or from bug to bug bug. And again, we are the fly running in a circle as opposed to stopping landing for a moment. And then looking around the room and thinking about which direction the windows in. So. I guess what I'm suggesting is some amount of intentionality. Does that make sense? Just sitting down and intentionally deciding you don't necessarily have to be right. It's just nice to make the choice. I think what happens is we get analysis-paralysis where we make, we were prepared to make a decision because we think it might be the wrong one, but I would propose that it, at least it is a decision. So I think. To sit down, take stock of your situation of your day of your life of your month and break it down and then pick a direction remembering that you can always change direction as long as you do it with intention. Michaela: [00:30:37] Yeah, true. So one of my questions and maybe a little bit differently phrased would be you wrote a book, you started those podcasts, um, you're doing those talks and going to conferences. Is this a master plan behind that? Or is it just because you're really liking that? Like, is it for me, for example, writing a book would be. Well, I like to write that book. I like to talk or think about it subject and they write that book. There wouldn't be a real big master plan behind it for you. Is there something like that, do you think? Well, those are the steps. Those are the things that I have to do too, you know? Be in that place in two years or three years? Scott: [00:31:14] No, no, there's no master plan. Is this podcast, your master plan? No. Yeah, you're doing it because it's enjoyable, right? Yeah, exactly. Yeah. Michaela: [00:31:23] So I do most of my things like that. I do pick the things that I enjoy and then do it. Scott: [00:31:27] Yeah. And it's great. And then what'll happen is you'll do the podcast and maybe you'll do some video stuff. You'll give a presentation at a conference then. Then you'll go and do one overseas and you'll put international speaker on your talk and then someone will refer to you as an influencer with a podcast as an international speaker, and then you'll go on a podcast. And some of them will say, was that part of the master plan? And then you'll be like, uh, Oh yeah, totally. A hundred percent master plan. Michaela: [00:32:00] Yeah, exactly. I mean, that's what I hope everything turns out. Right. Just did you follow your heart and then. Thanks. Lead your way. Yeah. Yeah. Scott: [00:32:12] I'm glad you and I have the same master plan. Michaela: [00:32:15] It's still what you enjoy, right. Yeah. Yeah. Um, so I actually ask people yeah. On Twitter also, what they would do like me to ask you. And I think some of the things I already asked you, so it was about working remote, but one of the questions that the person had was about more about processes at Microsoft. And so one was for example, about devOps, if that's really something that Microsoft invests in, if we have devOps roles and if. Don't know, companies should also change their whole product life cycle to use devOps? I know it's coming complete different ends, but I wanted to pick your pain and just ask you if what's your thought on that. Scott: [00:32:58] I think that devOps is a very nice name and a very nice rebranding. Towards continuous software development, which is something that has been happening since the days of extreme of XP, extreme programming and techniques like that. Um, I was working almost 20 years ago, uh, checking software into a system. That would then build the software and it would test the software, send a report out to everyone on the team. If the build broke, it would send off a siren. We had like a police siren, like a klaxon that goes on the top of a police car and it would. Tell you, if you broke the build, it was called the siren of shame. And, uh, we would then produce a virtual machine that the sales person could then pick up and take. So each build produced a virtual machine that could be picked up and taken off, uh, and shipped. So that was devOps. We just didn't know it. Cause it was 20 years ago now. Everyone who was in the space of, of kind of extreme programming or pushing what was software engineering to the limits that at those times was experimenting on what's the best way to create software, not the computer science of it, but the actual software engineering of it devOps is just really great branding of the thing that has been done for many years. But I would say that devOps in 2019 is extremely refined. Well, 20 years ago, we were just making it up and trying, you know, fail fast, fail often. And we were, there was no real formality to it because we were, we were learning, but devOps is absolutely essential. If, if you're build, if your software system is being built on, you know, Fred's machine or Anna's laptop under her desk, then that's probably not a very good software development process. And yes, one should be absolutely doing as much investment in devOps as they can. But just remember that when you name it devOps, what you're really talking about is the kind of the, the engineering science of delivering software, the way you should have always been delivering it before. It's just fun to say devOps. Michaela: [00:35:09] Yeah. Yeah, I totally agree. I mean, I worked on a tour of the software engineering team and one of the things that we did was exactly that we were concerned with the build with the testing well, with the continuous integration after after software. And I think it's a very critical part of your software development life cycle. So I think. I want to thank you for being on my show. Thank you. Did I could pick your brain for so many different topics and was a really pressured talking to you and thank you very much. Scott: [00:35:42] Absolutely. It was my pleasure and I hope that we get lots of great guests and that you do hundreds and hundreds of shows and we get to hear your voice more. Yeah, that would be great. Michaela: [00:35:51] Thank you so much. Have a good day. Bye bye Scott. I hope you enjoyed another episode of Software Engineering Unlocked podcast. Don't forget to subscribe. And I talked to you again. Bye.