StaffEng Podcast

Nell Shamrell-Harrington (Microsoft)

Today’s guest is a principal software engineer at Microsoft who works at the interface between external and internal elements of the organization. Nell Shamrell-Harrington works on the ClearlyDefined open source project, which tracks open source licenses across open source ecosystems, and is also part of the Rust Foundation’s Board of Directors. In today’s episode, you’ll hear about the “field commander” role that Nell plays in both of these organizations, and some of the major learnings they have had along the way (with particular emphasis on the importance of ensuring that technical interventions are responding to the needs of the business and the community). Nell also shares their experience of mentoring veterans through Operation Code, their approach to mentoring in general, and how this impacts their day-to-day job. 

Links

Listen

Download Episode

Transcript

Note: This transcript was generated using automated transcription and may contain errors.

David: Welcome to the staffenge podcast where we interview software engineers who have progressed beyond the career level, into staff levels and beyond. We’re interested in the areas of work that set staff plus level engineers apart from other individual contributors. Things like setting technical direction, mentorship and sponsorship, providing engineering perspective to the org, etc. My name is David Nguylromis and I’m joined by by my co host Alex Kessinger. We’re both staff plus engineers who’ve been working in software for over a decade. Alex, please tell us a bit about today’s guest.

Alex: Totally. Today’s guest is Nell Shamrill Harrington. Nell is a principal software engineer at Microsoft and Microsoft’s representative on the Rust Foundation’s Board of Directors. It was a treat to talk with Nell about all their roles and I think you will appreciate it as well. Let’s get into it.

Nell: Well Nell, thank you so much for.

David: Taking the time to chat with us today. If you could start by just kind of telling us who you are and what you do.

SPEAKER_D: Sure thing. I’m Nell Shamrell Harrington. I’m currently a principal software engineer at Microsoft. I am split between working on a product called Clearly Defined. I lead engineering on it and that is a project which tracks open source licenses across open source ecosystems. So if you are using an open source project, want to check that the license is in compliance with the licenses that you can use, or if you’re getting conflicting information about what the license might be. We have Data Store where we store information about licenses. We have some automated ways we determine what the license is most likely to be, as well as having human curators who come in when needed. The other thing I work on at Microsoft is the Rust programming language. I am Microsoft’s representative on the Rust Foundation Board of Directors and prior to Microsoft I was at Mozilla. I was a senior staff engineer there working on the Rust language full time. And prior to that I was a principal engineer at Chef Software.

Alex: Wow, that’s like a lot of senior engineering roles. I’m curious, when you came to Microsoft, was the principal role explained to you? Like, did they have a set of expectations for principal engineers at Microsoft?

SPEAKER_D: They do. Microsoft is one of the first places I’ve worked at where they do have the role clearly defined and they do. I just use clearly defined the sense and that’s the name of the open source project I use. But where they do have it is a nice thing about big tech companies. They have clearly defined expectations for the levels. At least they do at Microsoft, which is nice.

Alex: Nice and I’m sure that if they’re well defined, there’s probably a lot of text there. But are there highlights that you could surface about what the expectations are of a principal engineer at Microsoft?

Nell: Sure.

SPEAKER_D: The way I understand it, and of course my understanding might be different from other people’s because even though it’s written down, the way you can interpret it is a lot of subject to interpretation. So what I think of as a junior engineer, intermediate engineer role is you’re focusing on one part of one product or maybe just two or three products. That’s how I define a junior intermediate engineer, senior engineer. You’re focusing on the entire product or the entirety of two or three products. Once you get to staff principal, you’re focusing on an entire architecture, so an entire suite of products. Obviously at Microsoft, no one architects the entirety of Microsoft’s products. There’s way too freaking many of them. But you do, you are in a engineer, a technical leadership role over several products. And the cool thing about clearly defined the open source product I work on is it deals with, I like to say deals with ecosystems of ecosystems because we are analyzing and tracking license information across all sorts of language ecosystems. And it’s the same thing with Rust. It’s used in so many different contexts. So it’s, you know, you’re not laser focused on one thing. Like even though I do still do quite a bit of coding in my day to day role, it’s not laser focused all the time. I am more focused on where does this piece, this product fit in a larger architecture and larger ecosystem. And part of my role as principal is to keep that big picture within my head at all times and not indulge in my engineering tendencies of wanting to dive down deep on one specific part for days at a time. I have to stop myself from doing that because that’s not my role anymore. So that’s loosely how I would interpret how it is.

