[00:00:05] SY: Welcome to the CodeNewbie Podcast where we talk to people on their coding journey in hopes of helping you on yours. I’m your host Saron, and today we’re talking about Technical Debt with Nina Zakharenko, Principal Cloud Developer Advocate at Microsoft.

[00:00:19] NZ: I mean, it was really slow and really error-prone. If text wasn’t in the right position that it expected, the whole thing would crash. And so I think that’s a great example of technical debt.

[00:00:30] SY: Nina talks about what causes technical debt, what can happen when it gets out of control, and how we can mitigate the accumulation of that debt after this.

[00:00:49] Heroku is a platform that enables developers to build, run, and operate applications entirely in the cloud. It streamlines development, allowing you to focus on your code, not your infrastructure. It also lets you use the most popular open source languages to build web apps. Also, you’re locked in to the service. So why not start building your apps today with Heroku?

[00:01:13] TwilioQuest is a desktop roleplaying game for Mac, Windows, and Linux to teach you real world developer skills. The TwilioQuest Program was created in secret to train an elite group of leaders to combat a shadowy organization known only as the Legacy Systems. Take up the tools of software development, become an operator, save the cloud. Download and play TwilioQuest for free at twilio.com/quest.

[00:01:40] DigitalOcean offers the simplest, most developer friendly cloud platform. It’s optimized to make managing and scaling apps easy with an intuitive API, multiple storage options, integrated firewalls, load balancers, and more. Get started on DigitalOcean for free with the free $100 credit at DO.co/codenewbie. That’s DO.co/codenewbie.

[00:02:05] When you need to focus on building, do you want to get bogged down by your database? MongoDB is an intuitive, flexible document database that lets you get to building. MongoDB’s document model is a natural way to represent data so you can focus on what matters. MongoDB Atlas is the best way to use MongoDB. It’s a global cloud database service that gives you all of the developer productivity of MongoDB, plus the added simplicity of a fully managed database service. You can get started free with MongoDB Atlas at mongodb.com/atlas.

[00:02:42] SY: Thank you so much for being here.

[00:02:44] NZ: Thanks for having me.

[00:02:45] SY: So how did you start your coding journey?

[00:02:47] NZ: It’s a bit of an embarrassing story, but I’ve always been interested in computers. And when I was around 12, I decided that there was a band out there that I really hated and I needed to tell people about it. So I had to make a website. That band was Hanson.

[00:03:08] SY: Okay. Wait. Why did you hate them so much?

[00:03:12] NZ: Oh, this is even more embarrassing. I’m actually blushing right now because I figured out that they weren’t girls and I felt tricked.

[00:03:19] SY: Oh no! You know what? That is fair. If I felt tricked, I would hate a band too. I’m okay with that. I’m okay with that reason. Okay. So you hated them so much that you felt that they deserved a site where you got to share your feelings about them.

[00:03:38] NZ: That’s right. Yeah. So I taught myself HTML, so I could make a GeoCities site, a Hanson hating website on GeoCities.

[00:03:48] SY: What kinds of things do you post on that site?

[00:03:50] NZ: Like really tiny, low resolution GIFs. I don’t even remember. It was ages ago. But that is what got me into computers and programming. So I guess, at the end, thank you, Hanson.

[00:04:05] SY: So how did you teach yourself HTML? How did you teach yourself the skills to do those GIFs and write that content?

[00:04:10] NZ: Yeah, I feel like back in the day it was pretty easy to just right click on a website and be the source.

[00:04:17] SY: Okay.

[00:04:17] NZ: And things were pretty straightforward and simple. It was before JavaScript was a big thing. So I would find sites that kind of looked like what I wanted and I would open the source and then just like poke around and teach myself.

[00:04:32] SY: So you got your little taste of HTML through this hate site and then what happened?

[00:04:37] NZ: That sounds horrible.

[00:04:39] SY: That does sound horrible. It’s not a hate site. It’s an anti-fan site, stuff like that.

[00:04:42] NZ: Yes.

[00:04:43] SY: So did you continue this interest in coding into high school?

