{"id":588766,"date":"2019-05-22T07:59:29","date_gmt":"2019-05-22T14:59:29","guid":{"rendered":"https:\/\/www.microsoft.com\/en-us\/research\/?p=588766"},"modified":"2020-04-23T14:48:57","modified_gmt":"2020-04-23T21:48:57","slug":"the-productive-software-engineer-with-dr-tom-zimmermann","status":"publish","type":"post","link":"https:\/\/www.microsoft.com\/en-us\/research\/podcast\/the-productive-software-engineer-with-dr-tom-zimmermann\/","title":{"rendered":"The productive software engineer with Dr. Tom Zimmermann"},"content":{"rendered":"
<\/a><\/p>\n If you\u2019re in software development, Dr. Tom Zimmermann<\/a>, a senior researcher at Microsoft Research in Redmond, wants you to be more productive, and he\u2019s here to help. How, you might ask? Well, while productivity can be hard to measure, his research in the Empirical Software Engineering group<\/a> is attempting to do just that by using insights from actual data, rather than just gut feelings, to improve the software development process.<\/p>\n On today\u2019s podcast, Dr. Zimmermann talks about why we need to rethink productivity in software engineering, explains why work environments matter, tells us how AI and machine learning are impacting traditional software workflows, and reveals the difference between a typical day and a good day in the life of a software developer, and what it would take to make a good day typical!<\/p>\n Tom Zimmermann: If you think of a typical software engineer at Microsoft, they spend about half of a day on development related activities, and the other half of the day is spent on other activities like coordinating with other people in meetings, sending emails\u2026 So, there\u2019s actually not that much time that they can spend on writing code, and the time they spend writing code, on a good day, it\u2019s actually only 96 minutes, and on a bad day it\u2019s, on average, 66 minutes. And half an hour writing code actually can make the difference between a bad and a good workday.<\/p>\n Host: You\u2019re listening to the Microsoft Research Podcast, a show that brings you closer to the cutting-edge of technology research and the scientists behind it. I\u2019m your host, Gretchen Huizinga.<\/strong><\/p>\n Host: If you\u2019re in software development, Dr. Tom Zimmermann, a senior researcher at Microsoft Research in Redmond, wants you to be more productive, and he\u2019s here to help. How, you might ask? Well, while productivity can be hard to measure, his research in the Empirical Software Engineering group is attempting to do just that by using insights from actual data, rather than just gut feelings, to improve the software development process.<\/strong><\/p>\n On today\u2019s podcast, Dr. Zimmermann talks about why we need to rethink productivity in software engineering, explains why work environments matter, tells us how AI and machine learning are impacting traditional software workflows, and reveals the difference between a typical day and a good day in the life of a software developer, and what it would take to make a good day typical! That and much more on this episode of the Microsoft Research Podcast.<\/p>\n Host: Tom Zimmermann, welcome to the podcast!<\/strong><\/p>\n Tom Zimmermann: Thank you.<\/p>\n Host: You have a cool nickname. Tom-Z. Kind of like A-Rod or J-Lo, but for research. Why do people call you that?<\/strong><\/p>\n Tom Zimmermann: So, it goes back to when I started at Microsoft. So, my manager was Tom Ball and so because my short name is also Tom, so basically, we are two Toms, and we had to find ways to distinguish between us.<\/p>\n Host: Well, you\u2019re a senior researcher at Microsoft Research in Redmond, working under the umbrella of Programming Languages and Software Engineering<\/a>. In broad strokes, what does a typical day look like for Tom-Z? I\u2019ll ask you about a good day later, but what\u2019s a typical day? What gets you up in the morning?<\/strong><\/p>\n Tom Zimmermann: So, basically, the work I do, it\u2019s analyzing any type of data which is related to software. And so what gets me up in the morning is to basically learn new things about software development because there is so many things we don\u2019t know or we don\u2019t have any data about, so really what my job is about is to basically look at such data and create interesting insights that we can use to improve software development at Microsoft.<\/p>\n Host: So, drill in there a little bit. Where do you gather this data and what does it look like?<\/strong><\/p>\n Tom Zimmermann: So, some of the data I collect by myself. So, like, a lot of the work I do is interviews and surveys with software developers. We also look a lot at existing software repositories. So, what happens during software development is there\u2019s a lot of data that\u2019s being collected. So, it\u2019s data about changes, about bugs that people face, about test executions and also like telemetry about how the software is being used in the field.<\/p>\n Host: Right.<\/strong><\/p>\n Tom Zimmermann: And so that was my part of my work is look at this data and do some analysis. And it can be many different things. So sometimes it\u2019s empirical studies to find out what makes software engineers productive. Sometimes it\u2019s building recommendation systems. So, one of my earliest projects was to build a recommendation system based on past changes to recommend like, people who change this file should also change this other file. It\u2019s mostly internal, so a lot of the data we analyze is internal Microsoft data.<\/p>\n Host: So, it sounds like you got to be sort of cross-pollinating with developers and engineers in Microsoft proper.<\/strong><\/p>\n Tom Zimmermann: Mm-hmm.<\/p>\n Host: And you\u2019re here in Microsoft Research\u2026<\/strong><\/p>\n Tom Zimmermann: Mm-hmm.<\/p>\n Host: \u2026working with them. How does that work?<\/strong><\/p>\n Tom Zimmermann: So, we meet with them, we just send emails or schedule meetings with developers and talk to them. And, in fact, actually that\u2019s like one big piece of the work I do is really figuring out what challenges people face.<\/p>\n Host: Yeah.<\/strong><\/p>\n Tom Zimmermann: And the best way to find out these challenges is by talking to people, and then, after talking to people, it\u2019s basically, can we use additional data to basically find support for the observations we\u2019ve made.<\/p>\n Host: Well, let\u2019s start the podcast kind of generally and set the stage for some of the other things we\u2019ll be covering by talking a bit about ICSE, or the International Conference on Software Engineering<\/a>. Since it\u2019s happening in Montreal about the same time this podcast drops, I\u2019d love for you to tell us what this conference is about and why it\u2019s important for people in your field.<\/strong><\/p>\n Tom Zimmermann: Yeah, so ICSE is the largest software engineering conference. So, everyone who is passionate about improving software development goes to ICSE and finds out what everyone else is working on. So, you will find like a lot of professors who are doing research on software engineering. You will find a lot of people from industry who want to find out what the latest research is about and how it can help them in what challenges they face right now.<\/p>\n Host: Right.<\/strong><\/p>\n Tom Zimmermann: You will find a lot of students who basically want to start their careers, so it\u2019s really good for recruiting, and in fact a lot of the interns I had over the past few years, I found that ICSE.<\/p>\n Host: Well you are a part of a group called ESE, or Empirical Software Engineering. Tell us why this group exists and what you hope to achieve through it.<\/strong><\/p>\n Tom Zimmermann: So, one of the reasons this group exists is because there\u2019s still a lot of decisions being made just based on gut feeling. So like statistics that 40% of management decisions, people just make based on what they think is right, but they don\u2019t use any data to inform the decisions. Or what you often also hear is that people get to see some data, but when the data doesn\u2019t match the gut feeling, they question the data until they either invalidate the data or the finding, or the finding matches what they were expecting. So that\u2019s really what ESE wants to change. So, what we want to have is that people have a more data-driven culture when making decisions because there\u2019s so much data available about software development.<\/p>\n Host: Yeah.<\/strong><\/p>\n Tom Zimmermann: By doing some analysis on top of this data, we can learn things about software engineering and that can help people to make better decisions. We can also build tools to make people more productive. And so that\u2019s like another mission of the ESE group.<\/p>\n Host: Yeah, and we\u2019re going to get way into productivity\u2026<\/strong><\/p>\n Tom Zimmermann: Yes!<\/p>\n Host: \u2026shortly. Give me an example of a decision that somebody would make on a gut feeling that could have disastrous consequences or maybe it would work out just fine, but you don\u2019t know, right?<\/strong><\/p>\n Tom Zimmermann: Yeah, so like one very simple example is like trust management structures. Like how you compose your teams. Who is put in a management role and who is assigned which manager? That can have like big implications on the productivity and satisfaction of software engineers.<\/p>\n Host: So, that\u2019s some of the questions that you\u2019re asking in ESE?<\/strong><\/p>\n Tom Zimmermann: That\u2019s some of the questions we ask. So, one of my colleagues, Nachi Nagappan<\/a>, so he actually did one study where he looked into how the organizational hierarchy affects software quality. And so, he actually found that like a misalignment in the organization hierarchy, that\u2019s one of the biggest predictors of bugs in software.<\/p>\n Host: Wow.<\/strong><\/p>\n Tom Zimmermann: And so another study we did in this space was, one of my colleagues, Chris Bird<\/a>, he was looking into what makes effective software engineering managers, because software engineering management has so much impact on the software we build, so it\u2019s really important for us to understand what are the characteristics of effective management techniques.<\/p>\n Host: You know, we\u2019re going to talk about the management impact on productivity of workers. It sounds like that\u2019s just not a software engineering workplace question but could have broad implications.<\/strong><\/p>\n Tom Zimmermann: Absolutely, yeah. And I think that\u2019s what\u2019s unique about empirical software engineering is that it\u2019s just not software engineering, it\u2019s not just programming languages, it covers much more than just these two disciplines. Like, a lot of the work we do, it\u2019s very related to human computer interaction<\/a> and CSEW style of work. We do a lot of AI in our research as well because we often build like tools which learn from past data to support decision-making.<\/p>\n (music plays)<\/p>\n Host: In a recent paper entitled Today Was a Good Day: the Daily Life of Software Developers<\/a> \u2013 I can\u2019t wait until that movie comes out! \u2013 um, you asked thousands of professional developers what constitutes a typical day at work and what constitutes a good day, in hopes that the answers would help you understand how to make a good day a typical day.<\/strong><\/p>\n Tom Zimmermann: Yeah.<\/p>\n Host: Yeah. So, what did you learn from the research behind this paper?<\/strong><\/p>\n Tom Zimmermann: Yeah, so, we\u2019ve learned actually quite a few things. So, some of the findings confirmed what we already knew, which is also important in empirical research because often you think you know something but you don\u2019t have any evidence and that\u2019s why you do empirical studies to support what your assumptions are. So, one of the findings we had was \u2013 and that\u2019s probably not surprising to many people \u2013 but software development involves many other activities than just writing code. So, actually, if you think of a typical software engineer at Microsoft, they spend about half of a day on development related activities. And the other half of the day is spent on other activities like coordinating with other people in meetings, sending emails\u2026 So, there\u2019s actually not that much time that they can spend on writing code, and the time they spend writing code, on a good day, it\u2019s actually only 96 minutes, and on a bad day it\u2019s, on average, 66 minutes. And half an hour writing code actually can make the difference between a bad and a good workday.<\/p>\n Host: Huh. So, everything you\u2019re saying has broader contextual application, as far as I\u2019m concerned. I mean, I think the average worker in any occupation has to do email, has to do meetings, has to do, you know, all the mundane things\u2026<\/strong><\/p>\n Tom Zimmermann: Yeah.<\/p>\n Host: \u2026and then, you know, if they\u2019re a writer or if they\u2019re, you know, an artist or whatever, it\u2019s how can I get to my work?<\/strong><\/p>\n Tom Zimmermann: Yeah.<\/p>\n Host: So, the next question is then, with what you found, that did confirm what you think, how do you get back those hours, or those minutes, that time?<\/strong><\/p>\n Tom Zimmermann: Basically, the way we approached this, in this particular paper, is we wanted to understand what makes good workdays and what makes typical workdays. And so, we built different conceptual models. So, the way we approach is we had this big survey with close to 5,000 responses\u2026<\/p>\n Host: Yeah.<\/strong><\/p>\n Tom Zimmermann: \u2026and in each of the responses, people could say why the day was good and why the day was typical. And so, we analyzed all of these 5,000 responses and came up with frameworks, and one of the frameworks was basically, for a good workday, things that matter is that people see that they created some value. So, at the end of the day, we want to go home and say hey, I spent a certain amount of time coding, I spent some time helping others to do their work or I spent some time finding a bug. So, they want to be able to say that they accomplished something.<\/p>\n Host: So, I noticed how you are framing this is a \u201ctypical\u201d day and a \u201cgood\u201d day. You are not calling a typical day a bad day. Is there something below a typical\u2026 I mean, there\u2019s days that could be really bad, right?<\/strong><\/p>\n Tom Zimmermann: Uh, yeah absolutely! And I mean an untypical workday doesn\u2019t have to be bad.<\/p>\n Host: Right.<\/strong><\/p>\n Tom Zimmermann: Because it can be untypical because you just had like ten hours coding time.<\/p>\n Host: Sure.<\/strong><\/p>\n Tom Zimmermann: And that it comes down to like looking into productivity, it\u2019s actually a very complicated construct. Like there are many factors which\u2026<\/p>\n Host: Yeah.<\/strong><\/p>\n Tom Zimmermann: \u2026 come into play that can change if you\u2019re productive, if you have a good workday, if you feel happy about what you accomplished.<\/p>\n Host: Well let\u2019s dig on this idea of productivity, especially as it pertains to programmers and developers, because that\u2019s what matters here. One of your papers \u2013 you have so many cool papers, Tom, it\u2019s really impressive\u2026<\/strong><\/p>\n Tom Zimmermann: Thank you.<\/p>\n Host: \u2026one of your papers is titled, The Effect of Work Environments on Productivity and Satisfaction of Software Engineers<\/a>. So, tell us about this research and the paper that came from it and what were the big takeaways on the study of work environments in relation to work productivity?<\/strong><\/p>\n Tom Zimmermann: Yeah, so it comes down to, again, many factors can influence productivity. We briefly talked about management and, just like management, work environment is like another factor which can influence how productive software engineers feel. So, the goal of this project was to understand what software engineers expect from the work environment. So, what are things that they consider to be important about the work environment and how can they help us understand productivity and satisfaction? So, what we did is, we started off with interviews, like as we do many\u2026 typically in our studies, and we did some analysis of the interviews and we followed up with a survey among software engineers at Microsoft. And so what we found was basically, that it was like a set of different themes which are really important for software engineers \u2013 and probably for everyone else working in an office environment \u2013 so, it\u2019s not necessarily saying software engineering is so much different, but it\u2019s confirming also what other people found about what makes good work environments. So, we found that personalization is very important for people. We also found that social norms and signals are important in work environments. Like when you are working in an open office, certain signals people use to, say, hey, don\u2019t disturb me, I have to focus now. For example, wearing headphones\u2026<\/p>\n Host: Okay.<\/strong><\/p>\n Tom Zimmermann: \u2026is one of the signals people often do. Then also like how the room composition looks like so, who\u2019s in the room sitting with you?<\/p>\n Host: Sure.<\/strong><\/p>\n Tom Zimmermann: Are you in the same room as your team members or you are in a separate room? If you can work without interruptions and can focus on the work, that\u2019s also very important. And so, what we did is, we collected these different aspects and when we did the survey, and this helped us to basically prioritize which are the most important factors when it comes to productivity.<\/p>\n Host: And then you present these findings to people who are in charge of\u2026<\/strong><\/p>\n Tom Zimmermann: Yeah.<\/p>\n Host: \u2026making the environments one way or the other.<\/strong><\/p>\n Tom Zimmermann: Yeah.<\/p>\n Host: I would imagine there\u2019s a spread there because there\u2019re some people who can work in completely noisy environments no problem, and other people who say, just get out of my face.<\/strong><\/p>\n Tom Zimmermann: Yeah, so absolutely. Like people have very different opinions or feelings.<\/p>\n Host: Yeah.<\/strong><\/p>\n Tom Zimmermann: And work differently in different environments.<\/p>\n Host: So, then is one of the takeaways to say, make space for these different kinds of work preferences?<\/strong><\/p>\n Tom Zimmermann: Yeah. So, that\u2019s one of the takeaways. And I would even say it\u2019s a takeaway of the entire productivity research we\u2019ve done is, that there\u2019s not a single way to make everyone more productive.<\/p>\n Host: Right.<\/strong><\/p>\n Tom Zimmermann: Right? With so many personal differences, you really need to understand how everything plays together and then you can make recommendations\u2026<\/p>\n Host: Make good decisions.<\/strong><\/p>\n Tom Zimmermann: …for individual people. Right? It\u2019s very similar to like going on a diet or, when you go to the gym, like your exercise routine. Everyone has their own techniques which work best for them.<\/p>\n Host: Right.<\/strong><\/p>\n Tom Zimmermann: So, it\u2019s not a single one-size-fits all.<\/p>\n Host: All right. Well, we talked a bit about the movement toward incorporating data science to help programmers achieve more, and you have a seriously delightful presentation called Software Productivity Decoded. I wish our listeners could see it, especially the part about Alice in Dataland\u2026 They\u2019ll have to come to one of your talks, I guess. Anyway\u2026 This is important and speaks to your unique approach to software engineering research. So, how does data science impact productivity and help software engineers achieve more?<\/strong><\/p>\n Tom Zimmermann: So, I think first, it helps us to really understand, more effectively, how software developers work. So, you can think of applying data science work to software engineering.<\/p>\n Host: Hmm.<\/strong><\/p>\n Tom Zimmermann: And so, I\u2019ve mentioned all these different data sources that we can leverage, and we also talked about ICSE\u2026 there\u2019s actually a conference just dedicated to the analysis of software data at ICSE. We talked about acronyms \u2013 it\u2019s actually called the MSR Conference, but it\u2019s not for Microsoft Research, it\u2019s for Mining Software Repositories.<\/p>\n Host: Oh, that\u2019s funny.<\/strong><\/p>\n Tom Zimmermann: And so, what this conference does is basically, people look at all of the data that is available for software and software development, and they try to do cool things with it. So, I will come up with interesting findings that help us understand software engineering more or I\u2019ll come up with tools that allow people to be more productive.<\/p>\n Host: Right.<\/strong><\/p>\n Tom Zimmermann: So, some people use data science techniques to improve code review processes. For example, you can assign code reviewers to your changes and then your change hopefully gets reviewed faster. So that\u2019s one area where data science can help us to discover more about software engineering. It can also help software engineers to understand more about how they work themselves. It\u2019s sort of like Fitbit or Apple Watch, right, which keeps track of your steps, your heart rate and at the end of the day you can look at it and reflect on how active you were. You can do similar things with data science. So you can build tools which allow developers to look at the end of a day to see how much time they spent on coding, how much time they spent on emails, on meetings, and then they can use this to become more productive and also to understand how their own productivity relates to the team productivity. Because you always have this tension between your personal productivity but also productivity as a team.<\/p>\n Host: Yeah.<\/strong><\/p>\n Tom Zimmermann: So sometimes what\u2019s best for your own personal productivity is maybe not best for your team, right? So, one thing we find is that people don\u2019t want to be interrupted. So, we can increase focused time that helps people to become more productive, but it can also block someone who really needs your help right now. If they cannot interrupt you, they might be stuck and not\u2026<\/p>\n Host: Right.<\/strong><\/p>\n Tom Zimmermann: \u2026make any progress.<\/p>\n Host: Right. Right.<\/strong><\/p>\n Tom Zimmermann: And so, what data science can help us do is to really understand this tension between individual productivity and team productivity and find effective ways to balance it.<\/p>\n Host: Those are fascinating questions and fascinating research. It seems there\u2019s a really beautiful mix of qualitative and quantitative\u2026<\/strong><\/p>\n Tom Zimmermann: Yep.<\/p>\n Host: \u2026in your work. And it also is, over into the HCI space, I know that there\u2019s researchers here, Dan McDuff<\/a> and Mary Czerwinski<\/a>, who are monitoring and then saying how can we improve our tools to make us understand when \u201cI\u2019m in the flow and don\u2019t get me out of the flow\u201d or when I could be interrupted\u2026<\/strong><\/p>\n Tom Zimmermann: Um-hum. Yep.<\/p>\n Host: Do you interact with them quite a bit?<\/strong><\/p>\n Tom Zimmermann: Yeah. So, we got together on some things.<\/p>\n Host: Yeah.<\/strong><\/p>\n Tom Zimmermann: And it\u2019s very related, the work we do.<\/p>\n Host: Yeah. All right. Well let\u2019s circle back to ICSE because you\u2019re presenting a really interesting paper there this year called Software Engineering for Machine Learning: A Case Study<\/a>, which I love. Tell us about this paper and the research behind it. How have you found AI \u2013 because that will be in there \u2013 to be sort of a forcing function for an evolution of workflows in the software development process?<\/strong><\/p>\n Tom Zimmermann: Yeah, so what\u2019s happening at the moment is that more and more teams are using AI in their software. And so, what we\u2019re trying to do is to basically process this whole AI workflow, how you build machine learning models. You collect some data. You change the models. You tune the models. You test the model. And we are basically trying to fit this workflow into the traditional software engineering workflow. And it is possible, but it\u2019s not a natural fit. For example, one very simple difference between traditional software development and more modern software development with AI is, in traditional software development, like software testing, it\u2019s usually fairly easy to tell if a test has failed or passed. So, there are some exceptions, but usually you know if something has worked or not, right? If you type in in Excel, like add up two numbers, you can tell if the sum is the same.<\/p>\n Host: Right.<\/strong><\/p>\n Tom Zimmermann: And if it\u2019s not, you know you found a bug. And this is a little bit harder for AI models because testing is not as straightforward because you don\u2019t know, what is a good AI model? It\u2019s sometimes hard to tell.<\/p>\n Host: Right.<\/strong><\/p>\n Tom Zimmermann: Right? Because you cannot test them online, you have to test them offline first and it also might change over time. If you use new training data, the model might look completely different.<\/p>\n Host: Right.<\/strong><\/p>\n Tom Zimmermann: So, it\u2019s really hard to tell when you\u2019re getting worse results than you did before. So, that\u2019s really one of the challenges people have to figure out and that\u2019s what we\u2019ve been looking into in this paper.<\/p>\n Host: Mm-hmm.<\/strong><\/p>\n Tom Zimmermann: So, we started off with interviews and we did surveys and collected data and did analysis of lots of open text responses.<\/p>\n Host: Well, tell us a little bit about the case study. What did you look at and how did you get your subject or your case?<\/strong><\/p>\n Tom Zimmermann: So, the case study is basically Microsoft. To find people, we used something called \u201csnowball sampling\u201d where we basically identified a few people knowledgeable in this area.<\/p>\n Host: And they recommend two friends and they recommend two friends\u2026<\/strong><\/p>\n Tom Zimmermann: They recommend friends and we kept doing this until we pretty much thought we heard everything. So, that\u2019s called saturation, when you don\u2019t get to hear anything new. And that\u2019s when we started working on a survey to really understand the landscape of AI at Microsoft. The interviews allow us to go deep.<\/p>\nEpisode 77, May 22, 2019<\/h3>\n
Related:<\/h3>\n
\n
\nTranscript<\/h3>\n