Alex: And it sounds like you’ve had senior engineering roles across multiple organizations. And I’m curious, does that understanding of principle, do you feel like that’s held similarly across all the places that you’ve worked or is it different across all the different places that you’ve worked?

SPEAKER_D: I’d say it has been different. I was at an org where they weren’t sure what a principle was, but they needed something to promote people beyond senior. So they had, you know, principal role in the, the career ladder, but it was more of a very, very senior coder role. Whereas other orgs, it’s, you know, there are some orgs where principals don’t code very much and it’s much more of an overall architecture role. And you know, at Microsoft I’d say it’s a combination. So there are some differences. Not every org I think understands what the role is or how it fits into their particular a small startup. I did three startups in a row before I went to Mozilla over nine years. Great experience but oh man was I tired at the end of it. But in that case there’s so few people that it’s a much more hands on technical role versus you go to a big tech company where it might be a hands on technical role or you might be in meetings all day. Again, keeping the big picture in mind and making sure all teams understand what that big picture is and know how they fit into it.

Alex: Cool. And obviously given any sort of general description of a role, there’s probably the way that an individual practices that role is a little bit different. Have you thought at all about how your practice of being a principal is different from maybe the written down expectations that Microsoft has?

SPEAKER_D: Right. I’d say in the role I’m in working with Rust, also working with Clearly Defined, which is a very much an open source project, I’m pretty public facing. I’m 99% sure that is not part of the written description of the roles at Microsoft. And again, you know, Microsoft 10 years ago had a kind of a toxic relationship with open source. I can tell you it has improved dramatically. It is not just hype, they have made a transformation. But yes, in my case it’s a very public facing role. So it’s not only internal engineers that I’m working with and leading the technical work of, it’s also community members, some from other customers, some from people who are interested everything from new boot camp grads who want to get their feet wet and open source to very senior staff principal engineers at Microsoft or at other big tech companies. So I’d say that’s the major difference for me in my role. From what’s written down.

Nell: Cool.

Alex: And I’m curious, does being a principal engineer at a company inform your role in the Rust community and does your role in the Rust community inform how you practice being a principal engineer?

SPEAKER_D: It does what I said when I started on the Rust foundation board, which only started back in February or March. My job as a board member there is to represent the interests of Microsoft to the Rust community. That I am Microsoft’s representative, that is part of it. But more importantly it’s to represent the interests of the Rust community. Back to Microsoft. A part of that, the Rust community has a RFC or request for comments process. That is how we figure out changes in the language and changes in the ecosystem. And a lot of what I’ve been doing internally at Microsoft is, you know, coaching people through the RFC process. You know, this is how you write it, but more importantly, if it stalls, this is how you get conversation going and you want to do it with, with nudges. The Rust community responds much better to nudges than someone trying to come in and push their, their will or push their way on it. So I’d say it informs both of them. And that honestly has made it a little easier to advocate for changes within Microsoft is knowing how to define what the technical changes are, but also knowing just because we can doesn’t mean we should not. Trying to quote Jurassic park, but there it is. And it’s understanding that not everyone has the understanding. I can tell you this was public. We were looking at adding another source of Go components to clearly define or not GO components, maven components. And it involved crawling one of Google’s Maven repositories. I said, all right, we need to talk to Google first because if we’re crawling their thing, they don’t like it, they could conceivably block it from us. The response I got internally at Microsoft was, well, we can get around it through this way, this way, this way, this way. I said, I know we can, but that’s going to put a bad relationship in place and we don’t want to do that. Yes, we can technically do that. Should we do that? We probably should. I don’t think they’re going to say no, but we need to talk to the people, the technical people first before we actually do it. And that’s what we did and it worked out beautifully.

David: Out of curiosity, where is Rust used within Microsoft these days?