[00:04:48] NZ: Yeah, a little bit. Like I was still interested in computers and I did a lot of reading. I spent a lot of time on IRC, but I didn’t really get into programming until I went to college.

[00:05:04] SY: Oh, okay. So what got you into coding then?

[00:05:06] NZ: I just kind of realized that computers were what I was passionate about and I couldn’t come up with anything else.

[00:05:15] SY: Okay. That’s fair. It really is incredible when you think about the big life decisions you have to make in college when you have little to no information on how to make those decisions. So it sounds like the process of elimination was kind of part of your decision to go into computers. There’s nothing else that you were into. Yeah.

[00:05:31] NZ: Yeah, exactly.

[00:05:32] SY: Okay. So you were interested in computer science. What was that experience like for you taking CS in college?

[00:05:38] NZ: It was a lot. I went to a public high school in the New York City Public High School system and we had some programming classes, but they weren’t great, and I never really, I don’t know, I felt like there was more that I was missing. All of the equipment that I ever used in school was always outdated. So I felt like I started with a disadvantage because a lot of the people who were in my courses had a lot more experience than I did and there was definitely a lot to work through, like my teachers were definitely biased against me. I would spend a lot of time in office hours or fighting for my grades, and I guess gave me a little bit of a taste of what the industry could be like.

[00:06:28] SY: You said that you’ve kind of felt like they were against you. Why was that?

[00:06:32] NZ: It was several teachers in several occasions, but at the time, I think I was in a class of about 200 and I was one of five women. So pretty abysmal statistics, and my teachers, I noticed were more likely to give partial credit to my male colleagues or they were more likely to believe in them versus me having to prove myself. Like I remember for a final project, I got a bad grade because my professor said my code never finished running and I had to go in there and sit in his office and run my code until it was done just to prove it to him and show him that like, “Here it is. You just kind of dismissed me prematurely.”

[00:07:17] SY: That must have been really frustrating.

[00:07:19] NZ: Yeah, it was. I don’t want it to be, but I think it still is because I hear a little bit of that frustration creeping into my voice as I talk about it.

[00:07:28] SY: So in that environment, what kept you going?

[00:07:31] NZ: I did make kind of a small group of friends that were awesome and really supportive. And then the more I learned, the more interested I became. So I was just kind of really motivated and proving everybody wrong.

[00:07:45] SY: That’s great. I mean, you had a little support system. That’s great.

[00:07:47] NZ: Those are folks that some of them I’m still friends with to this day.

[00:07:50] SY: Oh, that’s wonderful. So when you were going through all this, was there any point where you wanted to quit?

[00:07:57] NZ: Yeah, definitely, especially towards the end, I took an operating systems programming class that was probably the hardest class of my degree and we were supposed to work together with a partner and my partner just ditched, like he didn’t show up. He didn’t do any of the homework or any of the assignments. And so I had to go through this really hard class alone and the teacher was, he wasn’t very kind of kind or understanding, he was just like, “Well, this is kind of like real life and there’s nobody else to partner with you. So deal with it.”

[00:08:34] SY: And so when you were in these moments when you decided or at least thought, “Maybe this isn’t for me, maybe I don’t actually want to do this, “what got you back from that? What made you decide ultimately that you’re going to keep going?

[00:08:47] NZ: I think I’ve just kind of had this lifelong desire to prove people wrong. And so that desire has kept me going through tough moments when I would have otherwise quit.

[00:09:00] SY: So what kinds of things did you get to do with your CS skills when you were in college?

[00:09:06] NZ: We learned a lot of theories, how databases are structured, we learned about compilers, a lot of history, and I thought that I would need all of that knowledge when I graduated and it turns out I really didn’t.

[00:09:22] SY: Surprise!

[00:09:24] NZ: A lot of it helps and some of it has helped me maybe buss through problems, but you really don’t need as much of the theory as you imagine you might.

[00:09:35] SY: So when you were getting this degree, did you have a career in mind that you wanted to pursue?

[00:09:39] NZ: I did not. At first, I tried an internship doing kind of more of a tech support role because I thought maybe I didn’t want to sit in a cubicle all day every day. And after some misadventures, I realized that support wasn’t necessarily for me, but I didn’t have much guidance when I graduated. So I went through a few roles in industries that really were not a good fit.

