From Code to Culture: Matt Anger's Odyssey in Software Engineering at DoorDash

Explore the ins and outs of software engineering and organizational culture in the ShipTalk Podcast. In this episode, Dewan Ahmed, a Principal Developer Advocate at Harness, engages in a compelling conversation with Matt Anger, a Senior Staff Engineer at DoorDash.

In this insightful discussion, Matt reflects on his career, from a fresh graduate to his current role as an engineering leader at DoorDash. The conversation covers the evolution of software delivery methodologies, touching on Matt's experiences with Kotlin for performance and ecosystem, scaling platform engineering at his org, and the significance of good engineering culture for creating better software.

Delve into DoorDash's engineering culture, where Matt shares the company's strategies, including embracing mono repos, automated workflows, and centralized developer infrastructure for a seamless onboarding experience.

The dialogue extends to the broader tech landscape, addressing startup challenges. Matt shares practical advice for small engineering teams, emphasizing the importance of leveraging existing platforms like GitHub or Harness and avoiding unnecessary complexity in the early stages.

The conversation takes a personal turn as Dewan and Matt delve into the human and cultural aspects of software delivery. Matt emphasizes the significance of finding good mentors early in one's career, highlighting the impact of mentorship in shaping professional growth. The dialogue also touches on the importance of understanding the underlying layers of technology and maintaining kindness and professionalism in interactions.

As the podcast wraps up, Dewan and Matt extend an invitation to fellow engineering professionals, encouraging them to connect, seek mentorship, and engage in knowledge-sharing. Matt shares insights on how he welcomes individuals to reach out for guidance, underscoring the power of networking in the tech community.

---

Connect with our host Dewan Ahmed on LinkedIn: Dewan's LinkedIn

Connect with our guest Matt Anger on LinkedIn: Matt's LinkedIn

Transcript

Dewan Ahmed  0:06  
Hello, everyone. Welcome to the ShipTalk podcast. This is a podcast where we talk about the ins and outs, ups and downs of software delivery. Besides the technology, we talk about the people and the culture, which are behind these technologies. I'm your host, Dewan Ahmed and I'm joining from the beautiful east coast of Canada. New Brunswick is a chilly day here. And I'm super excited to be joined by Matt anger - an engineering leader, working as a senior staff engineer at DoorDash, Matt, how's everything?

Matt Anger  0:42  
That's going great. I'm in the wonderfully finally sunny after a few days of rain, San Francisco.

Dewan Ahmed  0:48  
That's the West Coast, right? 

Matt Anger 0:50
Yeah.

Dewan Ahmed 0:51
There's a debate like which coast is the best like East Coast or West Coast? I don't know. I haven't. I haven't never been to the west coast. So I think I have to be to the west coast before I can talk about the West Coast.

Matt Anger  1:02  
Yeah, I mean, they each have their pluses and minuses, right? I mean, you had you tend to have a lot more of the nice big cities and a bit more urban environment across most of the East Coast. And then in the West Coast, you've got massive forests and mountains to go through.

Dewan Ahmed  1:16  
Yeah, I lived in Toronto for 10 years. And I got tired out of big city living. So I came, I took a chance and I came to the East Coast. And so far, I've been loving it, like all the fresh seafood like beautiful nature. But enough about me, why don't you tell our viewers and listeners about about you? Like how did you get into tech?

Matt Anger  1:39  
I got into tech because I just kind of always loved it. Right? I grew up loving computers, you know, working on them, I was benefit to have some technical leaders at my local like elementary schools and middle school that, you know, we got to you know, play with computers, build them, get learn the basics of programming, just doing like basic and Perl back in the day, and then decided that that was fun enough, I wanted to make a career out of it.

Dewan Ahmed  2:04  
That's fantastic. I recall using Qbasic. So I did my high school in Bangladesh. And those were the days where like computer was in an air air cooled room. Like those were the devices that you don't need to protect. And then the the doors were locked. And I still recall like they're those mouse with like the moving balls. And some students will take out those those balls. And then when when you need to use the mouse then where's the cursor, right? So very different times.

Matt Anger  2:37  
Yeah, oh. It was definitely yeah, I remember, you still felt like at least once a month, you'd have to pull the ball out and like take a Q tip to get all the dust that had gone on to like your mouth would be sticking you couldn't move it and, and having to load up everything from like floppy disks that took forever to read from.