SPEAKER_D: All over the place. I can’t keep track of it. It’s very much still an experimental mode, I can say that. But there are several teams that publicly, I can say there are teams that are experimenting with using it where they would normally use C or using it to interact with old C. Windows is a giant code base. Office is a giant code base. Rewriting all the C. And Rust is not going to happen. But there are places where we can write new components in or even rewrite certain parts of old ones that have a lot of memory vulnerabilities. That’s one of the things Rust does best, is it prevents you from doing common memory insecure things. And so I’d say it’s still an experimental mode. The enthusiasm is there, which is fantastic, but now we need to make sure it translates into technical value, which I think we’re going to be successful in.

David: Okay, so jumping back into it, Nell, can you tell us a bit about sort of tactically what it looks like, what your involvement in the projects you’ve described looks like? So you’ve talked a little bit about your involvement with the Rust foundation and really curious to hear sort of what your day to day looks like with Clearly Defined.

SPEAKER_D: Certainly. So part of it is through creating new features and a big thing I did when I came in, when I started at Microsoft in October, Clearly Defined had not had a full time engineer on it for about a year. It had been in maintenance mode and there was a lot of cruft that had built up and that happens. So a big part of my job I worked at Chef, I’ve worked as an infrastructure engineer, was figuring out what the infrastructure of Clearly Defined was, documenting it. And then we were having problems with bottlenecks, so was identifying where those bottlenecks are. What do we do infrastructure wise to make it better? Mostly Clearly Defined infrastructure runs on Azure. So that was my first project which was make the infrastructure that runs the sites and the crawlers and such work better. A lot of what I do is code review. We do have contributors both from within Microsoft and from external to Microsoft. So I am const scanning for pull requests. I review those. What I see as the role of code review is to make sure one, I mean the code is functional, which it usually is, and 2 there’s no security vulnerabilities that are introduced. 3, it’s repeatable or it makes sense to look at it. And there was a fourth one, but I can’t remember what it is off the top of my head. But it’s not trying to impose my personal preferences for how code should be. If it’s not something that’s going to affect the functionality or the security or the maintainability of the code. That was the fourth one, maintainability. So code review is a big part of it. Also defining architectures for new features or new additions to it and then also talking with the key users of Clearly Defined, which again includes engineers at other big companies. It includes people within Microsoft figuring out how they use it and how we can make it work better for their processes. Often that’s kind of the role of a product manager. I do a little bit of that, but it’s very much an engineer to engineer kind of communication and I do have a fantastic PM who does a lot more of the business to business communication, but it’s figuring out how to make it work better within the ecosystems that it functions in. That was a pretty long winded answer.

Alex: Yeah. No. So when you joined Microsoft and you knew that you were going to start working on clearly defined what was sort of like the mission that was described to you at the beginning.

SPEAKER_D: Big part of it was so clearly defined is not technically owned by Microsoft, it’s owned by the Open Source initiative but Microsoft sponsors it in part by paying my salary to work on it. And one of the part of the mission that was handed to me was, you know, Microsoft is the primary user of this project. We don’t want it to be just a Microsoft used project. We need someone who yes, can work internally with Microsoft engineers on making it work better for their needs. But we and lead engineering with regard to other Microsoft engineers but we need someone who can also work with a community and make the project work better for the needs of our customers, other big users of it, and also make it work well as an open source project. I mean when I came in I would say at that point it was open code, the code was out there. But there wasn’t really a. And there hadn’t been for a long time due to nobody’s fault. I mean things change. But there hadn’t been a nurturing is how I put it of a technical community around it. So that’s not just the role of a traditional community manager. I’m not a community manager. I’ve been a community manager before, but that’s not my role at Microsoft. But they needed someone who could work on a technical level with other people who wanted to contribute to the project and also wanted to use the project. So that was the mission as it was laid out to me is make it work better for Microsoft but also critically form a technical community around it and make it work for their needs as well.

Nell: Cool.

Alex: And help me connect the dots a little bit here. So what’s interesting is that I feel like you described something that was about sort of the code as it is in the repo, building partnerships across, you know, with outside partners. But earlier you were talking about how, you know, the code was a little bit. There was cruft, there were bottlenecks you had to run inside of Azure. So how did you go from community building aspect to optimizing it and making it run better in Azure? Or did I misunderstand that part?

SPEAKER_D: It was both. Both at the same time. Some community building we do bi weekly community meetings. We have a discord where people chat about the project and how to use it. And then it was also doing that in depth infrastructure work as well. So doing both simultaneously.