[00:10:08] SY: And what did you land on? What was the thing that you found that maybe it was a good fit?

[00:10:13] NZ: So I started my career doing Enterprise Java development because that’s what I had learned in college. And the roles that were available for that type of skillset were kind of in bigger corporations, environments that were a lot more buttoned up. And I really enjoy having the opportunity to be creative. So a few years after college, I taught myself Python and that was kind of what changed my trajectory because it was a lot more fun. It had a really vibrant community, which I hadn’t found in Java at the time, and kind of re-sparked my desire to program and my interest in it.

[00:10:58] SY: You mentioned that you taught yourself Python. What tools did you use to learn?

[00:11:01] NZ: Yeah. So I was really lucky because at the time I had tried to teach myself Python while I was doing a job as a full time Java developer and my brain just… I don’t know, it was so conceptually different that I was having a really hard time doing both every day, and I learned about this program called, at the time it was called Hacker School, but now it’s called Recurse Center. It was the right time, the right place. I was lucky enough to be in a position where I quit my job. And so I went into this program, which was kind of like a writer’s retreat, but for programmers and spent three months of the summer teaching myself.

[00:11:45] SY: Yeah. That’s a great way to describe it. A writer’s retreat, but for coding. That’s very accurate from what I’ve heard. Yeah. So for folks who are interested in code, who are learning how to code, but they’re not really sure what career they want to pursue and where do they want to end up, what advice do you have for them?

[00:12:02] NZ: If you’re in a position to, I would say don’t do what I did and just take the first job that gave me an offer. Try to be in a position where you can kind of think it through a little bit more and maybe even interview in a few different sectors.

[00:12:19] SY: Good idea. Yeah.

[00:12:20] NZ: Yeah. It’s totally fine to interview for a job that you’re not crazy about just to see what the process is like, what the company is like. You might end up being surprised.

[00:12:47] TwilioQuest is a desktop roleplaying game for Mac, Windows, and Linux to teach you real world developer skills. Explore the Mysteries of the Pythonic Temple, the JavaScript Test Lab, and more all while learning the tools of software development with TwilioQuest. Become an operator, save the cloud. Download and play TwilioQuest for free at twilio.com/quest.

[00:13:12] No one wants to manage databases if they can avoid it. That’s why MongoDB made a MongoDB Atlas, a global cloud database service that runs on AWS, GCP, and Azure. You can deploy a fully managed MongoDB database in minutes with just a few clicks or API calls. MongoDB Atlas automates deployment, updates, scaling, and more so that you can focus on your application instead of taking care of your database. You can get started free at mongodb.com/atlas. If you’re already managing a MongoDB deployment, Atlas has a live migration service, so you can migrate it easily and with minimal downtime then get back to what matters. Stop managing your database and start using MongoDB Atlas.

[00:14:01] SY: So I want to talk to you about technical debt, which is the topic I don’t think we’ve covered yet on this show, and it’s something that you’ve talked about at conferences. You’ve spoken about technical debt. Can you explain to us what technical debt is?

[00:14:14] NZ: Technical debt is code or technical processes that kind of end up building up over time when the team is not able to invest in better practices like code quality testing, automation.

[00:14:31] SY: So what kinds of things lead to technical debt? How might I accumulate that debt?

[00:14:36] NZ: There’s a few different paths to it, but usually when a team is all about implementing features, usually there’s external pressure, maybe deadlines or project managers who just kind of want to see the new things and don’t set aside time for code maintenance. That’s usually when technical debt starts to rear its ugly head because as you build and build features and don’t take the time to clean up your codebase, you end up with parts of it just starting to crumble.

[00:15:10] SY: Can you give me an example of that? Like if I were to build a feature but not maintain it, what does it actually look like?

[00:15:19] NZ: One of my absolute favorites has to do from one of my first jobs. I spent a lot of time working in finance, so working at giant banks. And at the time, and I’m almost positive, but this is probably still the case, a lot of the banks ran software on mainframes. So I worked with COBOL developers not that long ago. The bankers in this kind of high net worth sector that were working with these really high value clients were starting to get frustrated with this mainframe system that they had to use because they didn’t have things like copy and paste.

