From art school to Microsoft Research

About Michaela Greiler
Dr. Michaela Greiler makes code reviews a team's superpower through her code review workshops. She has worked with teams from Microsoft, National Instruments, Metro Systems, Flutter, Wix and many more.

Read the whole episode "From art school to Microsoft Research" (Transcript)

[Improve this transcript on Github.]

Michaela:

(intro music)

[00:00:00] Hello and welcome to this Software Engineering Unlocked podcast! I'm your host, Dr. McKayla, and today is a special episode. Yeah! The software engineering unlocked podcast turned one. And to celebrate the one year anniversary - and can you imagine it's already one year? - I thought I will tell you a little bit about myself.

[00:00:26] I will very inline with the theme of the show. I will tell you a little bit how I came into tech, a little bit (about) my experiences with different companies, and also I will tell you about my favorite topic: code review. So yeah, let's see how that goes.

[00:00:42] I'm a little bit nervous because it's the first "not-interview-style" podcast? So it means that I don't have another person interviewing me and asking me questions, so it will be all me talking and I hope that this goes well. (laugh)I don't know. So yeah, about me. Well, where should I start? Maybe really from the beginning - like I do with my guests. So how did I actually come into Tech. You know, that's quite a strange story because I went to a high school that was all about art. And, well, it's way back then - computer were already a thing - I'm not that old, but at my school, we didn't have laptops in our class. We didn't write on Word, for example, or some word processor or something.

[00:01:31] We wrote, really, still with pencil on paper. And especially when I graduated at the time we were already advanced. So in other school, people were already using computers and programs to type, and our school was an art school, and so we were not very progressed. Our teachers also thought, you know, "It's not a good thing", you know, "Writers write on paper", so even though when I graduated, I was still writing most of my stuff, really with pen and paper. And I had little to no exposure to computers.

[00:02:09] We had a computer at home, but because it's- it was something expensive? And it was something, you know, that...also my parents were maybe a little bit afraid of? We were not allowed to just go and play with the computer or try things out. So I really have to say my exposure to computers were really - was really, really limited. Yeah. Never ever would I have thought in this year that I will study computer science. But in the last year before graduating and before starting university, I actually attended a few lectures at the university and I attended lectures in different areas.

[00:02:46] So I was in one lecture about psychology. I was in a lecture about physics and I was in the lecture about algorithms. And somehow I was really hooked. I never- I actually thought I will study math. This is what I thought that I will go on. But then when, when I was in this lecture and this professor talked about distributed systems and threading problems, and he also were talking about cash machines. And so I really could see the application of what very much looked like math to me and logic. But I could see really the impact that it has on the real world. And so I think I was hooked! So I got a first book about it, and during the summer break, before starting university, I read this book, it was about really fundamentals.

[00:03:36] What is an algorithm? and What is computer science? Still, I didn't touch any computers. (laugh) Right? It was really theoretical knowledge about, you know, what computer science is all about. And I was really, really fascinated. I thought, "this is what I want to do". And so when I made the decision and I said, "I'm going to apply", my parents were not thrilled. They were like, "this is not for girls, and this is not for you and you're coming from an art background", which was very true, right? I was mainly painting pictures. laugh I drew, I had paintings and things like that, architecture, but I was always good at math. And I decided even though they weren't happy and actually even said they're not going to really support me doing that. I went ahead, and then enrolled.

