Dianne Marsh on Language and Frameworks Used at Netflix, the Manager's Role, and Diversity in IT

1. My name is Charles Humble and I’m here at QCon San Francisco 2014 with Dianne Marsh. Dianne can you introduce yourself to the InfoQ community

Sure, my name is Dianne Marsh; I am the director of engineering for Engineering Tools at Netflix. That means that my team is responsible for the tools that the developers use to build, bake, and deploy to the Cloud, so really anything from code all the way through to deployment out in the Cloud.

2. When you are hiring an engineer at Netflix, what specific things do you look for?

So when we are hiring engineers at Netflix, mostly we look for passion around the area that the person would be working in. Does this person really want to work in the industry? Does the person want to push the envelope and not stop learning? So, you know, that continual strive for education and for continuing to push the envelope. Specifically for my team, I look for great communication skills in engineers; my team is a centralized team in a company that doesn’t have a lot of centralized teams, and so we reach out to all of the other developer teams, which means that my team has to be really good at reaching out, at follow through, at being able to explain what we are doing and being able to work with other developers. So communication skills are really super important for my team.

3. [...] From a kind of people point of view, what are some of the things that slow people down and what do you look for and try and take out of the process?

Charles full question: Something I know from listening to you present, and also talking to Adrian Cockroft and people like that, is basically Netflix was designed for speed of execution essentially; to get things done really quickly. So from a kind of people point of view, what are some of the things that slow people down and what do you look for and try and take out of the process?

Yes, you are right. What we want to be able to do at Netflix is push things out really quickly: keep people moving. A manager’s role at Netflix is really just to get out of the way, you know hire really great people and get out of the way. I think what a lot of companies make the mistake of doing is hiring really great people and then putting a lot of processes in their way and a lot of gates that actually slow them down, or question the direction that those people want to take; and instead we really want those people to do what we hired them for, and frankly what we pay them for, which is just to build great software; and so a manager’s job at Netflix, my job at Netflix, is to make sure that I give my team context about what the rest of the company is doing, and give context about what my team is doing to the rest of the company, so that we can all make great decisions together about what to do. I get out of the way of the decisions that my team make, so that they can independently come up with great ideas, and I don’t have to stand in the way and decide which things have legs and which things don’t. Instead I just depend on the wisdom of the people that we hire to be able to make those decisions.

4. Something you talked about in New York, I remember, was encouraging experimentation amongst developers, and parallel paths of exploration, and that sort of thing. Are there kind of cultural aspects to that that you have to promote and maintain?

Yes, so it’s pretty important to us that we don’t prematurely optimize solutions; that we don’t all sit down by committee and decide group A is going to do this thing, group B is going to do this thing, and don’t overlap and make sure that you stay within your boundaries; that’s not us at all. Instead we really leave it to the teams to make those decisions and, if there is overlap, then we benefit from the parallel experiments that happen, if those things work, and we benefit from the information that comes back if they don’t; and so either way I think it’s a win that we wouldn’t get if we sat down and tried to really just control all of the development aspects and who is doing what. Instead we get to throw more minds at the problem.

5. Something that comes up a lot in the industry is the lack of diversity and obviously the sort of gender bias that we have, in technical roles at least, in IT. So I guess first of all I’m curious as to whether you think that’s a problem, and if you do, what could we do to try and address it?

So this is an interesting problem I think. Until, gosh, I don’t know maybe about 6 or 7 years ago, I didn’t think it was a problem. I didn’t realize how low the numbers of women in Computer Science had dropped to; and part of this was because when I graduated with a bachelor’s degree in Computer Science was in the mid 80’s, and this was the heyday actually of women getting degrees in Computer Science - so around 34-37% of the degrees at that time were going to women, and that was consistent with engineering as a whole, and it was still climbing. What I didn’t realize until I went back and looked at this a few years ago, was that at that time that was really when it starting dropping, right after that, and we’re back down to numbers in the 12% range; which is about where we were in the 1970’s, which is a little bit shocking.