[00:15:57] SY: Oh, okay.

[00:16:01] NZ: And so the engineering teams are like, “okay, they need this fancy new interface.” And instead of taking the time to fix the backend system or maybe move off of the mainframe because that was a really big and involved project, they just kind of decided to slap a new interface on top of the mainframe backend.

[00:16:26] SY: Yeah.

[00:16:27] NZ: And I mean, the process ended up being like really slow and really error-prone because basically like this new interface would send a command to the mainframe. The mainframe would take the arguments and then just print out a screen of text as output and so the new interface, but have to take that printed out screen and parse all of the elements out of it. I mean, it was really slow and really error-prone. If text wasn’t in the right position that it expected, the whole thing would crash. And so I think that’s a great example of technical debt because, I mean, the bankers got this fancy new interface and they hated it because it was really slow and really error-prone because the company didn’t invest in fixing the underlying problem. They just tried to add new features on top of it.

[00:17:18] SY: Okay. So if that was the wrong way to do it, what would have been the right way?

[00:17:23] NZ: I think it would have taken a more long-term investment to probably at least move some of the components off of the mainframe part by part, service by service because even back then, COBOL developers were not easy to find. It was becoming more and more of a specialized skill. So the pool of people who would be available to take on that kind of work was already diminishing.

[00:17:46] SY: And so moving it off of it would have removed that technical debt. How? Tell me a little more about that.

[00:17:53] NZ: Well, the system could have been faster. You might not have needed that intermediary step of feed input into the mainframe and then have it printed out as a text screen that had to be parsed, right? You can introduce more error checking or new security features. So that would have kind of fixed the underlying problem and then a new interface could have been added on.

[00:18:18] SY: Yeah, I mean, I’m a huge fan of testing. I think we’ve covered testing a couple of times on this show, and you mentioned not testing as a way to accumulate technical debt. And it reminds me of just being in a situation where you were so excited about feature building and you want to just like build up your app and give it all this functionality, and then you skip the tests, which, helps you get there faster, but then you have like all these bugs and all these issues that you could have prevented that didn’t really need to be there if only you had taken the time to write your tests. So that’s like one of the things I struggle with is remembering like, “No, tests are important. Tests are important. It helps you to avoid technical debt.”

[00:18:55] NZ: Yeah. Yeah. That’s exactly it. And I find that it’s a pitfall for a lot of new developers. One is not taking maintenance time and the time that it takes to write tests into account when you’re putting together estimates. So that’s super important when you’re estimating your work, it’s not just like, “Hey, how long is it going to take you to write this code?” But, “How long is it going to take you to write the code to document it, to write your test cases and do a little bit of cleanup depending on what codebase you’re working with?”

[00:19:26] SY: So the thing about most debt is that you usually don’t have to pay it off right away. You feel the burn later on. So I’m wondering about technical debt, how does it work? Do you start kind of paying the price immediately? Is it kind of a long time before we really have to think about it, have to worry about it? How does that work?

[00:19:43] NZ: It depends on tons of factors, the project, company culture, the experience level of the developers working on it, like you said like a lot of times new developers just get really excited and they just want to build the thing. So not that they don’t just necessarily estimate for it, but they don’t plan for that work either. So just like with financial debt, if you do find yourself working on a project that has a lot of technical debt, you want to figure out what debt has the highest interest and then pay it off first. So what is making your life miserable?

[00:20:22] SY: Because you will feel that misery.

[00:20:23] NZ: Yes.

[00:20:24] SY: Maybe not like a lot, but I think maybe it usually starts off kind of small. Is that fair to say?

[00:20:30] NZ: Yeah.

[00:20:31] SY: Yeah. So you talk about technical debt. You’ve given talks about that topic at conferences. What do you usually say? What do you share with the audience?

[00:20:40] NZ: Yeah, it is, hands down, one of my favorite talks to give because it ends up being like this weird group therapy, like I’ll talk about some of my experiences with technical debt. I’ll give suggestions for how you can solve spending the time to invest in your codebase to your management, what arguments you can make to really prove that it’s important. And this is the only talk that I give where people are just kind of like in the audience, just like, “Yeah, me too,” or, “That happened to me.” They’re just kind of nodding, smiling, laughing, crying. So it’s a roller coaster.