Dewan Ahmed  2:56  
I think we're giving our age, I can think about the VCRs. And like cleaning out the tape with the sprays. But move less. Let's fast forward 30 years back to the current day and age where we're talking about Kubernetes and clouds, and how can we squeeze out more juice out of the infrastructure we have? And one of the things that many people under like think about is the tech stack? Like how do architects or CTOs choose the tech stack? So one thing I've always kind of wondered that there is no right answer. But let's say if you talk about DoorDash, right, what's that stack? And how did it come about, like, forming there? Because it didn't evolve in one day? Right? So how, how did that tech stack form? And how does it enable the DevOps kind of delivery at DoorDash?

Matt Anger  3:44  
Yeah, I mean, we started off the way a lot of startups do. We were a Python model, right. So we used to use Django, and everyone kind of kind of developed in one code base, and everything was stored in one database, right. So it was very similar to lots of other startups I've done in the past, which you know, either also use Django or Ruby on Rails is another big one a lot of big startups have used. And over time, you know, as the company grew as we started to do more and more products, and particularly as we started to have more and more engineers, we needed a way to kind of help unlock and allow teams to ship faster and kind of more on demand. That was the big thing that we want to focus, right. Because with that giant monolith, particularly as we're trying to coordinate all these changes, you know, towards the end, we were down to shipping maybe twice a day, like Monday through Thursday. And it was always a big process to kind of roll that out throughout the whole fleet. And so we started looking at like, Okay, how do we want to evolve our services architecture? We took a good long look at kind of what was out there and we decided we were going to use G RPC. So primarily because like it's got this huge ecosystem. There's a lot of tooling around it. There's a lot Good, you know, other people are using it, there's a lot of good blog posts about it right. So the the hope was that we weren't going to run into too many sort of like unknown or weird issues that were already lots of people much bigger than us that were using G RPC. So we're hoping like, this should be a pretty safe bet. The place where we took a little bit of a risk was, we just have to use Kotlin as our primary back end language. The benefit of Kotlin is that we do still get the entire JVM ecosystem, and we do use a lot of sort of like Java components. But then we're trying to kind of marry that with sort of some of the newer advances in sort of like programming language design, trying to embrace a little bit more of that functional nature, right, going towards more the immutable by default, as well as the benefits of things like CO routines to make it easier to write asynchronous, and async friendly code. Our whole tech stack is built on top of Kubernetes. And we've been slowly evolving that as well, right? We were originally in, you know, just a single Kubernetes cluster, which then got bigger and bigger, bigger. And then we started approaching like based architecture had multiple Kubernetes clusters. And now we're also on our way to like embracing a service mesh that we can do no more fancy things around traffic splitting and Canary rollouts, and sandbox testing. And slowly replacing, you know, what was like an nginx ingress with a more advanced and more customizable envoy based one. And, you know, kind of as we take those things to the next level, and trying to really get ourselves to the place where, you know, we can have that that, you know, paragon of, you know, developer productivity where we can have like, a fully continuous development cycle where as soon as you merge your change, it'll automatically start a canary analysis. And it'll figure out ahead of time, like are you did this cause any breach in SLOs, is this causes an increase in error, all that's up for you automatically, and then eventually just roll out the entire fleet without you ever having to touch a button or even think about it. And it should be, you know, safe, fast and efficient so that we can really get our developers shipping all the time and getting the immediate results back of whatever it is the experiments and another thing that they're trying to run, so we can keep iterating?

Dewan Ahmed  7:11  
Yeah, I remember reading that blog post about how DoorDash moved to Kotlin. And I think they read it like a few years ago, and I couldn't imagine that I'd be talking to the blog author on this. So how big no engineering decision is like, you make a decision, and everyone is on board, right? Initially, there might be some some questions and concerns like why would go Lang and why Kotlin? Has anyone done it? Was it like the wealth of Java ecosystem? Like the benefit of finding link Java, so you can quickly pick up Kotlin? And having like, a single code was like, What about the fact that like, what were the last three convincing factors that sold the deal? Yeah,

