Return to Podcast Home
Microsoft Research Podcast

Episode 77, May 22, 2019

If you’re in software development, Dr. Tom Zimmermann, a senior researcher at Microsoft Research in Redmond, wants you to be more productive, and he’s 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.

On today’s 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!



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… So, there’s actually not that much time that they can spend on writing code, and the time they spend writing code, on a good day, it’s actually only 96 minutes, and on a bad day it’s, on average, 66 minutes. And half an hour writing code actually can make the difference between a bad and a good workday.

Host: You’re 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’m your host, Gretchen Huizinga.

Host: If you’re in software development, Dr. Tom Zimmermann, a senior researcher at Microsoft Research in Redmond, wants you to be more productive, and he’s 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.

On today’s 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.

Host: Tom Zimmermann, welcome to the podcast!

Tom Zimmermann: Thank you.

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?

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.

Host: Well, you’re a senior researcher at Microsoft Research in Redmond, working under the umbrella of Programming Languages and Software Engineering. In broad strokes, what does a typical day look like for Tom-Z? I’ll ask you about a good day later, but what’s a typical day? What gets you up in the morning?

Tom Zimmermann: So, basically, the work I do, it’s 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’t know or we don’t 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.

Host: So, drill in there a little bit. Where do you gather this data and what does it look like?

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’s a lot of data that’s being collected. So, it’s 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.

Host: Right.

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’s empirical studies to find out what makes software engineers productive. Sometimes it’s 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’s mostly internal, so a lot of the data we analyze is internal Microsoft data.

Host: So, it sounds like you got to be sort of cross-pollinating with developers and engineers in Microsoft proper.

Tom Zimmermann: Mm-hmm.

Host: And you’re here in Microsoft Research…

Tom Zimmermann: Mm-hmm.

Host: …working with them. How does that work?

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’s like one big piece of the work I do is really figuring out what challenges people face.

Host: Yeah.

Tom Zimmermann: And the best way to find out these challenges is by talking to people, and then, after talking to people, it’s basically, can we use additional data to basically find support for the observations we’ve made.

Host: Well, let’s start the podcast kind of generally and set the stage for some of the other things we’ll be covering by talking a bit about ICSE, or the International Conference on Software Engineering. Since it’s happening in Montreal about the same time this podcast drops, I’d love for you to tell us what this conference is about and why it’s important for people in your field.

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.

Host: Right.

Tom Zimmermann: You will find a lot of students who basically want to start their careers, so it’s really good for recruiting, and in fact a lot of the interns I had over the past few years, I found that ICSE.

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.

Tom Zimmermann: So, one of the reasons this group exists is because there’s 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’t 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’t 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’s 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’s so much data available about software development.

Host: Yeah.

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’s like another mission of the ESE group.

Host: Yeah, and we’re going to get way into productivity…

Tom Zimmermann: Yes!

Host: …shortly. 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’t know, right?

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.

Host: So, that’s some of the questions that you’re asking in ESE?

Tom Zimmermann: That’s some of the questions we ask. So, one of my colleagues, Nachi Nagappan, 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’s one of the biggest predictors of bugs in software.

Host: Wow.

Tom Zimmermann: And so another study we did in this space was, one of my colleagues, Chris Bird, 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’s really important for us to understand what are the characteristics of effective management techniques.

Host: You know, we’re going to talk about the management impact on productivity of workers. It sounds like that’s just not a software engineering workplace question but could have broad implications.

Tom Zimmermann: Absolutely, yeah. And I think that’s what’s unique about empirical software engineering is that it’s just not software engineering, it’s not just programming languages, it covers much more than just these two disciplines. Like, a lot of the work we do, it’s very related to human computer interaction 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.

(music plays)

Host: In a recent paper entitled Today Was a Good Day: the Daily Life of Software Developers – I can’t wait until that movie comes out! – 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.

Tom Zimmermann: Yeah.

Host: Yeah. So, what did you learn from the research behind this paper?

Tom Zimmermann: Yeah, so, we’ve 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’t have any evidence and that’s why you do empirical studies to support what your assumptions are. So, one of the findings we had was – and that’s probably not surprising to many people – 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… So, there’s actually not that much time that they can spend on writing code, and the time they spend writing code, on a good day, it’s actually only 96 minutes, and on a bad day it’s, on average, 66 minutes. And half an hour writing code actually can make the difference between a bad and a good workday.

Host: Huh. So, everything you’re saying has broader contextual application, as far as I’m 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…

Tom Zimmermann: Yeah.

Host: …and then, you know, if they’re a writer or if they’re, you know, an artist or whatever, it’s how can I get to my work?

