[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 demonstrating curiosity kindly with Matt Newkirk, Engineering Director at Etsy.

[00:00:21] MN: Developers demonstrating curiosity helps them build better things. It also helps in terms of collaboration and communication because so much of the job is about learning and learning from each other, and part of that is about learning how to ask each other for help and to ask each other for more insight. And how we demonstrate curiosity is a large part of that.

[00:00:43] SY: Matt talks about his coding journey, flunking out of high school and college to then go back to college and graduate with a computer science degree. He talks about his current role as engineering director at Etsy and leadership tips he’s picked up along the way and currently implements after this.

[MUSIC BREAK]

[00:01:04] SY: Thank you so much for being here.

[00:01:06] MN: Thanks for having me. It’s a real pleasure to be here.

[00:01:08] SY: So Matt, you currently have an incredible role as engineering director at Etsy, which sounds very important, very prestigious. But let’s take a step back. I’d love to learn about how you got your start in coding.

[00:01:22] MN: Yeah. My dad was a software engineer. Growing up, we had computers around the house and an Apple IIc was the first computer that I had in the house and did a lot of very basic games on that. And then over time, I started to do a lot of writing with word processors, and I didn’t really understand programming as a job for me. But when I was a teenager, I started to play these online games and I was playing one on AOL and it was great, but it was also expensive. And because I was a teenager with no money, I was not able to keep playing that. But a friend of mine mentioned to me that, “Hey, there are these things called MUDs, Multi-User Dungeon, and basically they’re free versions of the game that I’ve been paying for. And they were made by volunteers and there’s like tons of them. But I started playing this one MUD in particular that was Lord of the Rings based, and it was also created by a few people in college. And over time, they found actually a few hundred people that were regularly playing. And in order to scale themselves up, they started letting players volunteer to write for the game. And part of that was writing content, part of that was writing code. And so I became one of the coders for that game when I was almost 16. In that world, you started off in the newbie team and you had this newbie project, which was really anything you wanted, but you had to propose it, which was really a couple of page ReadMe text file. All this development happened in this game, which was all on Telnet. So I had a Telnet client and everything happened in that. And over time, I learned a lot more about software development through this volunteer opportunity., learning about quality control, learning about team management and distributed work. This was back before we had really even VoIP. There wasn’t really video chat or anything like that. So most of our chat happened in the game in these channels that were kind of like Discord or Slack or bulletin boards or an email. So I was working with people who are all over the world trying to build mostly our own separate little parts of this world and trying to make it into this coherent game. And I did that for like 15 or 16 years on and off before I realized like, “Oh, I could actually make money doing this,” paying kind of a job.

[00:04:05] SY: Wow!

[00:04:06] MN: But I learned a ton about quality through that opportunity and that turned into some contract quality assurance jobs in college. And when I finally tried to start my career at 30, I got my bachelor’s degree at 29 in computer science. I was not good at school, or at least I hadn’t figured out how to have the right coping mechanisms to help me get through it. So when I finally started my career, the job that I could get was as a quality assurance analyst at Electronic Arts for The Sims, and I ended up working on a team that was actually a web team within this game company. And because I had all this experience in quality assurance and because of the state of the project, I had this extra time and I told the team, “You know, I can write code if you have any things that I can help with.” And they took me up on it. And I was really lucky and privileged to have a team that gave me the opportunity to do more and they helped me figure out how to do a lot more automated testing, selenium testing, all of that, and then from there helped me figure out how to set up like AWS instances at a time where that was still feeling pretty new so that they could automatically test their code every time they push a new revision. And then from there taught me how to build a front end to manage all of that as well. And all of that experience led me to my first paid engineering job. And my official title was Quality Engineer for an education technology company. And that job was really interesting. It was still a relatively small company when I joined, and I was the only person focused on quality. And as a result, I was also focused a lot on just how things worked day to day. And so I ended up building a lot of kind of observability tools for the company. I ended up teaching a lot of engineers how to write unit tests, which meant I also had to learn more about how to write unit tests and build out their entire kind of CI system. At the time, the company, if I remember correctly, was deploying like once a week on a Saturday at midnight and had something like seven unit tests. And by the time I was done, we were running tests against every build, and I can’t remember the exact code coverage, but it was much, much higher, especially for a new code. And all of that was really interesting and gave me an opportunity to look at kind of the broad side of the code. But I also, because I was the only quality engineer, didn’t do a lot of things the way that I would recommend other people do them. I didn’t have as much of the kind of team collaborative peer programming code review kind of style in mind, and I didn’t really understand how to collaborate with folks as well as I do now at least. But all of that did teach me a little bit more about how to scale myself and an opportunity came to create a quality assurance team at the company. And I was asked if I would like to be a QA manager and head that team. And I had no idea what my career growth was going to look like as a quality engineer. And so I said, “Sure, let’s try it.” And it was really hard and I did a lot of things wrong. But I learned a lot along the way and I got to work with some really great people. I built up a couple of teams and got to see individuals become leaders of those teams. And all of that helped me see that where I found the most value wasn’t in writing code to solve specific problems, but was helping other people figure out how to solve their problems. So from there, my next job was as an engineering manager at Etsy.

[00:08:05] SY: And that’s where you are today. So I find it interesting that you’ve been in the tech space for quite some time, but how old were you when you first got your engineering job?

[00:08:17] MN: I think like 31.

[00:08:19] SY: Thirty-one, okay. So you’ve been in the space in the world and the industry for quite some time, but the first engineering job came at 31. Tell me a little bit about this computer science degree that came a little bit later in life. You went to school first. Didn’t quite work out. Decided to go back. And I think this is such an important point because so many people in our community are trying to figure out, “Do I need a computer science degree? Should I go back to school? Should I just keep kind of going, learning to code on my own journey?” So tell me about the decision that led to you going back to school.

[00:08:54] MN: Yeah. I always felt this desire to be creative, but I didn’t really understand how to succeed. And I learned very late in life that I actually have ADHD, and looking back, it helps explain like why I flunked out of high school and why I had such a hard time with so many classes. But part of the reason that I wanted to get a degree was because I still felt this stigma of not having completed anything. I spent most of my time following these creative pursuits that didn’t really end up going anywhere. I made several games on my own that never left alpha. I wrote a draft of a novel that I never went back and edited, and I just felt like I need to complete something. And after kind of flunking out of four years of community college, I thought I needed some sort of bootstrapped way to succeed, and so I did end up going to Heald College, which was a for-profit associate’s degree program and was able to test out of enough classes to finish in one year. And so I got an associate’s degree in computer technology, which looking back was a mix of things like public speaking class and a lot of math classes and a very small amount of programming, a lot more focus on hardware, like understanding which IR to use.

[00:10:27] SY: Like how computers work?

[00:10:28] MN: Yeah. It was very like help desk, late ‘90s desk.

[00:10:35] SY: Oh, okay.

[00:10:36] MN: I was able to get an A plus certificate.

[00:10:39] SY: Nice!

[00:10:40] MN: Based on my knowledge there, but I didn’t end up really using that associate’s degree, but it did help me understand that I could focus on something and succeed. If I tried hard enough, I could will my way through this thing. And so I did that in night school while working at a pizza place. And I think part of it too was I didn’t want to keep working at pizza places. I felt like there was more that I wanted to do and I just wanted to do something more. So I took a couple of years off. My significant other went to medical school in the Caribbean and I followed and spent that time working on that MUD in my copious free time. And I decided that when we moved back to the States, I would restart my academic career. I knew that we were going to be in New York, so I looked at the curriculums for the different state schools and I chose Stony Brook. And honestly, Stony Brook was a great program for me. The only challenge was it turned out that we were living in the southwest most corner of Brooklyn, and so it was like a three-and-a-half-hour train ride or a two-and-a-half-hour car ride, and I absolutely do not recommend long commutes for either work or school. It is very disincentivizing. But I did manage to learn enough about programming that I could see where some of my earlier experience came in handy and also could see a lot more of where my lack of math experience was really holding me back. So I found myself still struggling in those classes, but I really wanted to just get through and I was really just aiming for that piece of paper to replace the lack of the high school diploma. I did end up getting a GED, but I wanted to see some more completion.

[00:12:33] SY: How do you feel like your career changed if it did because of your computer science degree? Did you feel like you had more opportunities than you would have otherwise? Do you feel like when you look back at where you are today and how you got here, do you feel like you would’ve still been able to get here if you did not have that computer science degree?

[00:12:55] MN: You know, it’s a hard question. I ended up transferring to the University of Michigan in Flint, and so I did two years in Stony Brook and two years in Flint. I believe that I got my quality engineer job, that second job in the industry and the first paid as an engineer job, because of the University of Michigan that was sitting on my resume. It didn’t matter that it wasn’t Ann Arbor, although I think that that’s what an assumption was. I think it definitely helped open that door and helped me get that interview. I’d say it’s a hard question because I think now in 2022, I really hope that there isn’t as much schools snobbery and using universities as this really important benchmark because I’ve worked with so many people that came through different bootcamps and have these second careers. And I would not be able to tell you like who went to college for this and who went through one of these programs and tell you who did what because, honestly, there are so many pluses to not going through the university program. And I really hope that when I’m talking to somebody and they ask like, “Should I get this degree or not?” It’s really tough. I think that it will open some doors, but I’m hoping that there are enough other doors open that it’s not as important. And I think that focusing on what’s best for your interests and your circumstances is more important. It’s kind of the same when I have somebody who has an intern and they have an offer to come back as a full-time employee. Should they take that or should they go back to school and get that master’s program? And the answer I give is, how much are you interested in what you’re going to learn in that master’s program? And how exclusive is that information to that program? Because we learn a lot on the job. And if you can do that and get paid at the same time and not accrue more debt, you might as well because it all helps with that lifetime earning potential. It does still end up being a very personal decision. And I wouldn’t steer people away from university programs, but I don’t know that a university program is required to move forward. But I say that with the belief that it did help me.

[00:15:12] SY: That feels very in line with conversations I’ve had with people who’ve said, “I don’t think it’s necessary today, but it helped me when I was coming up. It helped me kind of on my own journey.” So that kind of resonates with me. I’m wondering if you have any advice, specifically speaking as a leader yourself, as an engineering director yourself, I’m assuming you’ve probably looked at your fair share of resumes and done some hiring yourself. I’m wondering what advice do you have for people who are trying to make that decision of today, of bootcamp, no bootcamp kind of learning with free resources online, going back to school for a year, a couple of years? How do you help people make that decision knowing what you look for when you’re the one doing the hiring at Etsy and what other engineering directors might be looking for as well?

[00:16:07] MN: Yeah. First, I want to say on today’s podcast, I’m not representing Etsy officially. So this is really my take on it. And I can’t speak for other Etsy hiring managers. But when I’m looking at candidates, I try to have as little bias in my selection criteria as possible. We have a career ladder, which is posted publicly and we try to map up all of our interview criteria to that so that we can make really good decisions. And so ultimately, it doesn’t come down to, “Did you take this class or not?” It comes down to, “Are you able to problem solve? Are you able to communicate how you’re problem solving?” A lot of it is communication and a lot of it is being able to problem solve sometimes in relatively short periods of time and not always needing to get the answer, but just being able to step forward. And I think when it comes down to what to do in order to move ahead in these processes, I think it’s being able to understand enough about algorithms that you can problem solve real code. Like I don’t ask people to reverse red-black trees. I don’t remember what that means actually. I think there’s definitely a limit to the amount of algorithmic practice stuff that’s necessary, but I think being able to play with putting webpages together and being able to work with like toy problems, all of that is really helpful because to an extent that’s kind of what the real work is, especially in entry level positions. And being able to talk about that is important. Feeling confident enough in that kind of work is important.

[00:17:57] SY: Yeah. Those other transferable skills are more important than literally having the degree.

[00:18:02] MN: Yeah.

[00:18:03] SY: At least, we hope so, depending on where you work and who’s doing the hiring.

[00:18:08] MN: Yeah. I think that there are all these books and plenty of like HackerRank questions and all kinds of things that are dedicated to how can you sort of provide rote answers to some pretty honestly boring questions.

[00:18:24] SY: Yeah.

[00:18:24] MN: I wouldn’t spend a lot of time on that. I think understanding some of it is important, but ultimately what’s more important is being able to answer questions, answer problems like as much as you can bring it back to like user value is important.

[MUSIC BREAK]

[00:18:52] SY: So at Etsy, you say that you learn to demonstrate curiosity kindly in a productive way. I’m very, very interested by what that means. What does it mean to demonstrate curiosity kindly?

[00:19:04] MN: Yeah. I’m glad we have the chance to talk about this. Effectively, what I’ve learned is a lot of people have a lot of curiosity and sometimes really intense curiosity. And I know from my own experience it can be easy to express that in a really judgmental, unproductive way that doesn’t help at all and actually hurts a lot. I think like a toy example is there’s some announcement and let’s say the announcement is that lunch will only be served on Tuesdays going forward. There can be an initial response of like, “Only Tuesdays? But what am I going to eat on Thursdays now?” And just this intensity of the unfairness of this change and this loss and this immediate grief around it, and I think I have felt and observed a couple of different kind of responses. The first is, “How dare we lose this opportunity?” Everything is going well. How can we lose this? And honestly, I think that the answers that come out of that are usually not the answers that are the most helpful. I think it can often be like, “Well, these are different budgets. Other things don’t quite equal each other out. It’s hard to draw the connections.” And I think the more kind question is like, “Oh, can you help me better understand like the decision making that led into this? What are the factors that determine how many days of the week we have lunch? What are all the other things that are happening?” And I think that those kinds of questions tend to lead to better responses for a lot of reasons. First, it gets a little bit more to understanding the fundamental system at play because if you don’t understand that, it’s really hard for you to understand the context of any decision or whether a decision is good or bad. But also, I think asking that question doesn’t imply a judgment that the decision was bad, that the decision maker was bad or that they should feel bad. And I think that when you ask questions in a more open and calm and kind way, it allows more room for the longer meandering answer, which often happens. It can be really hard to get to that meander-y answer, especially if there’s just a lot of complexity in some system. If the way that you ask a question feels like you’ve just punched somebody in the face or insulted them, they’re not going to want to talk to you for an hour, let alone one minute. Ultimately, there are a lot of environments and I’m really happy to work in one where it is safe to ask really kind questions and demonstrate genuine curiosity. And also it’s really helpful when you do that in a way that feels helpful and kind in inviting.

[00:22:07] SY: And how do you think curiosity plays into the role of a developer?

[00:22:11] MN: I think curiosity is maybe one of the most important skills for a developer. Curious, meaning like not satisfied with information that they’ve been given, but really trying to understand the deeper meaning. And when I look at the successful developers that I’ve worked with, I see curiosity coming through at every step of the way from, “Here is a problem that we’re trying to solve,” and curiosity about, “Why is this problem important? Why is it the most important right now? What are the factors that lead to that being important? What are the factors that might lead us to solve it? How do we understand the users and what their needs are and what their behaviors are? And then how do we understand our technical systems and their constraints and all of those requirements? And how do we understand our own business requirements and the time that we have available to put into it?” And all of that curiosity is required to deliver something that is going to be a little bit more robust than just doing the exact specification that’s handed to them. If there’s enough detail in a request, it’s relatively simple to deliver exactly that. But when you find out, “Oh, this doesn’t support this edge case,” or, “Oh, there’s this very similar request that is almost identical. Can this support this?” “Well, no, we have to reimplement the entire system for that other thing.” I think developers demonstrating curiosity helps them build better things in general, and I think it also helps in terms of collaboration and communication because so much of the job is about learning and learning from each other, and part of that is about learning how to ask each other for help and to ask each other for more insight and how we demonstrate curiosity is a large part of that.

[00:24:11] SY: So one thing that’s really interesting that you just said is how you describe curiosity as a skill, and I guess in my head, I never thought of curiosity in that way. I always thought of curiosity as, I don’t know, maybe like a personality trait. You either are curious or you’re not. That’s just kind of the way I’ve always thought of it. So it’s interesting that you think of it as a skill. Do you feel like it’s something that people can develop, can get better at? Can people become more curious? And if so, how do you develop that skill, that muscle?

[00:24:42] MN: I hope it’s a skill.

[00:24:45] SY: Okay., Fair.

[00:24:47] MN: I hope it’s a skill because I think it is one of those things that, depending on the time and the moment, I’ve definitely had different levels of it. But I think it is something that you can learn and I think you learn it through different behaviors. And I think about it in a developer’s role in kind of two sides of the job. One is learning new information so that you can complete your task. And that is like, “Hey, what’s the right class for me to work to call here? Or what’s the right method for me to call? Where do I find the data in the database that’s pertinent here?” And I think figuring out how to ask those questions in a way that isn’t how exactly do I do my job step by step, that is something that there’s a progression as you grow in your career. And I think on the flip side is as somebody demonstrating leadership. And by that, I don’t mean manager. I just mean a member of the team who has a little more information than somebody else. I think it becomes really important to learn how to demonstrate curiosity with how to help those other folks. I’ve definitely worked with engineers whose immediate response was to deliver a solution like, “Hey, I’m trying to solve this problem. How do I do it?” “Here is a solution. Here you go. You can look at my solution and learn.” And that doesn’t work in a lot of cases. But I think figuring out how much information do you need, how can I deliver this information effectively, how do I give you just enough and then leave the door open for you to ask for more detail, I think all of that is an important skill too, for a coach, for a mentor, for a manager as well, but I think especially important for anybody who isn’t in their first job in their career.

[00:26:44] SY: So you now manage a team of engineers, which means that you get to really think about how to cultivate curiosity and how to cultivate people’s skills and how to make sure they’re growing. What are some strategies that you’ve learned along the way that has helped people you’ve worked with become the best developer that they can become and really grow in their skills?

[00:27:07] MN: Yeah. One of the things that’s helped me is I actually don’t tend to have the direct technical domain expertise that my engineers have. I learned a lot with this MUD, which was a type list variant of C. I professionally did a lot of work in Java, and I work at a company that mostly does PHP and other things. So I think part of it is I have to rely on their domain expertise. And part of that means asking a lot of questions and some of those questions involve, “How are you thinking about how this will scale or perform? How are you thinking about these different risks?” And when individuals need help with something, helping them tell me what specific help they want, like I think a goal of, I want to be better at programming is too broad and even I want to be better at JavaScript is too broad, but learning more about like, I want to learn more about asynchronous calls or I want to work more with our databases or I want to work more with dynamic front-end work, like those specific areas make it easier for me to help them find the people with that domain expertise to help them. And part of it is just using my curiosity and theirs to figure out what specifically do they need. So some of that is modeling and asking lots and lots of questions, knowing that over time they’ll proactively ask themselves those questions and provide some of that information. And part of it is just knowing that ultimately they are going to be more informed about a lot of things than I am. And so I’m not there to tell them what they did wrong. I’m there to help them kind of figure out how they can be most successful.

[00:29:05] SY: Coming up next, Matt talks about how he feels about the idea of a single programmer, peer one-on-ones, and advice for people on their coding journey after this.

[MUSIC BREAK]

[00:29:26] SY: I know that for new developers, one of the struggles is figuring out what they should learn and specifically how much they should learn, meaning should I learn a little bit about a bunch of different topics? Should I go all in on one particular thing? And I know that you are very opposed to this idea of a single programmer being able to do it all, that that is flawed.

[00:29:49] MN: Yeah.

[00:29:50] SY: Can you elaborate a little bit on that and how that might translate to advice on how someone can kind of outline and decide their own learning journey, their own curriculum so they don’t feel all this pressure to do it all and to know it all?

[00:30:07] MN: Yeah. I don’t love the idea that one person is required to know everything, and that’s part of why we try to work with teams. And there are business models where you’re the sole kind of consultant for a business and are doing everything yourself. And I know many people who have done that successfully. But I think it also is much harder and I think those folks also have to find other resources to help fill in the gaps in an ongoing basis. In the team driven development that I’ve really come to love, I think it’s more important to be able to learn quickly. And so most of the folks that I work with have a pretty broad ability to figure stuff out, meaning I mostly work with full stack developers. I think full stack can mean a lot of things, and realistically, the stack gets so large that nobody is entirely fluent across the entire stack.

[00:31:05] SY: Right.

[00:31:07] MN: But at least when it comes to like, “Okay, I need to be able to work with these APIs. I need to be able to format this data properly. I need to know how this data’s being passed to the front end.” And honestly, you don’t have to be an expert at any of those individual pieces. You can talk to database experts and figure out how to more effectively call that data. You can talk to front-end experts and figure out how to more effectively load that data. Maybe that’s asynchronously, maybe it’s lazy loading, like whatever it is, you don’t have to know all of those different pieces. So I think when it comes to like what should you learn, I would say try to learn the simplest hops that are interesting to you. I actually think a lot of the tutorials that are like build a simple website that uses a database and is like a pet shop or something like that. I think all of those sometimes feel silly, but they actually cover quite a lot of the breadth and you can always add on into the pieces that you find more interesting, whether it’s making more complicated tables or processing the data differently or displaying it differently. And most of the people that I work with also don’t know exactly what they want to do forever. They take a position. They’re in that position for a couple of years. They learn a lot of depth in the space that their team operates, and then they rotate into a different team and see like, “Oh, actually I really care more about this part of the back end,” or, “I care a lot more about this part of the front end.” And maybe they transfer into that team for another few years. Maybe that’s their passion for life and they end up in a very like T-shaped role where they go very, very deep into that with less breadth or they change again. There’s no rule that says that you have to figure any of it out. I don’t really believe in the five-year plan. I believe in like the two-year plan. Like, “What do I want to do next year and what do I do this year to get there?”-[00:33:19] SY: Yeah. Yeah, I like that. So I know that community is very important to you and community’s been a big part of your own coding journey and there is one concept that I hadn’t heard of before that I want to talk to you about called the Peer One-on-Ones. I’ve heard of one-on-ones when it comes to managers and their direct reports, but I don’t think I’ve heard of a peer one-on-one. Can you talk a little bit about what that is and what you would use that for?

[00:33:47] MN: Yeah. This is something that I learned pretty late in my career. And before I learned about it, the only one-on-ones that I had were with my direct manager, with my direct reports, and if I was talking to somebody about a project. And those project meetings were always, “When is this due? What do you need? What do I need? Bye.”-[00:34:14] SY: Yeah.

[00:34:14] MN: And they weren’t great. And what I learned about these peer meetings is they’re really designed to build a relationship, and that’s the core need. And so if you’re a developer, having peer one-on-ones with other developers, whether they’re on your team or not, then ultimately it’s about building up that relationship so that you have somebody that it’s safe to talk to when you have a question or a challenge. I can’t tell you how long I went in my career where if I ever had any sort of challenge with my manager and whether it was a disagreement or I just didn’t know how to understand what they said, like, “Should I take their message to me and that they’re mad at me or what do I do?” Like having somebody to talk to is really important, but it’s a great way to talk about your different goals, whether that is learning more about something. Maybe you have somebody on your team that is really good at documentation or really good at kind of thinking about longer term plans, or maybe they’re really good at presentations, even like standup updates. If it’s something that you’re trying to get good at, then having that peer one-on-one is a way to just have a reason to talk to them about that and other things. It’s an opportunity to learn more about what’s going on in people’s lives. You don’t have to be invasive, but I think especially the last few years, there have been a lot of hard moments for a lot of people, and having these moments to further build up the relationship and further build up psychological safety on the team is really important and makes it a lot easier to support each other when something is happening, and we don’t have to just guess about what’s going on.

[00:36:05] SY: Any final words of advice for developers who are just getting started, just looking for their first job, given that you’ve had such an interesting career getting to where you got to and you had some starts and stops and restarts and all the way you’ve navigated your tech career? Any final words of advice for people who are on that journey today?

[00:36:25] MN: Yeah. I think ultimately one of the things that will be the most useful skill is finding somebody to talk to at the companies where you want to work. And sometimes it’s referred to as like a backdoor referral or a backdoor reference even. But I find that just reaching out to somebody who works at a company and saying, “I would love to learn more about this company. Are you free for some time to chat?” And for me, when I was looking for my next role, and ultimately at Etsy, I was reaching out to a lot of people through community Slack, through LinkedIn, just trying to find any sort of connection. And for some of those folks that ended up being like a coffee chat. For others, it was just some like DMs, and that was kind of enough.

[00:37:16] SY: What did you get from those DMs?

[00:37:17] MN: I learned a little bit about what the company culture was like, but mostly I was able to find a human being to tell my story. Resumes are great, but ultimately, there’s a lot of words for what’s usually a very simple message or sometimes a complicated message, and having a human to talk to made it easier because then they could refer me through their system, and that almost always led to an interview, and it got me the interview that I might not have with just a website application. I did end up getting this job with a cover letter, which also a lot of jobs sometimes require cover letters. It can be challenging, but the best case is finding a human to talk to and using your network and your network’s network to help find somebody is really valuable. And if you don’t have a network yet, then go to places where there are people. You can always reach out to me on LinkedIn or Twitter, while Twitter is still around, and I’m happy to help make any connections.

[00:38:26] SY: And that information will be in the show notes as well. So thank you so much for that. Now at the end of every episode, we ask our guest to fill in the blanks of some very important questions. Matt, are you ready to fill in the blanks?

[00:38:43] MN: I am ready.

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

[00:38:47] MN: I think early in my career I heard that having strong opinions loosely held was a virtue that I should subscribe to, and I had enough of a blend of imposter syndrome and actually not knowing very much. And I thought that it would be enough for me to just start sharing strong opinions. And I made this promise to myself that I just back down if I learn something new. But in practice, I just found myself arguing a lot, especially if I was introduced into a conversation as any sort of subject matter expert, even if I just happen to be slightly more informed on one tiny aspect than somebody else. So it only took me a short while to learn how to be kind of a jerk in a long time to break those habits. And instead, I really wish I had focused more on how to be a more effective teacher and writer and collaborator and also to find that psychological safety in myself from not needing to know an answer off the bat, but kind of being comfortable with that uncertainty.

[00:39:50] SY: Number two, best advice I’ve ever received is?

[00:39:53] MN: To be open to being wrong about something that I felt really deeply. I remember I was talking to a friend about how a reporter of mine, this was many years ago, thought that they should be doing something with their team. And I was telling my friend how I thought that my report was making the wrong choice because they were clearly misunderstanding that their own circumstances. My friend very calmly asked me like, “Matt, what if they’re right? Is it possible that they understand this situation better than you?” And I thought about it and my report was closer to the problem than I was. I was relying entirely on the secondhand information. And my takeaway wasn’t just that I could have been wrong about this particular decision, but that I was making a judgment based on some incomplete information and that really wasn’t helping anybody. And I was able to go back and ask my report some more information, which helped me understand their position and trust them more, which I should have been doing, but I also was able to be a better coach to them by thinking a little deeper. And I try to carry that advice with me into every disagreement I’ve had. And it’s made it a lot easier to try to empathize with the people I’m talking with and find a more productive way forward and be less judgmental.

[00:41:05] SY: Very nice. Number three, my first coding project was about?

[00:41:10] MN: Yeah, I mentioned a little bit earlier, but I started on this Lord of the Rings tech space game. So my first coding project was this quest to help a girl in this like swampy area near Hobbiton. And most of our quests were really highly template. So I only really had to plug in like the story and the description in a few spots, but I added some code that involves climbing into a tree in one room, which changed how you interacted in other rooms. And so like it knew that you were up on a branch and it changed how you could interact with the room and what things looked like and how other people could interact with you. And it was a really fun project. It was all in LPC, which is this weekly typed variant of C and everything ran in this one single-threaded environment. And the whole game rebooted itself every three or four days. And that’s how we managed memory. But it was a lot of fun to work with all those constraints.

[00:42:10] SY: Very cool. Number four, one thing I wish I knew when I first started to code is?

[00:42:15] MN: I mentioned this a little earlier too, but I wish I better understood how to collaborate with other people.

[00:42:20] SY: Nice. Yeah. Very important.

[00:42:22] MN: Yeah.

[00:42:22] SY: Well, thank you again so much for joining us, Matt.

[00:42:24] MN: Thank you. It’s been an absolute pleasure.

[00:42:36] SY: You can reach out to us on Twitter at CodeNewbies or send me an email, hello@codenewbie.org. For more info on the podcast, check out www.codenewbie.org/podcast. Thanks for listening. See you next week.