[00:21:20] SY: Wow! So what can I do? If my manager’s like, “We need to get those features out as soon as possible,” and I’m like, “Well, Nina said I need to watch out for technical debt.” What can I say? What do I do?

[00:21:32] NZ: So while I am an expert, unfortunately I don’t think most managers would be into the Nina said arguments. And fortunately, there have been a lot of case studies about good practices like code reviews done and on the codebases of large companies like Microsoft where there are papers and statistics and studies that you can point at to say, “Hey, this is proven to reduce bugs in large software systems.”

[00:22:03] SY: That’s pretty cool. I didn’t know research like that existed. So when we think about trying to avoid technical debt, what kinds of things can we do.

[00:22:12] NZ: There are a few things and some of them are easy to implement, some aren’t. I think one of the best things you can do for your project is have coding standards and coding guidelines that everyone on the team can follow because I don’t know where I picked up this quote from, but I really love it. I read that a codebase that’s worked on by a team should look like it was written by one developer.

[00:22:39] SY: Oh, I like that.

[00:22:40] NZ: Right? So you shouldn’t be able to look at a piece of code and be like, “Oh, I know for sure that Katie wrote that.”

[00:22:46] SY: So how do you accomplish that? Tell me more about that.

[00:22:49] NZ: Code or a style guideline is one of the best ways to do that. And then as a team are doing code reviews, then you can just be really objective and not say, “Hey, you’re doing this wrong,” or, “I don’t like this.” And instead say, “Hey, our style guide says that we should be writing our code this way. We should be documenting it this way and writing our tests like so.” That way everyone is following the same standard as they move forward.

[00:23:18] SY: What does a style guide or coding guide look like? What kinds of things or maybe some examples of things I might find in there?

[00:23:26] NZ: So for Python, there’s actually one that is built into the language. It’s called “PEP 8”, basically Proposal #8, and it’s guidelines for how your code should be formatted. For example, how many new lines you should have between a class and a function, guidelines for the spacing around symbols like the equal sign. And then because all of those rules are written out, you can have tools called linters, basically compare your code to that style suggestion automatically and then point out any discrepancies.

[00:24:04] SY: Interesting. Okay. So when I think about how many lines or how many spaces that should be, it sounds kind of aesthetic, I guess, like I’m having a hard time seeing how that would help me avoid technical debt. Can you make that connection for me?

[00:24:17] NZ: I think for Python it is pretty aesthetic and I think the difference is Python is a language, so there are no curly braces, each line is its own statement, and then the control blocks are differentiated by how many spaces they have in front of them. So that aesthetic is kind of important. If you’re working on a large codebase or you’re looking at a lot of Python code, your brain kind of pretty quickly learns where to look for things. Like having done Python for many years, I can now instantly look at a Python file and know if it follows this PEP 8 standard or not. And if it doesn’t, it bothers me. So that’s kind of just one example for one language, but style guides don’t necessarily have to be focused just on the style. They can cover broader things like how your tests should be written, how should they be structured, and then there’s a lot of really good style guides available already that you can use as a base. For example, Google has great style guides available for Python. And I believe JavaScript as well, and probably other languages.

[00:25:26] SY: So we’ve got style guides as a resource, as a way to help us avoid technical debt. What other things can we do?

[00:25:32] NZ: Tests.

[00:25:34] SY: Tests. Tell me about tests.

[00:25:35] NZ: There’s kind of two parts to tests. One is that you have to write them.

[00:25:40] SY: That’s true.

[00:25:42] NZ: I guess one and a half is that they have to pass.

[00:25:45] SY: That’s true too. Yeah.