Matt Anger  7:53  
so the big wins were really Yeah, though, the entire Java ecosystem, right? Java being a really well studied, well supported language, right. And particularly for a lot of the things that we were already using, right? We already were heavy users of Kafka, we were picking up Cassandra or are more like no sequels type stores. And a lot of those things like they're really they're best supported in in the the JVM ecosystem, primarily, because a lot of those developer those products are built on top of jump, right, like Cassandra and Kafka, both are JVM apps themselves. So using the Java libraries gives us even better support than you would make get from, for example, like goaling, or even in Python, right? Like we run into issues with, you know, the live rd Kafka wrappers, and our Python apps all the time, every time we tried to upgrade it, we'd always have to be super careful. And kind of having that that sort of that more of that first class native support was was really kind of like, wow, this is a lot easier to work with than it was in the other worlds. The other thing was, yeah, being able to find your job, not just Java developers, but sort of any object oriented programmer can kind of pick up Kotlin fairly quickly, it's a little bit easier to get around that because it has the standard object oriented, like inheritance and, you know, interfaces and things like that. Whereas, you know, go does more of that kind of like that duck typing, which, which is a little bit harder to kind of teach people how to use and teach people how to think and sort of like, how do you write you know, go idiomatic code. Obviously go also has its own benefits. But we do have some services that are written in Go for places where we need it. But for the general back end, we really felt that like Scotland was going to be the language that it would be the easiest to kind of train developers up on and then and then just also, like, be the most productive.

Dewan Ahmed  9:46  
Yeah, that makes perfect sense. Now, if we shift gears from how old becomes software like the delivery piece of the of the puzzle, how did that evolve at DoorDash? So you mentioned about like a single Kubernetes cluster and then scaling to multiple Kubernetes clusters. But let's see the other pieces like how you do CI, like what's your set golden base image or how you do monitoring? Let's say I joined DoorDash. Right as a new engineer. Now I'm confused by a zillion things, I have to log in credentials. And now I've learned that what would be less in the first 14 days for me? Yeah,

Matt Anger  10:21  
so I mean, we're, this is rapidly evolving even today, right? So like, back when I joined, it was it was very sort of rudimentary, right? We had, we spun up a bunch of Jenkins instances by ourselves. And we had kind of hooked it up. And we were heavy users of helm and TerraForm, to just kind of like magically make things happen, as well, as we built a small slack bot called DD ops that we were having people use that, you know, like, oh, DD ops, deploy my app, this version, right. And so it was it was very rudimentary. And we're evolving that. Right? Not like I said, we're trying to really get to that that continuous delivery cycle. So we don't even have to think about that stuff. But we're, you know, we're starting to leverage build pipe, right, we're starting to use that to replace Jenkins to have more standardized pipelines. We have standardized our Docker base images, that was like one of the first things I did after I joined, because I was just like, there's too much copy pasta here. Like Why does every service copy the same 50 line Docker file, and then add the last tool. We've also standardized sort of our serving framework to try and help standardize all the metrics, make sure that we have like circuit braking, load shedding all of these things that you know, you really want to have. And just kind of make sure that they're there as defaults. And it's no longer a thing where it's like, get the Go hound everyone to go, did you upgrade this? Do you have the right version of this? Did you configure it? Did you actually turn it on? Like all those things, we just making sure that they're they're out of the box. We're embracing Spinnaker. Now to help kind of do a lot of that, like I said, the the automatic Canary analysis and things like that, that we want to do as we're rolling out software, making sure that it goes safely. And really just trying to get to that, like said that that golden state of making sure that the systems are as far out of the way as possible for you. So that it's all just sort of like magic you barely even have to think about.

Dewan Ahmed  12:21  
Yeah, I recall. So when you mentioned Jenkins, I recall, it was around 2019. And I was prepper, preparing for a conference, or maybe end of 2019. And that conference was in New Zealand, Auckland. And the talk was on Tecton, like the open source project that originated at Google. And I was rehearsing that talk, right? So I had like, 10 of my IBMer friends. And one of my slide was like, why Jenkins is bad. But it wasn't that wording but but why you shouldn't choose Jenkins, right and choose something else. And then I got a pretty important and good feedback. They said "Dewan, that maybe 90% of the room would be Jenkins user. So probably don't say Jenkins is bad because everyone uses Jenkins. Right?" So that was a good lesson for me like maybe a traditional CI instance. Yes, let's frame it this way. That was a, like a single job of yam packed with all the plugins and but but don't say Jenkins is bad because people wouldn't be able to take it. So yeah, like we sometimes we don't understand the value of these, like old and tested technologies. But oftentimes, most of our technologies are powered powered by these things. One other thing you mentioned about like how it evolved, right? So I guess, like nowadays, if someone joins DoorDash, like a lot of this underlying pumping are abstracted away from them, like, do they like do they see what's going on underneath? Or is it like app? Like I'm trying to understand the abstraction. Yeah, how much of the abstraction that's a new engineer needs to know, to appreciate what's what's going on under the hood.