Tom Zimmermann: Yeah.

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?

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…

Host: Yeah.

Tom Zimmermann: …and 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.

Host: So, I noticed how you are framing this is a “typical” day and a “good” day. You are not calling a typical day a bad day. Is there something below a typical… I mean, there’s days that could be really bad, right?

Tom Zimmermann: Uh, yeah absolutely! And I mean an untypical workday doesn’t have to be bad.

Host: Right.

Tom Zimmermann: Because it can be untypical because you just had like ten hours coding time.

Host: Sure.

Tom Zimmermann: And that it comes down to like looking into productivity, it’s actually a very complicated construct. Like there are many factors which…

Host: Yeah.

Tom Zimmermann: … come into play that can change if you’re productive, if you have a good workday, if you feel happy about what you accomplished.

Host: Well let’s dig on this idea of productivity, especially as it pertains to programmers and developers, because that’s what matters here. One of your papers – you have so many cool papers, Tom, it’s really impressive…

Tom Zimmermann: Thank you.

Host: …one of your papers is titled, The Effect of Work Environments on Productivity and Satisfaction of Software Engineers. 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?

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… 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 – and probably for everyone else working in an office environment – so, it’s not necessarily saying software engineering is so much different, but it’s 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’t disturb me, I have to focus now. For example, wearing headphones…

Host: Okay.

Tom Zimmermann: …is one of the signals people often do. Then also like how the room composition looks like so, who’s in the room sitting with you?

Host: Sure.

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’s 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.

Host: And then you present these findings to people who are in charge of…

Tom Zimmermann: Yeah.

Host: …making the environments one way or the other.

Tom Zimmermann: Yeah.

Host: I would imagine there’s a spread there because there’re some people who can work in completely noisy environments no problem, and other people who say, just get out of my face.

Tom Zimmermann: Yeah, so absolutely. Like people have very different opinions or feelings.

Host: Yeah.

Tom Zimmermann: And work differently in different environments.

Host: So, then is one of the takeaways to say, make space for these different kinds of work preferences?

Tom Zimmermann: Yeah. So, that’s one of the takeaways. And I would even say it’s a takeaway of the entire productivity research we’ve done is, that there’s not a single way to make everyone more productive.

Host: Right.

Tom Zimmermann: Right? With so many personal differences, you really need to understand how everything plays together and then you can make recommendations…

Host: Make good decisions.

Tom Zimmermann: …for individual people. Right? It’s 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.

Host: Right.

Tom Zimmermann: So, it’s not a single one-size-fits all.

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… They’ll have to come to one of your talks, I guess. Anyway… 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?

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.

Host: Hmm.

Tom Zimmermann: And so, I’ve mentioned all these different data sources that we can leverage, and we also talked about ICSE… there’s actually a conference just dedicated to the analysis of software data at ICSE. We talked about acronyms – it’s actually called the MSR Conference, but it’s not for Microsoft Research, it’s for Mining Software Repositories.

Host: Oh, that’s funny.

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’ll come up with tools that allow people to be more productive.

Host: Right.

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’s 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’s 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.

Host: Yeah.

Tom Zimmermann: So sometimes what’s best for your own personal productivity is maybe not best for your team, right? So, one thing we find is that people don’t 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…

Host: Right.

Tom Zimmermann: …make any progress.

Host: Right. Right.

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.

Host: Those are fascinating questions and fascinating research. It seems there’s a really beautiful mix of qualitative and quantitative…

Tom Zimmermann: Yep.

Host: …in your work. And it also is, over into the HCI space, I know that there’s researchers here, Dan McDuff and Mary Czerwinski, who are monitoring and then saying how can we improve our tools to make us understand when “I’m in the flow and don’t get me out of the flow” or when I could be interrupted…

Tom Zimmermann: Um-hum. Yep.

Host: Do you interact with them quite a bit?

Tom Zimmermann: Yeah. So, we got together on some things.

Host: Yeah.

Tom Zimmermann: And it’s very related, the work we do.

Host: Yeah. All right. Well let’s circle back to ICSE because you’re presenting a really interesting paper there this year called Software Engineering for Machine Learning: A Case Study, which I love. Tell us about this paper and the research behind it. How have you found AI – because that will be in there – to be sort of a forcing function for an evolution of workflows in the software development process?

Tom Zimmermann: Yeah, so what’s happening at the moment is that more and more teams are using AI in their software. And so, what we’re 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’s 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’s 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.

Host: Right.

Tom Zimmermann: And if it’s 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’t know, what is a good AI model? It’s sometimes hard to tell.

Host: Right.

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.

Host: Right.