[00:25:46] NZ: But the second part is that you have to run them or they’re not useful. So by testing your code, you’re building up your confidence that the code that you wrote actually works and it works as expected, and you’re also doing a bit of future proofing because if you’re changing the code, you’re changing how a method works, what’s being passed into it and your tests that you wrote around that code break, that’s great, right? Because now you know what you need to do to fix those tests and you can kind of have that process of writing and fixing your code and fixing your tests and increasing your confidence that you’re doing the right thing. And then if you do have this solid test suite and you have that confidence, you can then hook that into your version control or your deployment process. So maybe every time you open a new PR on the server, the test suite runs, maybe it takes too long to run on your personal machine, but if you run it on a beefy server, you can see any failing tests across lots of modules in your system, and then you kind of know what went wrong and now you’re not pushing broken code up to master and up to production.

[00:26:56] SY: Okay. So we’ve got a style guide. We’ve got testing. Let’s do one more. What’s one more thing we can do to avoid technical debt.?

[00:27:03] NZ: Code review.

[00:27:04] SY: All right. Tell me about code reviews.

[00:27:06] NZ: Code reviews are a favorite topic of mine. I also give a talk about code reviews that I really enjoy giving because for those of us who’ve worked as developers for a long time, or just like, “Oh, yeah, code reviews. Everybody does that, right?” Like we kind of get so used to some of the processes that we don’t realize that there are new people entering the fields and the industry all the time. There are new companies forming new teams and not everyone kind of has that institutionalized knowledge of what they should be doing to have a good healthy development environment or developing team. It’s not something that everyone just knows about. And a healthy code review culture is awesome for both senior engineers and junior ones. It’s a way to share information, learn new things, teach new things, adhere to a style guide and be friendly. But if you kind of work with people who don’t have the right attitude, code reviews can also become this scary, fearful thing.

[00:28:11] SY: That’s true.

[00:28:12] NZ: Yeah.

[00:28:13] SY: It can be really intimidating, especially if you’re not used to doing them, especially when you have to do them in front of everyone.

[00:28:17] NZ: Yeah. Right.

[00:28:18] SY: Yeah. Those are going to be really scary.

[00:28:20] NZ: So it’s not just about doing the code reviews, but about building a really good culture around them where they’re not scary and you’re not using it as an opportunity to embarrass other people or criticize them for what they don’t know, even if it’s something that you think is really simple or straightforward.

[00:28:47] SY: Coming up next, Nina talks about who the usual culprits are of technical debt and her work as principal cloud developer advocate at Microsoft after this. Over nine million apps have been created and ran on Heroku’s cloud service. It scales and grows with you from free apps to enterprise apps, supporting things at enterprise scale. It also manages over two million data stores and makes over 175 add-on services available. Also, make sure to check out their podcast, Code[ish], which explores code, technology, tools, tips, and the life of the developer. Find it at heroku.com/podcast.

[00:29:39] With DigitalOcean’s cloud infrastructure, you’ll be able to build faster and scale easier from predicting pricing, to flexible configurations, to world-class customer support. You’ll get access to all the infrastructure services you need to grow. Plus, DigitalOcean’s community provides over 2,000 tutorials to help you stay up to date with the latest open source software, languages and frameworks. Get started on DigitalOcean for free with a free $100 credit at DO.co/codenewbie. That’s DO.co/codenewbie. So I want to talk a little bit about experience and how it relates to technical debt as new developers, as people maybe new to the team, new to the world of building production ready code. Does the technical debt tend to come from us? Does it tend to happen or be more likely to be caused by those of us who are code newbies?

[00:30:38] NZ: No.

[00:30:39] SY: Okay. That’s very, very short. Okay. Tell me more.

[00:30:43] NZ: I mean, there are definitely things that code newbies can do that contribute just like being overly excited and not focusing on the maintenance tasks, but some of the worst technical debt that I’ve seen has been perpetuated by people who have been doing this for a really long time, stubborn folks who have a better than now complex or people who have a big ego and a lot of insecurity. It’s really caused by everyone.

[00:31:15] SY: Okay. Great. So we are all the problem. Wonderful. That is great to hear

[00:31:20] NZ: But we can work together to fix it.

[00:31:21] SY: There we go. So if you’re comfortable sharing, I would love to hear, what has been your worst, your most frustrating experience dealing with technical debt?