Matt Anger  14:00  
So for the most part, there's very little these days, right? We're we're also starting to embrace mono repos. So we have a lot of, you know, especially if you're developing, let's say, a net new service, and you decide to use you know, our, we built a new UI for provisioning a new service to make that really just right, so you click the new UI button or the new service button in our UI. And it takes care of automating a lot of the background work that used to be manual, right? You sit there go to like three different repos and create a bunch of TerraForm to create a new ECR repository, and to map this service to an appropriate Jenkins instance. And like, like all this stuff, that was just sort of like, you know, black magic that you had to know, okay, go here, type the six command, then copy, paste and copy paste this thing and just change the service name. And like, we tried to automate a lot of that, right. So it's really you click a button, and yep, so there are some like approvals and stuff that need to go on in the background, but it's a whole workflow that we've automated that you no longer Need to directly kind of interact with our C? And then yeah, when it comes to like, Okay, so now you've got your new service, right? It created a PR for you with a with a templated app in there. And you can start making your PR and Ci is already set up. And we've standardized the CI pipelines, particularly for for services. So you don't have to really think about it anymore. Because we know it's going to be, you know, a Kotlin app. And we know it's going to use Gradle to build it. And we built you know, you eyes with build insights that you can see, like, hey, here are all the steps that ran and you can help figure out why was my build so slow, why what happened did it didn't miss the cache, right? And we built a nice UI, we have this whole centralized developer infrastructure called Dev Console, where we kind of like, put all these different plugins to try and just have this be like the center place that, you know, if you need help, this is where you go, right. It's got code labs, it's got a service catalog, all these places where we want it to be sort of like the homepage that you're if you have any questions you'd go here.

Dewan Ahmed  15:59  
That's fantastic to hear what other like the pain points I had when I was a developer? Was the dependencies like the dependency hell, I have, like so many differences and some version outdated. And now all of the app is waiting to compile? How did this evolving of your software delivery help with those battling those dependency? Hell's? Yeah,

Matt Anger  16:23  
though, right now, the mono repo is our primary method to try and kind of save this. And the way we're doing it is by essentially, we have what we call them platform releases. So essentially, what we do is we cut a new platform release every six months, and sort of within that platform release, the idea is that we won't touch, we won't upgrade any of the dependent libraries to a new major version, unless we can be like 99% Sure, it's not going to have any breaking changes. And part of that is so that one, we can ensure that we have all the latest security updates, and performance updates and things like that. But then the other side is also just making it easier for the individual service owners, that they're not constantly getting pinged like every month by like, oh, you need to go upgrade the SLF for J dependency and like, like all these different, like vulnerabilities that we've had that are coming out, it's like, nope, yeah, we'll take care of that in the platform releases, you just, you know, we have we built our own custom Gradle plugin, so you just say, Hey, I'm using the, you know, 2024, you know, January platform release. And that takes care of basically pinning all the dependency versions to a set that we've tested, that we know, work well together. And so then the idea is that, you know, we will support a platform release for up to 18 months. And then so it's like, once every year and a half, you have to go through the you know, the pain of oops, let's move to the next platform release. But it kind of you know, you're not dealing with like 1000 paper cuts throughout the throughout the year, it's just like, it's once every 18 months, and you can move to the new platform, and life is better.

Dewan Ahmed  17:55  
Yeah, that seems great. Now imagine, let's say one of our listeners, their new startup, there's only five people so not every company is they can Uber or DoorDash, or Google. And they think all like so many technologies, they have to do that all like how can like small engineering teams were just starting, they want to have that scalability, they want to have their security, they want to have that enterprise readiness, then still start somewhere, like what would be your prescription for that,