[00:04:29] And the enrollment was actually online and I miserably failed to be honest. Yeah, I really failed to create an account. You know this was the current state that I was in, right? So I got a little bit worried about, um, if I'm not even able to enroll, because I had so little exposure to computers, and internet, and things like that. We didn't have internet at home. How I'm gonna deal with that? But yeah, there was an I.T. department, so they helped me actually enroll when I told them that I- they- I need some assistance with that and that I actually want to study computer science. They were also not super thrilled and I laughed a little bit about me, but I managed to get the thing done with a little bit of help. And then it was... It was really intense. I would say the first year, especially the first half year, it was really intense. Most of my classmates, my colleagues at university had a lot of knowledge already became, um, most of them actually came from high schools that had like, focus on computers. They even knew how to program. And for me, everything was new and I didn't have really a computer and I didn't have so much money, so I bought really a crappy computer and it wasn't good enough for- for example, the Java compilers rarely ran. So if I wanted to combine my 'Hello World', the first program that I wrote, it took several minutes - like 15 minutes can you can imagine?

[00:06:00] So. I knew I had to do something else, so I tried to collect a little bit more money and make more money. I worked on the side. And so within the first two, three months I was able to buy a better computer. It wasn't the best computer but it was really nice. A nice laptop that got the job done. Let's put it that way. And also I have to say that in my computer science education, especially at the beginning, we did again, a lot of things on paper. I mean we wrote Java programs on paper. Not always do you really needed a computer and you were doing it at home, right? Well then transferring what you learned in class to the computer. But yeah, so this is how I got started. I did a primer in programming that really helped a lot. It was very, very intense, but I studied a lot. This is purely...reality is that I really studied a lot and I really, you know, deep dived into that. I found it really also very, very fascinating. So it wasn't, it wasn't hard for me. And by the end of the first year, I was one of the best in class. And this was very encouraging as well. So I didn't start really well. But yeah, based on learning a lot and really having an open mind and being so curious, I was able to level up. So while this was really how I started, maybe I rambled a little bit too long, but hopefully you found it interesting. And well, Then back then, actually, when I did my bachelor, there were no bachelor and masters in Austria. I did my university in Austria, but this was one five year program. And so in the middle of when I started, they actually changed the thing to master and bachelor. But because I already took master classes in my bachelor's, I then actually, pursued the whole thing and did a bachelor and the master. And the master I did partly in London,

[00:08:00] in the Westminster University, and this was really one of my best times. It was the first time that I went away from home. And somehow I got a little bit hooked. I really loved being away and learning about new cultures. Having a complete different perspective on life through those travels through those months abroad. And so when I finished my masters, I knew that I'm not going to stay. I started actually as a lecturer in university and I teach the system security and complexity theory in algorithms. So something like that, Introduction to Algorithms. But I knew that I wanted something else, so I looked around and I found a PhD program and I applied! And that was actually in the Netherlands. And I also have to say that when I graduated, this was 2008, it was a recession. So it wasn't the best job market. And maybe I don't know if I would have done a PhD, if there would be a better job market. I wanted to go into- what I always wanted to do is industrial research, right? So I wanted to be in industry and do the research side. But that point I think it was just not possible. There was no money and especially companies didn't hire a lot of people into research, which somehow is not the most necessary thing. I think that if times are, you know, difficult, a lot of resources go away fom research. Anyway, so I went actually to the Netherlands and I did my PhD program there. I was mainly looking at how people understand software systems. So, software comprehension - can we build models around large software systems so that it's easier to really know what's happening here. To get an overview and I was also diving into testing. So especially test systems. When we are testing something, how do we know, how do we know what we should test?

[00:10:00] Which integrations, for example, should we be testing. And experimenting with things that help people really to understand their test suites. But in that aspect of that, I got more and more into qualitative studies. So what I really enjoyed was doing this quantitative thing. So like you're looking at data, you're analyzing software repositories data that you're getting from what the engineers produce, right? So you're looking at commits. You're looking at the source code. You're looking at maybe interactions that engineers are having, right? But this in a very quantitative way. So you're doing a lot of data mining there and maybe have some algorithms around to extract interesting patterns. But then compliment that with qualitative research. So instead of saying, well we extracted the git history and then we saw, and we have some way to detect, let's say some smells - anti-patterns in the software. And then we look over time, you know, did they increase or decrease? And we correlate that, for example, with different aspects of the software system. Like how much ownership does a person have. I did things like that, right? And you can do that just with code. You can do that just with the artifacts that are there. But this is very, very limited. The things that you're seeing have to reflect on that and really ask the people behind. So I got more and more hooked into combining quantitative work with qualitative work, which means that you're observing people that you are talking to engineers. That you are doing some surveys, for example, Survey Research. And I really found it extremely powerful if you have both worlds together. So this was mainly what I did at my PhD. I'm looking for example, how are people testing blogging software