[00:31:31] NZ: It’s hard to pick just one. Yeah. I think my most frustrating one, like one where I was just kind of pulling out my hair was I worked on a codebase that was a tire fire, like for a few months and it was really stressful, like basically every time we would deploy to production, somebody would get woken up in the middle of the night.

[00:31:54] SY: Oh.

[00:31:55] NZ: Yeah.

[00:31:56] SY: Wow!

[00:31:57] SY: And as I was exploring the codebase and learning more about it, I found this feature that was maybe three quarters of the way implemented, but then we decided it wasn’t a priority anymore. So the developer who worked on it, she was actually considered a senior engineer, so not a code newbie. She commented all of it out and then just left it in the codebase.

[00:32:20] SY: Oh!

[00:32:21] NZ: Yeah. And the code had kept evolving. New features had been added. So even if you uncommonly did all of it at the time that I found it, it’s not like it would have worked out of the box. And so we have Git and Version Control and it’s actually really easy to find deleted code in Git. You have this Git history. It’s not gone forever. So I tried to coax her into deleting all the comments and told her I could show her how she could pull those up and get again if she wanted to, but she was very adamant that the commented out code stayed in. And so that was one battle that wasn’t worth fighting, but it was really frustrating.

[00:33:03] SY: And how did that experience affect how you thought about technical debt or did it affect how you thought about technical debt?

[00:33:10] NZ: It did. Yeah. Like sometimes a few bad apples can really do a lot of damage to a codebase. And so the more process you have, style guides, maybe even a team guide to get, maybe how to look for deleted code or just a style guide that says, “Commented out code can’t be checked in.” The more process you have, the less personal it is between two people. So it’s not just I think this and you think that. It’s like, “Hey, we came up with these guidelines together and so we have to follow them.”

[00:33:49] SY: So I want to switch topics for a bit and talk about your role at Microsoft because I think it’s just so interesting. You are a principal cloud developer advocate. What does that mean? What do you do?

[00:33:59] NZ: Yeah. I’ve been at Microsoft for about two years now, and I wear a lot of hats. It’s been an interesting ride. I can definitely say that my job has never really been the same. I don’t do many of the same activities day to day. So I have a lot of things to choose from. I create content. I work with the Python teams at Microsoft that work on our cloud computing service, Azure, and the Python extension for VS Code, which not a lot of folks know, is actually built in-house by a team at Microsoft, even though it is open source. So I work with them to help them improve their products and build products that Python developers want to use and would love to use. I’m also heavily involved in communities. So for the past two years and now this third, I’m pretty heavily involved with Microsoft’s presence at PyCon US, which is the biggest Python conference. And so I kind of help guide folks into putting together an experience that attendees and the Python community are really going to like and enjoy. And that also helps the folks that are attending from Microsoft to have the best experience and talk to people who are using their products and get feedback.

[00:35:20] SY: So do you get to do much coding?

[00:35:22] NZ: I do. There was a time when that fell to the back burner and I realized it was making me really unhappy. So over the past few months, I’ve been carving aside more time for writing code and contributing to open source because I realized the reason that I am good at this advocacy job is because I have my experience to draw on and because I worked on code and production. And so to lose that has been a little bit challenging, but I still really kind of like and appreciate my job and I like how much impact I can have. So I’ve learned that it’s on me to have a good balance between activity is like writing or going to events, speaking at events, and keeping my technical skills sharp and up to date.

[00:36:15] SY: So the idea of being an advocate I think is something that a lot of folks in our community are interested in because it involves coding, some speaking, community building, writing. It involves so many different skills that are usually a lot of communication skills and then also technical skills as well. But I feel like it’s kind of one of those tricky jobs to actually get into. So if I wanted to be an advocate, what would I do? How do I end up in a role like that?