Alex: Okay, cool. So when you were working on the project, how did you ascertain that like infrastructure work was needed? And how did you explain to your stakeholders that like, this is something that we need to do?

SPEAKER_D: The first thing I always ask someone when I come into a project, whether it’s a contributor, whether it’s a user, et cetera, is what’s causing you pain. And often it’s a variety of things. And I talk to 10, 15 people or possibly even more and see where the common pain points are and then figure out, all right, what’s a quick. What’s something that we can make work better right away? One was enhancing the way that the curators, the way clearly defined interacts with GitHub. GitHub is where the curators do their work. Okay, quick win, we can do that. But what are common pain points that are not necessarily quick wins? And one was that the infrastructure was falling over occasionally and that was causing data to be corrupted or to be unreliable. And that took a couple of months. A lot of observation of it. Diving into logs. Nice thing about Azure is they have, I mean, well, I guess every cloud has really good log parsing software, but Azure’s I particularly like and looking for patterns. That’s one of the key things you do as a. When you’re trying to figure out, all right, we know there’s bottlenecks, we know this is falling over for some reason. This is distributed microservices architecture. We’ve got. They’re not called lambda functions in Azure, but now I can’t remember what they’re called. We’ve got serverless functions going, we’ve got a variety of databases, we’ve got several different containers going all at once. All right, this is falling down somewhere. Where is it falling down? And observability. I learned a lot from the people at Honeycomb about it. I didn’t use Honeycomb in this case, but I learned about the principles from them, which was let’s find the bottlenecks by observing how the application behaves. Again, nice thing about having a community was I put in discord. All right, if anyone sees this specific behavior, because this was something that’s happening in the middle of the night my time, please add something to this GitHub issue or just put something in Discord. So we have a timestamp on it and I can go back and observe what was happening at that particular time. That was a way to. Number one, I found out our MongoDB database. We were doing some very expensive queries on it and it was timing out. We had Cloudflare in front of it. Cloudflare. The request, understandably, can only take a certain amount of time. So cloudflare was timing out, but the user was seeing the cloudflare timeout error. They weren’t seeing the actual error in the application. That indicated the MongoDB query was taking too much time. So that was a big one. Other one was we found we had to scale laterally as well as. Or horizontally, excuse me, as well as vertically. And there were different problems that each of those solved. So again, long winded answer. But observing the application, tracing it to where people’s pain points were, what they told me about, and then devising solutions based on that, which often involve changing things in multiple places, which is something I’d like to improve over the year, which is ideally microservices. When you change one, you don’t have to change a bunch of them. That’s not the reality right now, but it’s something we can work toward.

Nell: MongoDB performance issues, say Natsu.

SPEAKER_D: Yeah, it’s very powerful, it does great things. But, oh my God, you did not want to query it the way you would query a relational database. And that’s some of what was going on.

Nell: Yeah, exactly.

Alex: Yeah.

Nell: No, I don’t want to cast aspergens. I’ve used mongodb in anger many times, but it does a good job for what it’s made for. So one of the things that we often ask folks, and I’m curious, given that the sort of core of your work is involvement in open source. I don’t know how this will differ for your role, but a lot of the, you know, staff, plus folks that we talk to, a big part of their job is sort of gaining alignment with the organization. Right. I mean, I’m sure that’s a factor in your role too. I just don’t know what it looks like as much because you’re not necessarily working on Microsoft products. You’re, you know, you’ve been sponsored by Microsoft to participate in open source projects for the most part, from the sound of things.

David: And so I’m curious to get your take on that.

Nell: How do you think about sort of organizational alignment? How do you make sure that, that the work that you’re doing aligns with what Microsoft expects from you?

SPEAKER_D: Right. It is challenging because I’m not working on a piece of Windows. But I do know my work ties into Windows in that clearly defined is used by an internal Microsoft product called Component Governance, which is used, as far as I know by all products at Microsoft to ensure that the licenses in the open source software we use are compliant with Microsoft standards. Like we don’t really want to use gpl. Yes. Microsoft builds commercial software. It always has. So my work is more of an interface to the rest of the organization. And it took me a little bit to figure out that’s what it was. That said, when you’re a principal at Microsoft, after you’ve been on the job six months, they have you go through a Microsoft Leadership 365 evaluation thing. It’s basically not 365. There’s too many Microsoft 365 products. Microsoft.