Tom Zimmermann: So, it’s really hard to tell when you’re getting worse results than you did before. So, that’s really one of the challenges people have to figure out and that’s what we’ve been looking into in this paper.

Host: Mm-hmm.

Tom Zimmermann: So, we started off with interviews and we did surveys and collected data and did analysis of lots of open text responses.

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?

Tom Zimmermann: So, the case study is basically Microsoft. To find people, we used something called “snowball sampling” where we basically identified a few people knowledgeable in this area.

Host: And they recommend two friends and they recommend two friends…

Tom Zimmermann: They recommend friends and we kept doing this until we pretty much thought we heard everything. So, that’s called saturation, when you don’t get to hear anything new. And that’s when we started working on a survey to really understand the landscape of AI at Microsoft. The interviews allow us to go deep.

Host: Yeah.

Tom Zimmermann: Because you can talk to people one-on-one, and it gets us more rich insight and then we want to confirm what we observed in the interviews with a larger scale survey.

Host: Yeah.

Tom Zimmermann: And it also allows us to look at some other things like, we looked into how much time people spend on different activities and we had questions about challenges we face.

Host: Well, it makes me laugh because I, you know, what was your case? Microsoft. It’s a big case.

Tom Zimmermann: It is.

Host: Well, and you’re lucky. You got access to this place.

(music plays)

Host: You are busy guy, Tom. In addition to all the research and papers you’re doing, you’re one of the editors of a new book called Rethinking Productivity in Software Engineering. I’m detecting a theme here. The description says that it “collects the wisdom of software engineering thought leaders in a form digestible for any developer.” I’m gonna resist my urge to make a comment about that and just ask you to give us some highlights on what these thought leaders had to say!

Tom Zimmermann: So, basically the book is the outcome of a Dagstuhl seminar that I had co-organized. And so, we organized the seminar on rethinking productivity in software engineering. And so that’s where all these thought leaders met. And at the end of the seminar, we decided we want to do a book to basically summarize what we discussed at the seminar. So, one of the takeaways – and this is, again, not going to surprise everyone – but it’s really hard to measure productivity. And often when people think about productivity, they have like one or two measurements in mind, but it’s important to take away that you need to measure many different things if you talk about productivity. If you just focus on one or two aspects, you’re not going to get a complete picture. Because productivity depends on so many different aspects like management, work environments, which tools you use, what processes you use, how good your team is, how much experience you have… so many factors which can affect productivity. Basically, what we were doing is discussing these factors and coming up with ideas how to get at a more complete picture of software productivity.

Host: Do you ever factor in things like life events or illnesses or the kinds of unpredictable edge cases?

Tom Zimmermann: Uh, yeah, so actually when we did this work on a typical software engineering workday, some of these came up. So, if you have to go to a doctor and family emergencies….

Host: Yeah.

Tom Zimmermann: So, that comes into play.

Host: But you can’t predict any of those nor can you prevent them necessarily.

Tom Zimmermann: You cannot predict or prevent, but you can basically deal with how you react to these cases.

Host: So, having contingencies and, um, thinking ahead for the unexpected…

Tom Zimmermann: Yeah. Yeah. In the end, it also comes down – and that’s also a part of the book is – so we have one chapter on happiness of software engineers. So, one thing that has been found in research is that happy software engineers are more productive and…

Host: Are productive software engineers more happy?

Tom Zimmermann: I think so, too.

Host: Well, I like to ask all my guests to share their version of what could possibly go wrong, because pure research is way upstream of unintended consequences. So, tell us, in the context of your work, is there anything that concerns you or keeps you up at night, and if so, what are you doing about it?

Tom Zimmermann: Yeah, so what’s happening right now, I think, is like software is getting more and more important, right? So, you cannot do much without software. And we are working really hard to make people more productive, more happy, more satisfied when they use software. But I think what’s also really important is to think about the people who cannot use software for various reasons, or who are not as skilled using software. So that’s one thing which concerns me.

Host: So, give me an example.

Tom Zimmermann: So, I see it a little bit with my parents.

Host: Oh, yeah.

Tom Zimmermann: So, there are certain things they are not as comfortable doing on a computer.

Host: Yeah.

Tom Zimmermann: Which is totally natural for me and I’m also going to get older and I’m going to have the same challenges. And I sometimes see it already, like certain things I’m like, oh, it’s getting a little bit too complicated. So, that’s one thing which worries me like, how we can really tailor to everyone with software.

Host: Yeah. Is there anything you can do about that? Because that’s an interesting conundrum that’s not new and it’s going to get worse, I think, in a cloud era/AI world.