[00:12:00] right? Plug-in systems. I worked a lot with the Eclipse community and based on that, I still had this dream of becoming a researcher in industry. Somehow at the conference, I came in contact with people from Microsoft Research and I always admired them. This was definitely where I wanted to be. This is, yeah, this was my dream. And yeah. Luckily I got the opportunity to do an interview. They liked my work and they invited me and thought it's very similar to what they want to do. And yeah! I had a full blown interview. It was probably my most advanced interview that I ever had. First it was like, I had to- Well first there were like this discussions during the conferences right? Then I had a screening interview where we just talk about what I like and you know...just get to meet each other. And then I had like at home assignment, like homework, more or less. I think it was some kind of calculator that I had to program and then send them over. They looked at the code then based on that they would schedule the next interview. So then I had an interview with two people via phone or video conference. This was really, really stressful because on that day, my internet connection was so poor and I could barely hear what they were talking. I was in student housing so the walls are really thin. So if other people talked in my flat, right? It was super loud and they were talking and they were, they were not- I mean they knew that I am going to have an interview but they were not paying any attention - probably forgot. And then their internet connection was so bad.

[00:14:00] And I barely heard what people were saying, and I was too afraid to say, "It's not working" right? Or "Can we reschedule". I dared to ask probably to repeat a couple of things, but even that, I mean if you ask seven times or "Could you please repeat" or "I couldn't hear you". It gets really bad, right? So I actually thought I blew the interview. I was very sad on that day and it took quite a while for them to get back to me - to tell me, you know, if I pass or if I didn't pass. But you know, when they did, they came back and said, yeah the interview went well. Then they said, "You should come for an onsite interview". And at that time, I was living in the Netherlands. So this meant that I had to fly to Seattle. I was super, super excited. Yeah. I was super excited. I think within two weeks, they flew me over. Before that, I really practiced some algorithms and everything again - just to refresh my mind. I'm also a person that's very nervous during interviews. Sometimes I'm a little bit better because of that. Sometimes I'm worse because of that, because of my anxiety a little bit. But yeah, so they flew me over. It was a very interesting experience to be in Seattle. I've never been there before. Then I had a whole day of interviews. It started - I can't completely recall - but I think around nine and it went on until really late in the evening. The only thing that I knew is that that's a good sign. So what I heard about interviews is the longer you last the better. So if, let's say, you have two interviews and they stop after that - that's not a good sign. I don't know. Maybe if you're having a lot of interviews, that's also not a good sign. I don't know. But what I can say is that I actually performed very well during these interviews,

[00:16:00] from my perspective. It was a very, very classical interview. Like white boarding exercises, or traversing trees, doing some design work, as well as some architectural work. I was also talking about my research - it was probably the easiest and most fun part of the whole interview. One thing that I didn't like was that the interview - I mean people were going with lunch with me but it's still an interview, right? It was still somehow an interview. This was really uncomfortable for me. I would rather have my break by myself, like recharging a little bit because I was with, you know, people that I don't know the whole day. So even after, or during lunch and I'm chewing, you know, my sandwich (laughs) I still have to talk. This was probably the part that I didn't enjoy so much. But I know that it was - it was a nice and kind intention, right? That I don't have to go by myself or having lunch. But also discussion was about work so I would still say this was an interview during lunch. It was stressful. Just put it that way. Anyway, in general, it was a very positive interview experience. I had worse interview experiences. I didn't feel judged. I didn't feel like people have an immediate bias when they see me, because sometimes in previous interviews I had that. They were saying- I was interviewing for software engineer and he was saying "Oh, you're here for the PM position?" I'm like, "No, I'm here for the software engineering position." "Oh. So...but I think you want to do the PM- Product Manager position." "No, no. I want to be a software engineer here" and things like that, right? Or one company I was, again, interviewing to be a software engineer. They always try to put me into the tester area, which is fine if you want to be a tester, but I didn't.