Nell: It would be perfect if it was called Leadership 365.

SPEAKER_D: I know, I know. Three hundred and sixty. Why do we call 365 but 360 principles. So there’s a survey of your co workers, other people who work with you, your manager basically trying to figure out where your strengths are and where the things you need to work on. What I found, what I need to work on most is to use a military analogy, I do volunteer work with the U.S. marines. I work the veterans nonprofit. I know some people have some visceral reactions to using a military analogy. But I do think it’s appropriate in this case, which is I’m very used to being a field commander kind of role, which is I am working with one team or maybe three or four teams. Someone else has set out the vision. But it’s my job to figure out how we execute it and use the strengths of my team. I set goals for the team or the teams themselves. But to use those strengths to execute this other person’s vision. However, what I need to work on is being the person who sets that vision and understanding how it fits into the larger overall story of the organization. Again, as I said, Microsoft giant company, 150,000 people. That’s a challenging thing to do. But there are clear lines in what I do to nearly everything else that. Not clear lines, dotted lines in what I do to nearly everything else that Microsoft does.

Alex: Does.

SPEAKER_D: So it’s a challenge. It’s something that I’m working on and it’s something I have a fantastic manager, Stormy Peters, who is the director of Open source at Microsoft. I’m learning how to do that. So it’s a work in progress, I would say.

Nell: Yeah, that’s fascinating. I Hadn’t really considered the aspect of clearly defined being used so heavily internally. But it makes a lot of sense. And I haven’t contemplated sort of the impact of like all these licenses kind of leading through all the open source code that we all depend on every day for our work. But that’s interesting, kind of along the same, well, the flip side to that coin. So if you’re not seeking alignment from above you in the organization, the other thing that we all sort of find ourselves needing to do is getting the teams that we work with aligned on the work. Right. And I think yours is an extra interesting challenge because in addition to people that share sort of reporting chains with you, there are also people that you work with or that you want to, that you seek to influence, who are, you know, open source contributors from elsewhere. And so what approach do you take to sort of gain alignment? You know, you talked about sort of executing a vision, whether it’s your vision or a vision that you’ve inherited, but like you sort of need to market that to the troops, so to speak, to continue the analogy and sort of what does that look like for you?

SPEAKER_D: Right. That is a challenge. It was a big challenge when I was working at Chef. That was one of the key things or one of my last big projects my last year there was all right, how do we make these products? We had several open source products work for our internal business needs while not alienating our community and making sure that it works for their needs as well. And I’m going to first off say that is hard. And I don’t think anyone has figured out how to do it perfectly yet. That said, the absolute best thing that you can do is listen a lot. I have again, engineer tendency. I have to stop myself from getting caught up in trying to, in saying this is what we’re going to do and this is technically superior because of this. Because ultimately, from a business standpoint, technical superiority does not matter if it doesn’t meet the business need. Technical superiority does not matter if it doesn’t meet the community need need. And that is a hard tendency to overcome. Since I moved into staff and principal roles several years ago, that was one of the first things that I had to work on a lot and make a lot of mistakes in figuring out how to. You learn through your mistakes and you will make a lot of them. It’s okay as long as you learn from them and they help you grow. So a lot of it is listening. Something I did find I had to do, especially in the open source world when I Bring something to someone, whether it’s an RFC or whether it’s a GitHub issue, whether it’s internally or externally. And I say, I want some feedback on this. There’s two ways people can interpret a request for feedback. One, and this is the way I usually intend it, is assuming I do this, how will this affect your workflow? And if it’s going to negatively affect the workflow, I might, you know, maybe not change exactly what we’re going to do, because there’s a compelling need for it, but I’ll change the way we execute it. There’s so much more. There’s so much flexibility in the execution, much more than I think we realize, again, when we’re getting into our little engineering laser sights or tunnel vision. And the second way, however, people can interpret a request for feedback is that I’m requesting their permission to do something. And that is where a lot of the drama happens. And it’s setting that expectation first, saying, there is a compelling business need for this, but I want to know how this would affect you, to inform what we do and how we do it, and setting that expectation up front. I keep using those words, but it really is critical. That helps a lot. So the best product manager I’ve ever worked with, Tasha Drew, she’s at VMware now, but she used to be at Chef, I called her. And she knows this, the benevolent Hannibal Lecter. Because what she would do is she would have conversations with all these stakeholders, including community stakeholders, including business stakeholders, et cetera, and suddenly plant ideas in their mind about how the product should work or how it would improve their needs for the product. If it worked in this way, and two months later, they’d all magically be in alignment. Maybe not magically, but they’d all be in alignment without realizing that that’s what happened. So I’ve tried to learn a little bit from that, in that sometimes you need to push. Yes, sometimes that happens more often. It’s good to start with a nudge and connecting it to showing that you understand that stakeholder’s need and connecting it to that need helps a lot. I don’t know if that answered your question.