Tom Zimmermann: Yeah, so I think it’s a tricky question. And it might get worse for a little bit, but over time, I think it’s probably also going to get better because right now you need to interact with the computer. If you want to do something on a desktop computer, you need to use a mouse you need a keyboard. It’s much more complicated. But again, with my parents, like once I gave them their touch devices, it was much easier for them to interact with it.

Host: Right.

Tom Zimmermann: And if you think of what’s coming next, if you do more voice control, it’s probably also going to get easier for people to interact.

Host: So, designing much more natural interfaces…

Tom Zimmermann: Yeah.

Host: …will probably assuage some of the problems that people have encountered with an engineered environment for what we use now.

Tom Zimmermann: Um-hum. Yep.

Host: So, I like to know the personal stories and career paths of the people I interview. They are often really interesting and inspiring and sometimes they’re actually entertaining. So, regardless of your genre, tell us how you landed here at Microsoft Research in Redmond, all the way from Germany, with a stop, I understand, in Calgary Alberta, Canada?

Tom Zimmermann: Yes. Yup.

Host: Tell us your story.

Tom Zimmermann: I did my PhD in Saarbrucken, in Saarland, in Germany. And so, during my PhD, I ended up doing an internship at Microsoft Research, actually working on empirical studies. And it was actually very eye-opening for me at that moment because, until then, I only looked into open source projects. And so, when I came here, I learned really like what’s important for Microsoft, for a company, for large-scale software development.

Host: What year was that?

Tom Zimmermann: It was 2006. And I really enjoyed my time here. So, when I finished my PhD and I ended up going to University of Calgary as Assistant Professor for one year and then the opportunity opened up with Microsoft for me to become a researcher here and I jumped on it.

Host: Right.

Tom Zimmermann: Because most of my research was very data driven. I had a good time here during my internship and I thought, what a better place to be for data than Microsoft? And since then, I’ve been here, and I’ve done data analysis of many different things. I looked into games telemetry, like how we can increase player engagement on Xbox. And lots of software data about software teams, software productivity. And so, it’s been really interesting.

Host: Well it seems like the research that you do has broad application in any division…

Tom Zimmermann: Yeah.

Host: …around the company. Do they let you out of 99 to go around?

Tom Zimmermann: Yeah. We got out of 99 a lot. So, and that’s really nice about being in research because we can get to work with many different product groups on many different challenges and they usually all very interesting.

Host: Well, that’s great because that’s where research becomes practical and helpful in immediate situations.

Tom Zimmermann: Yeah. And the other thing which was really great about coming to Microsoft is… so initially, my motivation was to come because of the data, but what I learned, once I came here, is you also get the people who you can talk to about the data which is a very big difference compared to a more open source setting.

Host: Come for the data, stay for the people.

Tom Zimmermann: Yep. It’s all about the people.

Host: Along those lines, here’s a new question I’ve been asking. What’s one interesting thing whether it’s a trait about you, a characteristic, a life event, that people might not know about you and how has it influenced or impacted your career as a researcher?

Tom Zimmermann: Okay. So, I’ve been always been fascinated by numbers and so here’s one thing I think only my parents and my sister know. When I was like little, like 8 or 9, I actually did my own stock index. So, and it was the old days, it was before internet. I didn’t have a computer. So, basically every morning the newspaper came in, I took the newspaper, was looking at the stock listings, looking up the numbers computing my own stock index, writing it down in like a notebook and I kept it for quite a long time. And so, it kind of started my interest in doing data analysis.

Host: Were you a good analyst?

Tom Zimmermann: Uh…

Host: For 8…

Tom Zimmermann: For 8, I would say yes! I mean, it was not a very clever stock index and it’s – I just found, I just liked adding up numbers, doing the average and keeping track of it and…

Host: Do you follow the stock market now?

Tom Zimmermann: I still follow the stock market.

Host: And do you analyze how they are analyzing?

Tom Zimmermann: Uh, so I don’t do analysis on the stock market. I think there are people who are smarter…

Host: See what I’m saying?

Tom Zimmermann: Yeah.

Host: I like it!

Host: As we close Tom, I’d like to give you the chance to say something profound to our listeners. If there’s anything you believe would-be researchers in programming languages and software engineering ought to know, now is your chance to say it!

Tom Zimmermann: I have something very short and concise. It’s that software is more than bits and bytes, it’s all about the people.

Host: How can you close with anything better than that? Tom Zimmermann, Tom-Z… thanks for coming on the podcast today!

Tom Zimmermann: Thank you for having me.

(music plays)

To learn more about Dr. Tom Zimmermann and the science of programmer productivity, visit

Français English