[00:18:00] So I expected something like this to happen, but no, it was really...I felt like they take this interview also very serious. They didn't, you know, I didn't have to earn kind of level of trust. But there was some kind of trust, like you passsed already things and we know your credentials, and so now we just make sure that you really can do what we want you to do. Something like that, right? So it was very challenging, but I didn't feel like there was a negative bias against me. Well, I'm rambling. I don't know. Is that going well? (laughs) Is this first episode me telling you things are going well. I don't know. Anyway, so this is how I started actually then at Microsoft. They didn't tell me immediately, I think? I actually can't completely recall, but I knew that because I - it was not only the head of this department but also the head of the division that interviewed me on that day. I heard that if he wants to interview you then more or less, you know, you passsed if he's happy. So I was very confident then actually I really got an offer into, I got sort of my dream job that I'd dreamt of for many years. And it was like this, it was really like this. So I first moved to England. I joined Microsoft Research in the UK and then a little bit later, I joined actually Microsoft Corporation in Seattle -
in Redmond. And I was part of a really amazing team. At that point it was called Tools for Software Engineers. Now it's called One ES. And they were looking at improving, you know, the software engineering practices of the 40,000 engineers that there are at Microsoft. And so, I mean, this was the best. You have all, you have this responsibility to really make an impact, but also you

[00:20:00] have like all these data available. So we were building a platform to extract engineering data, and yeah! I was really happy at that point. It was very overwhelming at the beginning to learn everything and to know how engineers at Microsoft tick and you know- you have a lot of divisions, so culturally engineering teams are also very different at Microsoft. It's not like one thing. So I had to learn a lot and also get used to, you know, the new country, the new continent even right? To get settled. And so it was really, really beautiful and I really enjoyed it, but life didn't really, you know, from a professional perspective things went really, really well. I also enjoyed Seattle. I really loved the West coast, but from a personal side, things didn't go so well. My husband didn't get a visa. So we had to stay separated. He was actually living in - at the beginning - in Europe. That was really hard. Then he moved to Vancouver and so he was working for a software company there. We traveled back and forth. It was four hours? If everything goes smooth. We did it for quite some time, but at one point, you know, after several years, I was - well we missed our time together. And so, even though I love this job, I took a really big risk and I said "I have to move. I have to move to a place where my husband can also work and where we can stay together". Luckily my team was actually agreeing that I could work remote. So this is how I actually started working remote. I have to say I'm a big remote fan. It was really cool to work remote. And it was really also fitting to my personality probably, right? So I'm very organized and I can motivate myself very well. So yeah! I

[00:22:00] actually moved back to Europe with my husband and we moved in together, which was beautiful. I was very, very grateful that I could continue with my team and with my job. To be fair, Europe and America - it's quite different, right? From a time perspective. Because my team wasn't remote first- was not even remote, right? It was a little bit challenging to work. I mainly worked their hours, right. So I came in very late. And I tried- but I have a lot of over lave(??) with their working hours with the Seattle Pacific time zone. That's not the easiest if you are in central European time zone but without family it was definitely manageable. But at one point, I wanted to have more flexibility also regarding my family life because I actually became a mother in this time. Actually, when Max was really little, it was still very cool because I could take care of him during the day and then work in the night but it was very, very exhausting. I actually knew that something has to change. So slowly, I transitioned to my own business, to start my own business, to start my own thing. I knew that I wanted to do something very similar working with teams, helping them improve their software engineering practices. It took me a little bit to figure out how I could actually bring this idea. This desire to live, right? How can I leverage all the things that I did? The knowledge that I gained theoretically and practically working with engineering teams. How can I do that in an very independent way? So this was something that was front of my mind for a couple of months until a year almost. I slowly transitioned and started to work with customers- with companies outside of Microsoft. The good thing is if you're working in Europe, in