And so, before, my opinion was, “Well you know, if women don’t want to go in to Computer Science, then why should we really try to encourage that? They have choices; they are just choosing not to do this.” But I feel like there is a bigger problem that we are not addressing and that is, why are they choosing it? I feel like when I talk about it as one of this 25-30% of women in the industry, we are leaving out 75% of the conversation - all the men. So what we really need in order to start building the number of women in Computer Science, is we need the men in the industry to be talking to their wives, their girlfriends, their daughters, their sisters, their cousins, and telling them about the field and encouraging them to go into the industry, and I think that that’s the only way that we are actually really going to make inroads. I think we need to really start with little kids, you know the elementary-middle schoolers. You know I think there is a lot of emphasis put on college-aged kids; honestly I feel like we’ve already lost that battle right now, and so I think we need a backup and work a little bit harder at the younger ages and try to build up those numbers. People that are in college at this point, I feel that they’ve already made up their mind, and there are lots of really great people working on that problem, so I’d rather focus my energies on younger kids; plus I have a daughter who’s eleven and I’d really like her to be able to make whatever choice make sense to her.

6. [...] Is Java still your main language of choice or are you mixing and matching; what are you doing?

Charles full qustion: Great; so let’s change tack a little and talk about some of the technology stuff. I think most people are probably familiar with the high-level architecture that Netflix has talked a lot about - the Microservices stuff and the Simian Army, and all of those bits and pieces. So I thought we might drop down a level and talk about things like the languages that you are using. I know you… I think I’m right in saying, at least, that you started as a Java Shop and I believe I’m also right in saying that you personally are a bit of a Scala fan. So is Java still your main language of choice or are you mixing and matching; what are you doing?

Yes to all of those things and more. Netflix is primarily a company that builds their services on Java; we have a lot of Java programmers but one really great thing about Java is that it opens up the whole JVM languages opportunity. So we have some teams that write in Scala, some teams that write in Groovy, some teams in Clojure; and that’s just on the JVM. We have other services that are written in Python, and in fact there is a Python application in my team that is in open-source, and we even have some teams that write in Ruby, and this is a fairly recent addition.

7. Is that JRuby?

No, not JRuby. Some of the enterprise tools that support, not our service, but sort of the peripheral functions around the company, so for legal and other partner tools we have actually some Ruby on Rails applications.

8. OK, and I know you ported the reactive extensions library to Java as well, so presumably you make quite heavy use of that on the front end?

Yes; so we have the RxJava project that Ben Christensen has tirelessly worked on, and that’s pretty popular and gets widespread use within the company. I think that we have a long way to go still in adoption of that and lots of opportunity within the company to take advantage of reactive extensions.

9. Are there any other frameworks that you make extensive use of?

Yes. The interesting thing about Netflix is that we don’t limit or specify languages or frameworks: development teams make their own choices. So one of the teams on my team uses Spring Boot for some of the applications that they are doing, there are a lot of Grails apps around; so there is just an extensive number of applications. There are some Scala frameworks running around as well, so just lots of choices, and I think that combination is really good for the company. People talk a lot about the advantages that they see: this team uses Ember and this team uses Angular, and they talk - those teams get together and talk a lot about their different programming experience. I think that that interaction builds a richness in the company.

10. What do you use for your build system?

So we’ve just moved our build system from an Ant/Ivy-based build to Gradle, with some extensions that we’ve written and put out in open-source called Nebula for Netflix Build Language, and that’s working really well for us. The speed improvements that we are getting are phenomenal, when compared to our older build system, so people are really excited about that.

11. Do you have any concerns about that sort of diversity of languages and frameworks and things, in terms of maintainability of code, in terms of kind of on-ramp for people joining the company and so on?

Yes, but frankly software doesn’t last that long; right? I mean people rewrite software all of the time and so, yes, you could say that we should standardize on a specific toolset; but new frameworks and new languages come up all the time, and people are tempted to try them and don’t want to be saddled with less efficient means for writing code in older frameworks anyway; so they are always looking for a way to up their game, and so I think that the lifetime of the software is constantly evolving, and so the opportunity to bring in new languages doesn’t really add too much risk; and I think that the benefit we get is in leaving the control where it belongs, with the teams that are actually doing the implementation, and with this parallel experimentation that we talked about as well.

Charles: Excellent; thank you so much. I think that’s a brilliant place to stop actually.

Great; thank you!