Nell: No, I think it does. And I think, I mean, one of the key takeaways that I’m hearing there is that, like, there’s an element of sort of patience that’s required. Right.

David: I found in my role, it’s very tempting to show up and be like.

Nell: Okay, you know, we have this problem. I have come up with this grand solution. Here it is you’re welcome, everybody.

SPEAKER_D: Right, I’ve done that and they shouted me down.

Nell: Yes, that is not usually a path to success. And I think like the harder approach is to be patient and to sort of, as you suggest, like sort of nudge and also listen a lot. Like genuinely listen. Not just nudging people toward the grand solution that you have in mind, but also sort of like understanding, making sure that it really does meet the different use cases and asking lots of questions and sort of like gradually moving toward a solution.

David: I have found that really difficult.

Nell: But you know, there’s, there’s a lot of things in there. It’s partly about properly understanding people’s needs and it’s partly, it’s, it’s largely about just making sure that everybody is brought along. Right. Like it, it’s, it’s really hard to get everybody on the same page as you right away. It takes some time.

SPEAKER_D: There. There’s three key words to always say when it feels like someone is objecting to what you’re proposing. It’s tell me more. Because that once you understand more of the problem, that is when you can, and this sounds manipulative, maybe it is a little bit, but that’s when you can connect their personal needs, connect, even make an emotional connection. Again, it’s what’s causing them pain. Connect to what’s causing them pain and then you can show how what you’re proposing will potentially make that better. If it will make it better, of course. And if it isn’t, you can, you know, alter your approach.

Nell: You mentioned sort of this learning from a product manager. We actually just. A recent interview that we did was with a staff level person who’s moving into product management. And I’m kind of fascinated by the overlap between staff plus technical leadership and product management, because I think there is some. What are some other lessons that you’ve taken from product managing folks?

SPEAKER_D: A big one is I’m not going to give many details about this, but I was on site with a national security contractor and one of the engineers on my team was getting into a pretty intense nerd fright, nerd fight with one of their security engineers over encryption algorithms and which was superior. And the product manager who I worked with finally took aside our engineer and said, no, you don’t understand. They have to check a box that it uses a specific encryption algorithm. It’s not about which one is technically superior. It’s about these are their needs.

Alex: Needs.

SPEAKER_D: They have to check certain boxes, especially in national security kind of spaces. Stop arguing and start listening to them. And figure out what we can do to meet their needs. Because they have needs that we can’t change. They can’t change them either. They change through acts of Congress or other things. And that takes a long time. So that was a big one. Second one is understanding the overall story before getting into the implementation. And again, as engineers, that’s hard. We want to dive right into the implementation when we hear about a problem. All right, this is how we make it better, making sure we understand the overall problem first. Number one, you’ll build a better product. Number two, you’ll know how to talk about it. And that’s something I’ve learned from wonderful product managers who I’ve worked with.

Alex: As an engineer here, do you do any form of, like, sponsoring or mentorship?