[00:24:00] Germany, it's okay if you have like- I think it's called 'moonlighting' in English. So you can do that. If you're transparent about it and you're telling your manager, then you can do something outside of your regular work hours. This is what I actually started. Especially when I was on parental leave, there was more time to actually do something like that and transition away. So yeah! This is actually how I started my training business. So I- training and consulting business in the code review space. Yeah, so I'm giving workshops, I'm working with teams and to help them be productive, very efficient and effective with code reviews. And this is exactly, you know, it's playing so much to my strengths and to the vision that I had that I want to do - continue working with engineering teams, right? But now it's not one company. It's really all over the world and it's not like a large corporation. But I'm working- I work with different other large corporations, but I also work with really small companies or with smaller companies. Actually with companies of all sizes. So for my curiosity of how things work, it's very beneficial. And maybe- yeah, well, I haven't talked with you about so much is 'why code reviews', right? (laughs) I actually probably am not going to talk about a lot about code reviews in this episode. Time flies. I talked a lot about my journey. I will do say in another episode. Anyway, why code reviews? Well, at Microsoft, we were looking at software engineering practices. We were not only looking at code reviews, but also code reviews- We were looking at how people are testing their system, how they are building and we were also owning the code review tool - the internal code review tool, Code Flow. We were also looking at how our engineers actually doing code review. Is that beneficial for them? Right? So what we saw is that teams were spending a lot of time on code reviews. We were spending over six hours and this was back then. Now

[00:26:00] they are even spending more, right? But even back then, they were spending over six hours doing code review. So obviously we wanted to know, is that beneficial for them? And so we were working with different teams and we could see that some teams are, you know, using code reviews better than others. So we wanted to distill best practices that we can then help other teams to adopt. Yeah, I've found this so fascinating when I was working at Microsoft because it's really a socio-technical, practice, right? So there's a lot of social skills that people have to bring to the table, but there's also a lot of technical skills that makeup the good code reviewer. Then there is also this process perspective, like, as a team, how are you actually doing code reviews? And there's so many unknowns, right? A lot of people thinking about the testing strategy. A lot of people, engineers, are thinking about, you know, 'how do you write code?' They're doing a lot of trainings in that area, but code reviews, I think, is something that has picked up a lot of steam. A lot of companies adopted that practice, but there isn't a lot of great information out there. There isn't a lot of training out there that teaches people how to actually do code reviews effectively. And there are things that you should know! So this is where I saw actually a little bit, like a "hole" in the market. A space that I could fill in that I had a lot of knowledge. I had a lot of passion also for this topic. And so this is actually how I came about during my code reviews workshops and writing my code reviews book that, you know, I'm writing right now. What's on my bucket list as well: I want to also develop a tool in that space. I hope that end of this year, beginning of next year, I will really start with that idea, and bring that to life, and experiment with that. So, this brings me to the end of this episode. Let me know if you enjoyed it. Next episode, if it's just me talking again, will not be about my journey.

[00:28:00] I thought maybe, you know, well, code reviews could be one thing like I'm telling you my perspective on how you can do code reviews more effectively. You can also talk about testing, for example, or other engineering topics. So everything that actually interests me a lot, and I have a lot of passion for, and that I hope will bring you also some joy and some interesting perspectives. So, have a good day! And talk to you in two weeks. Bye bye!

I hope you enjoyed another episode of the Software Engineering Unlocked podcast. Don't forget to subscribe! And I talk to you again in two weeks. Bye!