Matt Anger  18:25  
um, I think especially when you're small, you can get by with sort of just embracing what a lot of the existing tooling gives you, right? Like, if you, if you're on GitHub, you know, you can use GitHub actions, you can use note dependent pot, and like all these nice things that are already built into there that are sort of like good enough, right. And yeah, you may have some pain points here and there as you're going through that. But for the most part, if you just kind of embrace those, while you're small, until you have a reason to start, like really trying to push the envelope or really customize those to fit your needs, I think you'll probably have a pretty good time, right, and especially when you're small, you're not gonna have a ton of code. Even a simple mono repo structure for your services, is gonna get you really far right until you start talking about having like 100 services and the scenery role, you're probably not going to see a lot of the pain points you with your you know, even the simplest of mono repos, they'll probably work just fine, regardless of which language you picked. And right whether it's, you know, Python, or go or Java or Kotlin, right, it until you have like tons and tons of code, you're not really going to see the like, oh, it takes, you know, super long for my IDE to open up because it's trying to index too much code and I haven't set up like the proper package sharding so that it only loads the one service that I'm working on yet. It's like you're just starting out. You don't have that much code. It's fine. It'll just just just go with it until it actually starts becoming a pain point.

Dewan Ahmed  19:52  
Yeah, absolutely. Like oftentimes like people overthink, and they're trying to, like go into one extreme On that build versus by an end, as engineers, we often do, let us roll it ourselves. And definitely, like, let's say something like GitHub or even like Harness gives you that platform, where you have the code repository, you can have your own CI CD infrastructure as code. It also gives you like a out of the box secret manager. So rather than you trying to solve your own business problems, you're trying to invent something that already exists. And definitely, as you scale, you have your bigger engineering teams, you can you can still do some of those work in house. But initially, I think something like a platform gives you more appeal on over Sure,

Matt Anger  20:37  
right? You host go with a hosted Kubernetes solution, you know, don't don't worry about rolling your own like you these things, it's not just the the initial build, that's the hard part, right? It's the continued maintenance, it's who's gonna take care of doing the upgrades, who's gonna make sure the upgrades are saved, right? These are all very time consuming tasks. And when you're small, like Why spend your time thinking about that, try to find your product market fit, try to find sort of like, what you're gonna build, that's gonna make your customers love you and want to keep using your product.

Dewan Ahmed  21:10  
Yeah, absolutely. So you mentioned about platform. And we keep hearing these terms these days, right platform engineering, and infrastructure engineering. I recall, when I was a consultant, like we had to build a war war, and the WAR file would be sent to some other team on some remote server, and they'll take that WAR file and then deploy it to some other production server. Right? Now we're very, very, we're living in a different time and ages where we have this platform key man, self hosted platform. So as like, I check your LinkedIn that you've worked at Cisco, as well. So how would you say like those days writing from the lens of SIS admin, how has software deliveries changed?

Matt Anger  21:58  
Oh, it's drastically different, right? I mean, back when I was at Cisco, the world was was just entirely different, right? We were building, you know, software for these giant data center switches. And our release cycles were like, you know, 18 months long. And, you know, we'd be sitting there constantly cutting new golden releases, and then each golden release would go to a QA team of like 150 engineers, each one of which big huge test suites that they'd be automating and running. And it was, you know, we're building on, you know, it wasn't good, I don't even remember what the, you know, our distributed code system was, you know, and we had very rudimentary bug tracking systems. And everything was written in pure C. So we're like, just very, very different world and compilation used to take in some cases, like an hour, if you had to build the full image, just just trying to build everything that needs to happen, because we didn't have good build caches or anything like that. And so like, it's 100%, different these days, where we've got not just build caching at, you know, sort of the the build tool chain level, we got build caching at Docker level, and we can constantly roll out and we can roll out little sandbox tests with like 1%, or point 1% of traffic with ease. And and, you know, we were no longer just relying on these huge QA teams that have to have run this manual battery of tests, right, we've got unit tests, we've got integration test suites, we've built up load testing suites to help do performance testing, you know, all these things that are just, you know, making sure that we have these strong repeatable processes to really know that we can ship with confidence and ship 345 10 times a day, as opposed to oh, we're gonna cut another major release in 18 months, and then we're gonna go bug all our customers to upgraded over the next two years. And we have to make sure we have an LTS release for everything, which you have to support for, like five years. And like that, you know, that that whole cycle, which I'm sure still exists in a lot of the, you know, the enterprise customer role, but for, for, you know, like me as an individual developer, right, you working on more of like a consumer product, I'm shifting, I get to see the results of my actions, the results of the the code that I'm writing, you know, the same day, and that's, that's so cool to kind of feel and see that, and that kind of see that immediate impact.

Dewan Ahmed  24:30  
And one other thing that's often forgotten is the documentation. So imagine writing the documentation for that two year release cycle. What did I do two years back March 15. What was that feature about right? So I think it's fast release cycle also helps with documentation because every time you have a release notes, you're constantly updating not only your software, but also the documentation.