SPEAKER_D: I do. I am on the board of a veterans nonprofit called Operation Code. Brief story. Both my parents were 20 year U.S. air Force officers. Grew up in military culture. Very much wanted to go into the military. I had a medical disqualification that developed when I was in high school. So I went to small liberal arts school and then I went into the tech industry. But I always felt, I mean, military culture is home to me. It’s what I grew up in. And I always felt a strong draw to it. And as the wars in Afghanistan and Iraq began to wind down a few years ago, a lot of veterans were leaving the service and trying to come into the workforce. And that is a big transition to make. Going from somewhere where you had a very clear mission, knew exactly, for the most part part where you fit into that mission, to coming into the civilian world, which is very different, particularly the tech industry. In the military, it’s we. In the tech industry, it’s I. So I literally put out a call on Twitter and said, is anyone doing work with teaching veterans technical skills? Someone responded, directed me to the founder of Operation Code, David Molina. The organization was still in its early stages at this point and he said, why don’t you come on board and be a mentor? So I did that for several years. That experience showed me how, how I knew how important open source was to the tech industry and engineers. But I didn’t realize how important it was for engineers who were very early in their career because it gave them a clear profile, a GitHub profile that they could bring to potential employers and say, this is what I’ve done on these open source projects and this is what I can do for your organization. So I’ve done a lot of mentorship through there. I eventually became their cto, which results again, a lot and that was a very tactical hands on CTO role. Again, mentoring people through their first open source contributions, teaching them kubernetes. While I was learning Kubernetes, that was interesting. But that’s a very in demand skillset. A lot of open source projects, they’re not just projects, less products, they’re also teaching devices. And kubernetes was an extremely in demand skill. So I’m now on their board which is less of a hands on role, it’s more of a again, setting overall direction. But I still do a lot of listening. One of my favorite things in the world to do is sitting next to someone or sitting on a zoom call with them because of COVID and guiding them through their first open source contribution and seeing their eyes light up when they hit that submit pull request button and then seeing it get merged. That is such a wonderful, wonderful feeling. So yes, it’s one of my favorite things to do. And you do not really know something. It’s true. You do not really know something until you can teach it. And it has improved my abilities as an engineer massively as well.

Alex: Awesome. When you are sort of working with someone, you know, side by side or sort of coaching them, you know, do you take. Is there an approach that you take with them? You know, is it different than say what you would do with a less experienced engineer? Or is it the same? What are the qualities of that?

SPEAKER_D: It’s pretty similar. I had when I was at Chef, I had an intern for six months. She was a delight to work with. She had just come out of boot camp and one of the things we did, I am not someone who can pair all the time. It just, I’m an introvert. It just. I can pair some of the time, I can’t do it all the time. But what we did was we set up two hours every day where we would pair together. And that let me still do other work that I needed to do in the time we were not pairing. It gave her some time to try some things on her own, but she always knew we were just a few hours away. Also, she sat across from me in our office back when we went into offices and knew there would be a time when we would be working together on it. And a lot of what I liked to do was we didn’t stick this religiously, but when I’d start, I would write a line of code. She would write a line of code. This is a Ruby on Rails application. I would write a test, she would write the code. To pass the test. She would write a test, I would write the code to pass the test. And it was interesting to see. I mean, boot camps, they do teach people a lot, but there’s so many subtleties of git that I forgot were there because they live in my fingers and it helped me understand it better. So that’s one approach. The second approach is if someone has done a few pull requests but is worried that if they open it on the project they’re going to be raked over the coals, which I usually steer them to projects where that’s not likely to happen. But I understand that fear. I had that fear immensely when I was a junior intermediate engineer is I said, okay, open it as a draft or even just tell me where the branch is, I’ll pull it down and I’ll do a private code review to start off with and catch anything that is obvious to me that might be a security issue or might just not quite work in the way you expect it to. Or there might just be a more. I love regular expressions. I overuse regular expressions. I’ve learned the hard way that no, it’s science is better just to substitute slice the string or something and figure out where you need looking for little bits like that, which gives them confidence when they do open the pull request. Okay. There’s nothing obvious that someone is going to immediately latch onto and tell them that they’re wrong. And if the project they’re opening the pull request request does that, I will be having a private conversation with them that that is not how you interact with a contributor. So that’s another approach that I take.

Alex: Cool. And I’m curious, do you find that you learn stuff from sponsoring your mentorship that like impacts your, you know, day.