[00:36:40] NZ: It was a little tricky. I will say that it’s not quite as glamorous as people make it out to seem. Yeah. I mean, going to events and meeting lots of folks from the community is awesome, but traveling a lot is just hard. It’s hard mentally. It’s hard on your body. It’s hard being away from home and family and friends and loved ones, and of course you have to balance all of those activities with staying sharp in tech. So it’s not for everyone, but the way that I broke into it at least was maybe a few years after I had started getting coding jobs. Basically a bunch of my friends very kindly pushed me into giving a lightning talk at a conference and it was only five minutes and I was like petrified. I was shaking so hard that you could see it on camera. There is a recording of it, and I didn’t think it was something I could do and I did it. I said what I wanted to say, and maybe an hour later I realized I was still clenching my fists. And so it’s like, “Okay, take a deep breath. You can relax. You thought you were going to die, but you didn’t actually die.” That was the worst thing that could happen and it didn’t. So I am not a natural speaker at all, but I kind of really pushed myself to give more conference talks with practice and I feel like giving talks and meeting community members and kind of being a part of that wholesome ecosystem was what helped me eventually decide that I wanted to move into advocacy. I already had kind of that foundation in place.

[00:38:29] SY: Now at the end of every episode, we ask our guests to fill in the blanks of some very important questions. Nina, are you ready to fill in the blanks?

[00:38:38] NZ: I am.

[00:38:39] SY: Number one, worst advice I’ve ever received is?

[00:38:43] NZ: There are two things. One is my high school guidance counselor told me to save my money on college applications because I would never get in.

[00:38:52] SY: Oh, wow! Holy smokes. Aren’t they the ones that are supposed to be pushing you to go to college.

[00:38:59] NZ: Right. Yeah.

[00:39:00] SY: Wow!

[00:39:01] NZ: The second one was from a family friend. I went to college kind of around the time of the last .com bust, boom, whatever that one’s called.

[00:39:10] SY: They came together. Yeah.

[00:39:11] NZ: Yeah, and so a family friend told me to not focus on a degree in computers because that was on the out and out and my skills wouldn’t be valuable.

[00:39:21] SY: That’s at least reasonable if you lived through the bust.

[00:39:26] NZ: Yeah. I didn’t listen to them.

[00:39:28] SY: Yeah. I’m very glad you didn’t. Number two, best advice I’ve ever received is?

[00:39:34] NZ: It was around giving talks and public speaking. I kind of want to pass on that advice. I think people who are new to the industry think that they don’t have anything to share, but I think that’s not true. Like everybody has something to share, no matter how much you know or you don’t know. A lot of times how you approach learning something is really interesting or the hurdles that you might have faced in learning a topic. So don’t be down on yourself. I think everyone has something interesting to talk about and to help. A few months ago, I wrote a seven-part series on giving technical talks.

[00:40:13] SY: Oh, cool.

[00:40:14] NZ: Yeah, that’s on my medium. So everything from picking a conference, to writing a CFP, to preparing and presenting.

[00:40:22] SY: That’s so helpful. Yeah.

[00:40:23] NZ: So if that’s something that folks are interested in, I’d love to share that resource.

[00:40:27] SY: Yeah, absolutely. We’ll put that in the show notes as well. Number three, my first coding project was about?

[00:40:33] NZ: Oh, you already know this one.

[00:40:35] SY: I do know this one. This is the Hanson one. Oh man!

[00:40:38] NZ: My Hanson, you called it an anti-fan site.

[00:40:42] SY: Yes.

[00:40:42] NZ: Yeah. I think I’ll accept that.

[00:40:44] SY: Your Hanson anti-fan site. All right. Number four, one thing I wish I knew when I first started to code is?

[00:40:51] NZ: I wish I knew about community and meet ups and friendly folks. I didn’t know about any of that. I didn’t really know about open source, and it wasn’t until I started getting into Python that I started exploring more of those things, and it’s been such a fundamental part of keeping me in tech in general and helping me realize that coding and software and tech doesn’t have to be boring and it doesn’t have to be solitary.

[00:41:22] SY: Love that. Well, thank you again so much, Nina, for joining us.

[00:41:25] NZ: Thank you so much for having me. This is great.

[00:41:35] SY: This show is produced and mixed by Levi Sharpe. You can reach out to us on Twitter at CodeNewbies or send me an email, hello@codenewbie.org. Join us for our weekly Twitter chats. We’ve got our Wednesday chats at 9 P.M. Eastern Time and our weekly coding check-in every Sunday at 2 P.M. Eastern Time. For more info on the podcast, check out www.codenewbie.org/podcast. Thanks for listening. See you next week.