Matt Anger  24:54  
Well, and then also the automation around helping build those releases, right if you if as long as you're writing, you know, Good kick, get commits and good PR descriptions and whatnot, we've got so much tooling that can really help make that happen, mostly automatically. And then you just have someone going through and cleaning it up a little bit to make it more human readable.

Dewan Ahmed  25:15  
Yeah, absolutely. Talking about human is also two aspects of the software delivery, besides the technology, like the the human aspect and the culture aspect. So let's see, if we have shift gears, how have you seen the engineering culture affect the software delivery, like the the quality of the code, and its relation with the engineering culture? Yeah,

Matt Anger  25:40  
that's something that's, that's I feel like has drastically changed as well, particularly as the engineering field has just gotten so much bigger, we have so many new people coming in with different ideas, different backgrounds, and it's great to see like, all of the different ways that we're now approaching some of these problems, as opposed to, you know, the standard, like Waterfall development cycle that used to kind of rule everything back to, you know, 20 plus years ago. And, you know, trying to get to that stage. And it's interesting to see, right, culture is always like, there's this balance that, you know, every company is trying to find where it's like, how do you balance all of the product, as with all of the engineering efforts, like how much tech debt can we take on to try and you know, get that product out sooner get that product out faster, like wood, because eventually we're gonna have to pay that down. Because we can't just keep piling, you know, things in a giant Jenga tunnel with one little piece down here at the bottom right? Eventually, we got to help shore that up and make that system a little bit stronger, make it a little bit more scalable, a little bit more reliable. And that's something that I think, you know, in every company, it's always going to be a constant give and take. And it's always going to be shifting a little bit you're you're always playing that, like, you know, that game where you're like, on a wheel with like, a little like skateboard on top, or you're like just just trying to like wiggle back and forth just trying to stay?

Dewan Ahmed  27:06  
Yeah, no, for sure. So if we think about the psychological safety, right, so now, now, you're confident like you've seen a lot of battles within these different technological evolution, but when we're just starting out, right, like, we don't have that much confidence, and we don't have that psychological safety there. And when making the right decision. So how would you say like Matt Anger when Just started fresh bread out of the university, the psychological safety we have, and like, how your confidence has evolved, and how you're, I guess the seniors in the teams at that time helped you?

Matt Anger  27:41  
Yeah, I mean, I think the big thing is finding great mentors early on, right? That was a big thing that I did. And one of the reasons why I actually stayed with Cisco, as long as I did for my first job out of college, right, as I found some great managers and great mentors, that that that kind of really helped me learn the software development process, the, you know, evolving my careers, taking on some of the more the design work, and just kind of having that space and having someone that I can quickly bounce ideas off of, and kind of, you know, level myself up to then get some of that confidence to be like, no, no, no, I've already seen this situation, I help solve it already. Right? Like, we know how to do this, right, we can do this, again, we can repeat this process, we can, we can make it a little bit more adaptable, if we need to, right? Finding those people that are going to help you and kind of be that champion, and be that safe place where you can say ideas that are like, probably really naive in the beginning, right? And it's like, and that's okay. It's like, hey, no, I get where you're coming from, but like, there are some side effects, like and you're thinking of those those secondary and those downstream effects like, Oh, if we actually did that, how would this piece over here work, right? And kind of learning how those things work and learning kind of like the peek under the covers and see how things work? Right? Let's lift the hood up. So you see what the pieces of the engine are doing? Try replacing one of them, right? I think that some of that experimentation, and having the space to do that is really going to help you, you know, level yourself up and be just become more more competent. And, you know, really, when you understand how the layers underneath you work, you can make better informed decisions for what you're trying to build. So like, don't be afraid to like, go look at the library that you're using source code and see what it's doing and try to understand and see if you can find the design documents for why they wrote it that way. See if you can find talks from the authors about why they made the trade offs they did. Because those will help inform you on one how to best use it. But to maybe there's a time when you want to write your own version of it. And you can say, hey, maybe I'm going to change the trade offs that they made because I think this will better fit our use case but you'll at least know that that's what's going on.

Dewan Ahmed  29:54  
Yeah, and I believe that's one of the reason that you try to give back as a mentor yourself and in Plado. So tell us about their platform and how, let's say if someone wants to have you as a mentor, is it a one time mentor or get some guidance from you? What's the best way to do that?