SPEAKER_D: To day job immensely? I learn how to communicate a technical concept to someone who doesn’t have the same experience that I do. And I need to be reminded of that a lot funnier example from this intern. We were in our standup and I was talking about something I don’t remember it was. And I said yeah. And it turned into an epic yak shave, not realizing she had no idea what that meant. So she later told me, yeah, I had to ask someone else, what is she talking about? And it’s an example of there’s little bits of vocabulary that make no sense to someone who doesn’t have the same context. And, and that’s been very helpful for me in communicating things to stakeholders who don’t necessarily. I don’t like saying non technical. If you can use Excel, you’re technical. But Maybe with less of a coding background than I have. And that’s a key way to get business stakeholders in alignment with what I’m executing or what my team is executing on a technical level. So, yes, it helps a lot.

Nell: That’s interesting. We have challenges with terminology in our industry, both in terms of the jargon, things like the act shave, but also. So the technical, non technical distinction is not a bright line.

SPEAKER_D: No, not at all. I can’t do Salesforce programming, but I know a lot of business people who can do great. It’s like blood magic in Game of Thrones to me. But they can do amazing things with it, so. Yep.

Nell: Oh yeah, yeah. No, there’s all sorts of interesting. You know, Excel is a really great example, but there’s all sorts of DSLs like that that exist in the world that someone is basically a programmer if they can use them. They’re just not the same kind of programmer that other people are. Switching gears a little bit. There’s a couple questions that we try to ask everybody who comes on the show. And one of them is what are some of the resources that you would point other folks toward who are interested in technical leadership and moving into the staff plus and principal levels, especially if there’s books or blogs or people that you would, that you would point others toward.

SPEAKER_D: There’s two people and I’d point you to their Twitter accounts. They both do a lot of blogging. Speaking about principal engineer, the differences from being, you know, intermediate or Even senior level IC1 is Tanya Riley. Her Twitter account is whereistanya spelled T A N Y A. She was so helpful to me. So I, I mean, some of you might know, I was laid off from Mozilla last year. They laid off 25% of the company. And I got caught up in that and that intellectually I knew it had nothing to do with my abilities. When they have to make a cut that blunt, it can’t just. I happened to be working in an area where they decided they were no longer going to invest in it the way that they had been investing in it. So I knew that intellectually learning, knowing that emotionally took a lot longer. And in particular, I am freaking terrified of interviewing still. Ten plus years of experience. I hate it. And she took me through a non judgmental systems design interview reminding me how it worked and what people. And she’s been through a lot of them herself. What people will be looking for in a staff principal role in a system design interview. And I think that played a large, large part in me getting the role I got at Microsoft. Also, she has lots of good information about, you know, what does being a principal mean? How do you become a principal, particularly if you’re, you know, more of an underrepresented person. Tech. Highly recommend her.

Nell: The other one is fantastic.

SPEAKER_D: Yeah, we’re gonna have.

David: We’re gonna have her on the show at some point.

Nell: She’s fantastic.

David: We’re just trying to figure out when.

SPEAKER_D: Yep. And then the other is Sylvia Botros. I’m not sure if I’m saying her last name correctly, but her Twitter account is dbsmasher, I guess, for database Smasher. Also, lots of good blog posts, lots of good thoughts on Twitter, et cetera, on what it means to be a principal engineer. So highly recommend that Twitter account as well.

Nell: Awesome. Awesome.

Alex: So we have our last question, which is sort of tongue in cheek. How much time do you spend coding nowadays?

SPEAKER_D: It’s about 50.

Nell: 50.

Alex: 50. 50. Wow.

SPEAKER_D: Yeah. Which I realize is unusual for a principal engineer. And perhaps when, you know, if we get more headcount, there’s more senior intermediate engineers under me, there will be less. But right now it’s about 50, 50. And part of that is, again, I’m interfacing with community members who are doing contributions, and I do consider code review coding work.

Alex: Sure. That makes total sense.

Nell: Awesome. Well, Nell, thank you so much for taking the time with us today. It’s really been a pleasure.

SPEAKER_D: It’s been a pleasure, too. Thank you so much for having me.

David: That’s it. Thanks so much for listening to staff Eng. If you enjoyed today’s show, please consider adding a review on itunes, Spotify, or your podcaster of choice. It helps others find the show and is a really useful signal to us that folks are finding value in this.

Nell: So that we keep doing it.

Alex: You can find the notes from today’s episode at our website, podcast.staffenge.com the website also has our contact info. Please don’t be shy, Sam.