Matt Anger 30:09
Oh, I mean, within like DoorDash I am I'm fairly open, right? I tell anyone like my calendar is up to date. If you want to throw some time on my calendar, go ahead and do it right. I'll try to make time for everyone. And then I have a series of probably close like seven or eight people that I meet with regularly either weekly or bi weekly, as sort of like a continuing longterm member mentorship, but then even outside of that, right I fully welcome people just you know, reaching out on LinkedIn like, Hey, can I can I set up 30 minutes to chat with you. I'm trying to figure something out. Right. And it's really just evolved. Like I said, the one of the ways that I was able to level up was just finding those people that were willing to you know, listen and talk with me. And I think it's really important to kind of help build that next generation of thinkers in the next generation of leaders and trying to make that a reality.

Dewan Ahmed 31:01
But that's fantastic to hear. And this is a call out to all the engineering professionals who are either viewing this podcast or listening to this point. Podcast, we can always find 15 minutes out of our very busy schedule. But you never know what that 15 minute might mean to the next candidate who's just puzzled how to write a resume, or how to build a project on GitHub. So over the last nine years, I've reviewed over 1000 resumes on LinkedIn. And that's something I do as a way of giving back to the community. So if you're looking for a resume review, connect with me on LinkedIn, I'll put both Matt and my LinkedIn URL in the description. And when you come to a position where you can help, remember to pass it forward like this is a gift, which will just keep giving. So taking 15 minutes time out of your schedule to help someone really goes a long way. Now,

Matt Anger 31:56
over Sure, plus, plus, at some point, someone you help will probably have a really awesome startup that you want to join. And they'll be good to know someone there.

Dewan Ahmed 32:02
That that's actually the secret reason why I'm trying to help more and more people that you actually spoke something that that was in my mind, like, the more people we help, the bigger network we have. And that's, that's the power of network. Now, if we want to wrap up this podcast with three key lessons that you learned in your long and rewarding career, and someone who's just starting out, can really benefit from those, those three lessons, Matt, what those be.

Matt Anger 32:36
So like I said, the big one is find find good mentors and people that are going to help you with your growth, right? That that is going to be one of the biggest things that you know, will help you in your career. The second is, like I said, don't be afraid to sort of like peek under the covers, or look under the hood, right? Getting some of that depth. But the way I always say it is like you know, you can you can get up to like senior engineer, usually just by like becoming a really good coder. But then once you start going into that, you know, the staff, the senior staff, the principal, where you're trying to get to those higher levels, you need to have a good knowledge for how things are going on, on underneath that you can make those decisions, and you can kind of build for scale and build to really solve the underlying problems. So don't be you know, don't be afraid to kind of, you know, go in and look, I was this thing actually doing it. And you know, try to understand why. And if you can, especially if you can find that explanation for why it was built that way. I think those are those are super useful things to kind of get yourself knowledgeable on. And lastly, I think it's just, you know, be kind, you know, you're gonna be working with other people, even if you have, you know, hugely conflicting tech views, right? Make make sure you're always talking about the tech, right? When you're trying to design for this, right. You're you're not it shouldn't be a personal attack. Right? You don't want to have that, right. You should always be professional, you should always be, you know, very cordial with the people you're working with. And yeah, you can sometimes have heated tech decisions, but make sure that it stays you know about the tech.

Dewan Ahmed 34:06
The last point, really just like touched my heart, because I read a blog by someone. They say like what I learned from my first five years as a software engineer, and he he overheard some of the feedback, he heard some of the feedback directly. And the common theme across all the feedback was, he was very direct and unkind with with his interactions. And he was a fantastic engineer. But then he couldn't move too far in in his role just because those interactions might be accurate, techno technologically, but not very kind. So his his takeaway was exactly like be kind because people will remember how you make them feel. At the end of the day. People write code, some write faster, some write slower. You're some right or wrong decision. But we're working with humans, we're not working. As engineers, we're taught how to work with machines. We're not taught very well how to work with people with actual feelings. So Matt, that last point is fantastic.

Matt Anger 35:11
Awesome. Thank you.

Dewan Ahmed 35:12
Thank you, Matt, for joining this podcast. Thank you everyone who listened and viewed this podcast. You can find this podcast wherever you find your podcast, and we'll come back to the ShipTalk podcast to talk with exceptional technical leaders like Matt. Thank you for joining ShipTalk podcast. I'm your host Dewan and I'll see you next time.