StaffEng Podcast

Alex Kessinger (Stitch Fix) and David Noël-Romas (Stripe)

This episode is a celebration of the journey we have been on as this podcast comes to a close. We have had such a great time bringing you these interviews and we are excited about a new chapter, taking the lessons we have learned forward into different spaces. It’s been a lot of work putting this show together, but it has also been such a pleasure doing it. And, as we all know, nothing good lasts forever! So to close the circle in a sense, we decided to host a conversation between the two of us where we interview each other as we have with our guests in the past, talking about mentorship, resources, coding as a leader, and much more! We also get into some of our thoughts on continuous delivery, prioritizing work, our backgrounds in engineering, and how to handle disagreements.  As we enter new phases in our lives, we want to thank everyone for tuning in and supporting us and we hope to reconnect with you all in the future!

Links

Listen

Download Episode

Transcript

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

David: Welcome to the Staff Eng podcast. Today’s episode is a special one. If you’ve been following along, you know that this is the show where we interview software engineers who’ve progressed beyond the career level into staff levels and beyond. We’re interested in the areas of work that set staff plus level engineers apart from other individual contributors. Things like setting technical direction, mentorship and sponsorship, providing engineering perspective to the org, etc. My name is David Noel Romas and I’m joined by my co host, Alex Gestner. So why is today’s episode special? Today’s episode will be the last episode of Staff Inch. Alex, why don’t you tell us more about why that is?

Alex: Sure. Well, I think off the top, nothing lasts forever, especially nothing good. And I think that, you know, I feel like we did some good interviews, but like, you know, I think doing this show takes a lot of work. And just if anyone at home is curious, David does far more work than I do to make this work. And it was a lot of work for myself. And so I’m really proud of what we’ve done and I’m proud of the interviews that we did, but I think we can sort of let this go and let it live on its own. I don’t know. How about you? What do you. Why do you think this is the last episode?

David: Oh, man, I feel so bittersweet to be having this conversation. But, you know, I think that there’s something special about, you know, as you say, sort of things being finished, and there’s something kind of more valuable in that than sort of things that outlast their. Their time. It’s also just sort of like a changing time for me. When I started the show, I was really interested in learning a lot about what it meant to be a staff engineer. And I feel like, you know, one of the lessons that I’ve taken away from the show is that first of all, like, it never ends, right? You have to keep learning. And also that sort of like, there’s more different about what we do than there is sort of. That’s the same. And so the show could go on forever, right? There’s. There’s no shortage of people to ask and things to learn. But I feel like the commonalities that are there, we’ve covered, right? We’ve picked up a lot of commonalities throughout the show. The other thing that’s changing for me is I’m, you know, moving into a different phase of life. I’m going to be a dad by, by the time folks hear This. I will have been a dad for a couple of months, and so I’m really excited about that, but thank you. But I’m expecting that to sort of, you know, it’s going to require a whole new degree of focus. And so I need to, you know, as we talk about in the show a lot, focus is a big deal. And being able to sort of choose the right project, so to speak, is, you know, I guess my next project is going to have. Have her own little heartbeat, so.

Alex: Nice. Yeah. One thing I’d like to tell anyone, like, we’re going to. We’re going to talk to one another and we’re going to sort of learn a little bit about ourselves. But one of the things that I want to highlight is that in any organization, there’s people who you might look at them and think that they know more or they are sort of like people you can’t talk to. And I just would highly recommend, if you see someone in your organization that you respect, that you think you could learn a lot from, just reach out. I think people are so generous with their time, especially with people who seek knowledge. And so just ask. And if you work at a place where you don’t feel like you have access to folks there, the Internet is a real. And the people on it can be kind. I think just keep asking and seek out communities of expertise.

David: Absolutely. And the other thing I would say is, like, people should be aware that, you know, I didn’t get a single no when I was soliciting folks for this podcast. You know, everyone out there wants to help and is interested in helping. And, you know, same goes for me and for Alex. Like, her contact information is out there on the web, and we’re happy to talk to folks. I. I have sort of inbound messages from strangers all the time, and I love it. I think that’s great. And I think that’s part of sort of the community that we’re trying to build. And so, you know, my hope is that although this is the end of this staff Eng podcast, I hope that we spring up a whole lot more in the years to come. So, anyway, let’s actually get to something that’s kind of meaty. Alex, you’ve alluded a bunch of times throughout the interviews to sort of some of your background, and it sounds fascinating to me. You know, you mentioned that you worked at a startup with Brian Berg. I think Brian’s awesome. Want to hear all about that startup. You also mentioned in the interview with Amy that you have a background in libraries, which Seems fascinating to me. So let’s dig into some of that. What’s your story?

Alex: Yeah, I think that I follow a pretty typical experience with other people who were introduced to computers at a young age and just immediately found them fascinating, you know, and I remember really early on, I think I was watching like 60 Minutes or just some new show and they mentioned the word hackers. And I was like, whoa, that’s for me, you know, at the age of like 11. And I think what’s interesting is like, I did sort of like follow the sort of like, I want to break into things. I want to, like, cause havoc, but very quickly. One of the things you run into if you are, you know, want to become like a serious hackers, you’ve got to learn how to program because you’ve got to learn how to like, break things.

David: And.

Alex: And so I found this programming thing and I remember getting like a book on QBasic and typing things like letter for letter from a book into a text editor and making them run.

David: That’s an experience that no one’s ever going to have in the next 20 years. Copying code from paper into a computer.

Alex: I don’t know. You know, I actually, I gave my son. My son asked me the other night. He was like, hey, I want to learn how to program. I’m like, okay. He’s like, do you have a book? And I was like, I might. And I had to, like, I had to go through like rows of like old Perl books and like, this isn’t for you. And I found a copy of JavaScript, the good parts. And I was like, okay, this is a good one. And he came upstairs the next day and he’s just a very literal guy and he had literally wrote the book into a notebook, like parts of it, like the whole book. So anyway, long story short, I think. I think there’s still room for it, but I think you’re right. I think lots of people, and I think for what it’s worth, is like, I love that there are many different ways to find computers. Right. Like, my way doesn’t have to be the only way. And I think we’re all coming to programming in different ways. I think that’s amazing.

David: Absolutely. By the way, just to interject really quickly because there’s a parallel there between something we said earlier. You mentioned JavaScript, the good parts. I love that book and I’m a big fan of Douglas Crockford, but riffing on the idea of sort of like you can contact anyone in our community and they’re Happy to chat. One of my cherished emails in my history of sending and receiving is a thread with Douglas Crockford. Because I contributed a small bit of code to. I contributed a JSON parser, JSON.org back in the day. But you know, all that to say that, like, people are out there and totally accessible and happy to help. Anyway, sorry for the interjection.

Alex: Yeah, no, I actually worked at Yahoo when Douglas Crockford was there. And so you could, like, any given month you could go like, get a class taught by Douglas Crockford. It was amazing.

David: That’s so cool.

Alex: You know, so sort of flash forward to I think my, the start of my professional career. Sort of funny enough. Like all through high school and college I was like, programming requires too much math, so I’m not gonna go get a CS degree. That’s not my strong suit. And I actually started studying like broadcast communications. And I was really excited. I, you know, I still am a fan of like movies and tv, but I think sort of halfway through my college career I realized that I was a bigger fan than I was a producer of media. But at that time I had started writing code to solve like homework issues. And that still wasn’t the light bulb, by the way, that maybe I should be a programmer. But I was really lucky to live in San Francisco at the time. And there was a small company that if you live in San Francisco, you might recognize called Monkey Brains, that is like, they’re a wireless service provider now for the whole city or large parts of the city. But in the early 2000s, they were sort of like a colocation company and they were looking for an intern. And that was my first gig where I was like putting FreeBSD on boxes. I was doing jails and setting up websites and I was writing code for a purpose, like for people. And that I think that sold it. So from there I was able to get an internship at Yahoo, which turned into a full time gig. And, you know, I was just thirsty for more experience, more knowledge. And I just kept learning and learning and learning. And so living in San Francisco, like In, you know, 2008, 2009, I wanted to work at a startup. I did that with Brian Berg at a place called app.net or. I mean, the company’s name is Wix Media Labs. And I had some amazing experiences at startups. But you know, startups can be stressful and they can be, they require a lot of time and energy. And so after my startup experience, I was really, I wanted something, I don’t know More, Less stressful, but also just like, different. And I was lucky enough to find this library services company in Berkeley, California, which is where I was living at the time. And for me, I’m not ashamed to say this, but, like, the first selling point was that I could walk to the office from my apartment.

David: That’s awesome. Yep.

Alex: And I got super lucky, but. And then it was just a lovely experience, like working and building code. For libraries and librarians, you just learn a whole bunch and their ethics are just amazing. And I think a lot of the things that we’re learning now in our industry sort of about being more inclusive and celebrating diversity and a lot of things that I think are important for the continued health and growth of our industry. I was learning them in that community far before I saw people in our industry sort of speaking up about this stuff. Anyway, that was a lovely experience. But then I continued to want more and more growth and, you know, it’s. Libraries are just always underfunded. We never give them as much money as they need. And so I had to sort of branch out to find new experiences. And I’ve been now at Stitch Fix for the last three years. About half that time has been as a principal engineer. And I continue to love to write code, but I think as we’re learning, as you grow in experience and influence and impact, you know, I write less and less code and I focus more on.

David: Oh, don’t. Don’t answer that yet. That’s for the end, Alex.

Alex: I’ll save the percentage of how much I write code for.

David: Okay, good.

Alex: Anyway, I love working with Stitch Fix. It’s kind of an amazing place to work compared to. Well, anyway, it’s just an amazing place to work. So that’s my story. I’m really curious, David. I feel like I know far less about where your time before, where you’re at now, so I’d love to learn more.

David: Yeah, absolutely.

Alex: So.

David: Where does it all start for me? I mean, I think I came along a little bit later than you did, but it was a similar sort of beginning, like copying code from books for sure. And, you know, a heavy interest in sort of the Internet and how it worked. I think my introduction to programming was. I certainly wrote some basic, but I think there was lots of like, of web programming early on and, you know, there’s still pretty early days. I remember when CSS became a commonly available thing in browsers, you know, and like, it was interesting. I. I taught myself. First thing I did was teach myself HTML, and then I was like, hey, I Want to, I want to make some of these things move. And so I learned some JavaScript and then I was like, okay, well I want to, you know, process some data that gets submitted by users. So I learned some, I think it was pearl at the time with like CGI scripting and then eventually that became sort of like php. And my first work was always freelance stuff. So I grew up and live in Winnipeg, Canada, which is very far out of the way, you know, far out of any sort of tech ecosystems. And so I was pretty isolated and I was doing stuff kind of on my own. I was finding people that needed websites. I was like a 12 year old kid that was finding people that needed websites and going out and building it for them, right? And then, and so that also developed sort of the entrepreneurial side, which I’ve been interested in for forever. And that was part of how I put myself through school. I went to school for electrical engineering. That was part of how I put myself to school. I also worked my first kind of real job doing, doing programming work was building training material for the Canadian military online learning systems. And so that was pretty interesting. It exposed me to sort of, you know, big organizations. Although the military isn’t really, isn’t stereotypical in all the ways, it certainly isn’t representative of tech organizations. But you know, there was more people involved and a bit more rigor required as you can imagine, compared to sort of some of the freelance websites that I was putting together when I was 12. And after school I kind of had a choice to make where like by that point I had enough freelance work that it was sort of keeping me busy and paying the bills and you know, I could have gone and gotten an electrical engineering job, but I just, I just really liked programming, right. And one of the things that I like about software versus hardware is like the quick feedback loop, right? Hardware is just so slow. Like it’s fun to do things and it’s cool when you build something and there’s like a real physical, tangible thing in front of you, but to get there it takes so long. Whereas putting pixels on a screen is instantaneous, right. So that was kind of the direction I took. I did do a startup right out of school that involved some hardware stuff. And so it was a good kind of crossover. It was display advertising. So we had these like special units that, that I devised which embedded into mirrors. It’s kind of a long story, but it was kind of neat. And so they, they had sensors that would activate when you walked up to them and it was Like a graphic display that showed up through the mirror. Anyway, that was know, one of the first startups and then I was sort of continuing to do some consulting and freelance work. All along. I worked at a company that did software for the construction industry. Did that for several years. I was a CTO in that, in that startup. There was about 30 people in the company overall, so really small. But, you know, there’s interesting technical challenges focused on, you know, one of the things that we had to do in that startup was like synchronizing data between lots of different places. It was sort of like, you know, the core product was a mobile app, but it needed to have a lot of. It needed to share a lot of state between a lot of different systems. And so that was kind of an interesting technical challenge and interesting architectural challenges. Then I did a startup where it was kind of like, imagine if you could use Slack to send SMS and email to your customers as well. It was sort of like that. It was like a communication platform that was primarily around similar maybe to something like Front that exists out there. But anyway, this was for, for a niche market and ran that for a while. And that was, you know, that’s an interesting product. But, you know, somewhere along the line I had a friend who was working at Stripe, and again, like, kind of an Internet acquaintance, right? Not someone who I knew very well, but someone who I had, who I had met online and had some exchanges with. And you know, they said, well, why don’t you try working at Stripe? And so I definitely knew, knew about Stripe, right? I’d been using their, like, payment platform all over the place, but it never really occurred to me anyway to try to work at a place like that, largely because my assumption is like, well, I don’t want to move to San Francisco and therefore these things are not options for me. Right? But Stripe has actually always had remotes. And more broadly, the industry has obviously, you know, even prior to Covid, the industry was heading in that direction for, for a while and now that’s. That’s accelerated. So, you know, it was. Joining Stripe was awesome. It was lots of fun. It was sort of like a lot of the stuff that I’d been doing sort of on my own to try to build my own community online and whatnot was sort of replaced by this huge group of people that were exactly like me that all, you know, cared about all the same things in the sense of like, you know, both technology and sort of like caring about startups and, you know, the. What sort of makes startups tick. Like, one of the cool things about Stripe is that our customers are startups, too. And so everyone in the company is kind of wired to understand or try to understand, like, you know, what are all these companies out there that are trying to collect money online?

Alex: Right.

David: Well, why is that a hard problem and how we can make it better? Right. And so that was something that was, like. That I intrinsically understood and, like, valued. So, anyway, working at Stripe has been tons of fun. I started there coming up on three years now, and, yeah, that’s kind of been my path.

Alex: Awesome. I’m curious, you know, to learn a little bit more about your work as an engineer. You know, one of the questions that we ask is what are some examples or projects that you’re really proud of in your career? You know, especially when it comes to maybe staff or staff plus engineering, you know, does anything come to mind?

David: Yeah, I mean, I think all the most relevant examples would come from Stripe, because one of the things that I feel distinguishes staff engineers is sort of the extent to which we’re not only solving technical problems, but we’re combining that with sort of the organizational challenges that come along with it. You just don’t get that in a small startup. You get other things. Right. And we’ve talked about it a lot of times on the show how, like, in startups, one of the main sort of virtues that you learn as an engineer is this idea that, like, you have to take ownership over problems. Right. And so, but to apply that as a staff engineer in a bigger or rapidly growing organization is about more than just taking ownership of the problem. It’s also about understanding the levers that you have at your disposal to make it happen. Right. And like I said, it’s more than just technical. So I think one of the projects that I’m really proud of happened pretty early in my time at Stripe, where there’s a whole platform of kind of internal tools that exist at Stripe. And when I joined, those internal tools were, you know, pretty loosely structured. It was basically a service that people could add code to kind of whenever they wanted. You know, obviously we’re subject to the reviews and whatnot, but people could add code and build their own internal tools. And, you know, there wasn’t a lot of structure to it. There wasn’t clear ownership necessarily of. Of those tools, and there wasn’t. It was a little bit overly coupled in the sense that, like, you know, everyone’s code is going to the same place, and it was all tangled together. There’s lots of implicit dependencies and Things like that. Implicit interdependencies, I should say. And so one of the projects that happen in kind of my first year at Stripe was converting that into sort of more of a platform approach where it’s. Instead of having sort of a hodgepodge of everything all kind of tucked into basically one application, we split those out into separate apps that shared an underlying framework which we published and which we made available to, you know, other engineers in the company. So that when people wanted to build internal tools now, first of all they had, you know, some best practices established, they had good documentation, they had, we wrote a little bit code generator that basically got rid of all the boilerplate for them. And you know, the benefit to Stripe and to us as maintainers of the platform was that we got, you know, sort of more hooks into like sort of a, a consistent view into what was going on in the system. So, you know, first of all, everything was clearly owned. We had analytics that were separated by the different applications in the platform. We could better enforce security invariance because we sort of now had an understanding of how the functionality in the platform was split up and sort of which pieces of the platform were more or less sensitive and which pieces of the platform were being exposed to more or less users, things like that. So that was kind of, that was sort of one of the first cross cutting projects that I did at Stripe. And it was, it sort of was a good eye opener for me of like the, the impact that someone operating in sort of a staff capacity can have where it’s sort of like the main value that I was bringing to the organization was that I was mapping sort of a lot of the technical requirements and a lot of the organizational requirements that we had into, into something that kind of worked together and then like driving and following through on, on the migration of that because you can imagine there was, you know, hundreds of different applications in the end, you know, many dozens of teams that owned this code. And the whole system is business critical to Stripe. So it’s handling millions of requests a day. And we, we had to, you know, we had to kind of. I always liked the analogy of like turn the car into a plane while it’s running sort of thing. So yeah, that was one example. And you know, it’s, I think a lot of things have sort of mirrored that shape over time as I’ve continued to strength. What about you?

Alex: Sure, yeah, so there’s definitely lots of stuff that we’ve done at Stitch Fix that I would call like this kind of work. Like I’m still actively involved in a project to sort of migrate large parts of our customer facing applications to GraphQL. But there’s actually a project that I think is like, I think of as like my first staff project, even though no one. I didn’t have the title at that.

David: Point, by the way. That’s kind of like I think key. Right. Like I didn’t have the title at that point either. Right. You have to demonstrate that you can do the work.

Alex: Yeah, absolutely. And I, well, I think I did this work at the library services company. So I’m actually, I’m reading this book right now called Kill it with Fire by Marianne Belotti. And it’s amazing because it really speaks to this idea of working on legacy systems. And so just a quick shout out, like, I think I wish this book had existed when I started to do this work. But the library services company that I worked for had been an evolution from a journal publishing company that was one of the very first companies that would help you sort of keep track of a digital journal. And when I say journal, I mean like that in the academic sense. So like people would publish paper, there would be peer review and they would published the peer reviewed articles and they would do, they created a system that would allow you to sort of have these peer reviewed journals and do the whole peer review process, you know, online with email. And they were doing this in the late 90s and so they were pretty early for this process. In the early 2000s, you know, librarians and people who sort of like are very, you know, clued into the sort of scholarship realized that more and more of our scholarship was happening in digital first and it wasn’t happening in paper first. And that doesn’t mean that those objects are any less important than the things on paper, but that digital objects have a far more likelihood of just sort of like disappearing from the world because there’s no paper record. And this company, having been in a position to publish journals, realized that they could also now be in a position to, to create this new tool called an institutional repository where libraries and institutions could be like, okay, great, here is our digital scholarship that’s happening. I’m going to put it into a place and it’s going to be organized and it’s going to be secure and archived and hopefully we’ll keep it forever. So in like 20, I don’t know, sometime in like 2012, I guess 13, 14, they decided that they wanted to, that the system was sort of experiencing all sorts of issues and they wanted to do something and so they started doing some microservices stuff and they wanted to split out their Python stuff. They wanted to create a microservice with Python. And I joined the company around that time. Fast forward. Like I didn’t realize that sort of like not having a well bounded monolith was an important first step. And we published this, you know, this microservice of Python and it didn’t go well. Let’s just say that it didn’t go well. Like we ended up making something that did go well, but you know, just, it took multiple years of work before I was there. It. We had to turn it off for a month. So like this is a system that like people were using every day and for us to do the migration we had to turn it off. And still to this day it was like one of those. And we had only planned to turn it off for a week. Right, that’s the other part. So just like red flags everywhere, right. And I remember after having sort of done the hard thing, the thing that I didn’t feel really great about, I then had the opportunity to turn my attention towards the monolith, the thing that was causing all the issues. And it just sort of like I wanted to start working on it, I wanted to start making things better. I wanted us to be able to introduce better practices. Because at the time it didn’t have continuous delivery, it didn’t have like a test suite that would run. There was no sense of like a pull request or anything. And so like people were just sort of pushing code and they were pushing, they were manually pushing code to any environment that they chose, even production. They were like patching production. And I wasn’t certain yet exactly what was the biggest issue, but I knew that it wasn’t producing value and I knew that the engineers were having a really tough time making things better. Right. And so I just wanted to do something. And what I ended up doing was I ended up working on continuous delivery for this system that had never experienced continuous delivery before. Code was being pushed to an NFS directory and then they would restore all the servers so that they could pick up code changes. And it was just a whole different world. It took me a long time to figure out how to package a Perl application, to package things that never wanted to be packaged in the first place, to get the test to run inside of a container for this thing that never expected to live inside of containers. And it just took so much time and effort. And like at the end of it, to me, myself, I was like, I Was like, man, I only got continuous delivery done, right? I was sort of. I was almost like sad about that. And I remember one of the guys who had worked there for like 20 years, one day he sort of came over to me and he was like, he had heard me sort of bellyaching, I think. And he just started like, he was like, you know, before this, like once every three months, I had to come into the office on a Friday at like 5 o’ clock in the afternoon. I might be here until like 12 or 1 o’ clock in the morning, right, because we’re deploying code. And then for the next week I’m having to like, get all these developers to fix things and I’m patching production and then I need to make sure that you’re reapplying those patches back to the main code base. He’s like, now at one o’ clock in the afternoon, I can click a button and everything goes to production and it’s fine. At that moment, it was like a watershed moment for me. I was like, oh, I made it better for him. I made this massive stuff for him and now his job is more sustainable and he feels better about the work that he’s doing and that is going to have a huge impact on all the other software delivery that we do. And so that to me was like, I think, really important because now I sort of always. I’m always looking for the friction, for the pain points. I’m looking for those, the people who aren’t necessarily speaking up about it, but they’re sort of getting crushed by tech debt or all those other things. Because almost without fail, when I sort of make things a little bit better for the people who work in the system, it almost always produces better value for our. Whoever you’re trying to deliver value to. And so I think that’s an important part of being, as you move up in the IC ladder, just making sure that you’re looking at the humans in the system as well as the code and the tech and everything. And there’s lots of different ways to see that humanity in the system. But my way is to sort of make sure that no one’s getting sort of like incidentally crushed by it, that there’s no one who’s sort of feeling like, you know, that fight or flight instinct because of code, like, that’s just. We don’t have to be there.

David: Yeah, yeah. I think like one of the things you touched, touching on that is sort of really interesting to me about the technical leadership track is that, and this is sort of what I was curious about when we talked to Ashby about, about the relationship between staff engineers and product managers is like, so one of the things that comes up all the time when you sort of dig into what is a staff engineer is that there are people who are, like, identifying the work that needs to be done right rather than having it dictated to them. And how do you identify the work that needs to be done right? This goes back to sort of that ownership mentality, but it’s also. That’s combined with an empathy. Right. For all the users in the system. Right. All the humans in the system, as you put it. Right. And so to me, that’s like, that’s where there’s this overlap with product management, where product managers, the good ones, are thinking not just about sort of the end user, but like, what is the holistic experience of this product for anyone who interacts with it. Right. And I think the same is sort of true of good staff engineers, because that’s the only way that you can find the gaps in the system that needs closing is by. Is by. Under. Like, at the end of the day, all that really matters is the humans that are interfacing with the system. Right. Like, that’s. That’s what the system is. The technology is nothing in a vacuum. Right. And so. So, yeah, that’s. I think that’s sort of an interesting parallel that comes up again and again.

Alex: Yeah. So I’m curious, you know, moving on a little bit. One of my favorite questions that we ask our folks are like, you know, when you’re in an organization, how do you know that you’re in alignment with what that organization is trying to get done? And so I’m curious, how do you know that you’re in alignment with what your organization is trying to do?

David: One of the things that I don’t think we talked about as much in this show as I expected us to is some guests did touch on it for sure, but I’m having trouble thinking of specific examples is sort of the importance of, as you move up the IC ladder, the fact that the importance of your relationship with your direct manager and with your reporting chain increases. I think of my manager as a sort of critical partner in the work that I do. And that would be sort of the first sort of signal that I have as to whether or not I’m aligned with the organization. But that being said, my manager and I don’t always agree. Right. And so it’s also useful to have other signals and also useful to be able to look past that not in a sense of like working around my manager, but in a sense of like bringing more information to them. Right. Making sure that their view is holistic. And so the other things that I do, and this is all about sort of like how I gather information, which is different from sort of how I might try to influence the org. But the things that I try to do are, first of all, I try to maintain a personal relationship with other people in my reporting chain. So I’ll make sure that I like my, the managers above my manager all have office hours. And so I will avail myself of those, you know, not super often, but on enough of a basis that, that I feel like I know them and that I feel confident reaching out to them directly whenever I need anything. I also spend a fair amount of time. I forget some people have mentioned this, but it was, I think Stacy Gammon actually talked about this a lot. But the idea of sort of keeping a pulse on the org but having lots of one on ones with various folks, I have found the balance kind of hard to strike because I think it sort of depends what phase of work I’m in. Like sometimes it’s sort of. I really am trying to keep my ear to the tracks a lot. And so in those times I will sort of up the cadence of my one on ones or like just find more excuses to have more chats with more people across the the organization. And then sometimes I’m in more of a cadence where I’m sort of focused toward the team and toward execution. And in those modes I might sort of reduce the extent of one on ones that I’m having. But at any rate, one of the things that helps me is that I’m a little bit shameless. Like prior to working at Stripe, I was often sort of in founder or founder adjacent roles at startups and one of the hats that I had to wear a lot was sales. And so, you know, I’m a terrible salesman, but compared to most engineers I’m pretty good. And so, you know, that ends up being useful in terms of. Terms of sort of, well, like I said, kind of being shameless. Right. I have no compunction about reaching out to anyone in the organization for any reason and either making up some excuse to talk or just saying hey, like let’s chat. Right. And so that has been useful and, and I realize that there’s sort of like a bit of a. Some people are kind of self conscious about that approach and so there’s a bit of a barrier there which I sort of just got Rid of a long time ago, I guess, probably sometimes to my detriment, maybe. And I’m trying to think of what sort of. What other tactics there are, but I mean, honestly, it’s really just listening a lot. Oh. The other thing I do is I know people who lurk in a lot of Slack channels. To me, that’s too noisy. I can’t ever keep up with that. But I do work on a lot of mailing lists and Stripe uses mailing lists pretty heavily. And I have like a pretty intense set of filters in my inbox. And so I have sort of some systems set up for like, monitoring lots of email over time. And some days I just, like, I can’t get to it. I mark everything as red in, like, the. The labels where I’m not directly. Where I’m not directly cc, I’ll mark those as red and just like, you know, declare bankruptcy on them until the next day sort of thing. But a lot of days I end up sort of catching a lot of stuff that’s happening in the company. I definitely monitor all the. We have an incident channel. I definitely monitor all the incidents that happen across the company. We also have. There’s a cool convention at Stripe of sending shift emails, which is basically just like whenever you or your team does a thing, you send an email to the entire company. Really cool convention. And also a really neat way of having sort of a pulse on what’s happening around the org. So I always monitor those. They’re long and I don’t always read all of them, but I always sort of know what’s happening. And I also make a point, you know, along the lines of sort of maintaining relationships with people. If I ever see a Shift email from someone that I know, just a quick ping, like, hey, congrats, that’s awesome. Right? It’s very low cost to me, but it goes a long way towards sort of maintaining some of those relationships. I realize I’m rambling, rambling a little bit, but what I just said made me think of a conversation I had a little while ago where someone was asking. It was in a group context, but a small group. Someone was asking sort of why. Why would we spend, like, energy being nice to each other, right? And like, as I’m recounting it, it sounds like I’m maybe being uncharitable to that person, but that was like, basically literally what they asked. And I don’t think they were, you know, they were themselves a very nice person. I don’t think that there was sort of any malice intended in that question. But, you know, it’s a fair question, Right. I think in all seriousness, we’re trying to. The main reason that we’re at work is we’re trying to make value for shareholders or whatever you want to say. Right. And so, like, it’s a fair question, like, why do the shareholders care if we’re nice to each other? Right. But I mean, setting aside the fact that many of us are shareholders in the companies that we work for, I think, I mean, for one thing it just feels good. But also like besides feeling good, it helps with this, this thing that I’m talking about now, which is like, if you want to keep your ear to the tracks, if you want to make sure that people tell you when stuff is going on that’s relevant to you, maintain a relationship with them. And you know what, it’s a lot easier to maintain relationships with people when you’re nice to them. So I have found it just like have concrete value besides just making me and the people around me feel better.

Alex: Yeah, that totally makes sense, you know, to sort of build on that. We’ll put this in the show notes. I can’t find it right off the top of my head, but there’s an amazing sort of class you can take, like an online class. It’s like the Science of Happiness. And one of the things that they talk about is being appreciative, sort of like appreciating certain things in your life brings you happiness. And I think that when we think about that in the terms of how we interact with other people, being nice is a way of showing appreciation, it’s a way of showing respect. And so it’s not just, you’re not just being nice for them, you’re not just being nice for shareholders. I think we’d be nice for our own happiness, which is a very important.

David: Part of being nice for shareholders. That’s going to be the title of my first book, Nice.

Alex: I like it. Yeah. The other thing that I really like that you touched on is I think you sort of are describing what some people might call networking. It’s like getting to know more people. And I have found that networking is the easiest thing that you can do that has the biggest impact on your long term career. Right. And it’s not like networking makes it sound like this foreign thing that it is. It’s just like just saying hello up.

David: At a weird convention of business cards and wearing like a suit that doesn’t fit properly. Yeah.

Alex: That’s what’s funny is I think that I Think that some people see that. Right. And I think just being genuinely curious about people and, and introducing yourself and like being able to be able to call someone by name and say, hey, that’s what networking is, I think. And there’s a lot of science to prove that sort of like the loose connections in our life have some of the largest impacts on our long term outcomes. You know, you know, having close ties is very important too. But that sort of, that looser, that second order is really important. I think networking is a part of that.

David: Yeah. I talk to people, you know, on my team or people that, you know that are close to me at work who maybe have ask for advice. This is something that I touch on a lot. Right. I think it’s sort of underappreciated. The value of, of networking. Sure. Of building relationships and to your point about sort of having different degrees of networks. Well, I guess I actually have a lot to say on this stuff. So I’ll try to maybe summarize for networking overall. The experience that I had earlier in my career where I was like really isolated from groups of people with similar interests was actually really helpful because it forced me to get good at like being intentional about networking, you know, online and stuff like that. And nowadays everyone’s remote. But even before that, I always worked remotely. And so for me, like, you know, that ended up being really useful in terms of sort of being able to build relationships with my colleagues wherever they are in the world. And the other thing, like I mentioned earlier, that stripe was sort of like this, this like awesome opportunity for me to get connected to sort of an ecosystem of people that I previously didn’t have that much access to. I try to impress sort of like how valuable of a resource that is to folks who, to new folks that I talked to, especially remote people. Right. Where it’s like, you know, you might live in Winnipeg or in, you know, I don’t want to disparage any other city, so I’ll just say Winnipeg. You have access to, you know, a world class network of people in this company across the world and you can ping them on Slack, you can send them an email, like they would be happy to help you adopt you. Right. And so one of the things that I used to do religiously back when travel was allowed, I would, you know, I’d go to San Francisco every couple of months. But I would make a point of using that as an excuse to sort of reconnect with everyone across the company that I knew, not just people in my team. Right. It’s like, oh, hey, I’m, I’m going to be in San Francisco this week, like if you’re going to be there, right? Like oftentimes they were based there or sometimes they would also be traveling there around the same time, like, let’s make sure we grab coffee or whatever. Right. And that I would treat that as sort of my job while I was in town would just be to like, you know, don’t try to get any other work done, just make that social time. Right. And, and the other thing I would say is that like to your point about sort of the degrees of relationships that we have, I read a book a little while ago, Billion Dollar Coach. It’s about Bill Campbell, who is this like, you know, really impactful coach and Silicon Valley coached executives at Google and Apple and stuff like that. But one of the things that the book drove home for me is that like, I think I was maybe under investing in sort of the closer relationships, the closer professional relationships that I have. I was maybe like spending a lot of time on, of sort of the broader network, but under investing in the people that I work most closely with. And one of the things that that book prompted me to do is change the structure of my one on one. So rather than having, for people that I work really closely with, rather than having, you know, let’s say a bi weekly 30 minute, I am more likely to try to set up a monthly one hour because I can get way deeper with someone in an hour of like uninterrupted time every month than I previously could in sort of 30 minutes here, 30 minutes there. Right. And so anyway, all that to say that like, I think, I think those, those layers are worth thinking about. But that took me a lot longer to say than I meant to.

Alex: No, don’t worry about it, you know. Well, I think the last thing I contribute here, I think is the most powerful bit of networking I’ve ever done was that when I was working for the library company, I had a hard time finding someone who could explain to me the value proposition of what we were giving our customers. And I don’t think that’s uncommon in a lot of industries. Right. Like a lot of people sometimes find themselves writing software that they don’t always understand exactly the value proposition, especially in places where there’s huge domain knowledge that you may not have access to from the get go. And so I literally googled other companies that did what we did and I started trying to find people at that company and just sort of asked them. I was like, just could you explain to me what we do. And it was such. I was demonstrating such, like, a level of vulnerability because I was like, literally coming to them and being like, I don’t know what I do, but everyone was incredibly gracious every time I did that. And we hooked up with a whole set of organizations that I could then go to conferences and stuff and talk to the people, a lot of people who were doing what I did. And that was incredible. And so if I ever find myself working in an industry or whatever, or if you find yourself working in an industry that you don’t necessarily understand, conferences and other things like that are a great place to go and just sort of talk to people and learn more about what you’re doing. And I find that a lot of people are very gracious in those moments.

David: Yes, absolutely. And the approach that you’re describing of sort of being really vulnerable is exactly what I would recommend to anyone. And I know it doesn’t sound like it because I’m here pontificating, but in sort of my regular life, I really try to take a beginner’s mindset when I’m approaching problems. And I really try to be the person in the room who asks the dumbest questions. And back from my sort of startup days, there’s this sort of meme in the world of, like, startup founders who are raising money where, like, if you go to an investor and you ask for money, you’ll get advice. But if you go to an investor and ask for advice, you’ll get money. Right. And that is something that I’ve kind of taken to heart in my life in general, is that, like, most of the time, the best way to approach anybody is to ask them for their advice. Right. Because first of all, you’re likely to get advice. And advice is great. Right. I want to hear whatever people have to say, anyone out there, Right. Like, there’s always going to be a unique perspective. And secondly, you might even end up with more than advice. Right. So anyway, I’m really curious, though, Alex. Like I said, I’ve been hogging the mic for a bit here. I want to hear your answer to that question too. How do you handle organizational alignment?

Alex: Yeah, I really like the themes of one on ones like that you touched on. And this is actually something I talked a lot about in the original staff engineer interview I gave for the staff Eng website. What’s interesting is, even since then, I’ve sort of like, I’ve seen a new layer to my one on ones, and I think you touched on this too, which Is like sometimes, especially when I’m in sort of like seeking mode, like what do I need to work on, what do I need to fix? That is something where I will do lots of one on ones with lots of people to sort of get my hands around this problem. Because I don’t see myself as the best reducer of problems. Like I can’t see a problem and then reduce it to its components. And so what I do is I’m asking people really, I’m just sort of seeking out perspectives and it’s usually through other people and talking to them that I can start to see things that I couldn’t see before. And I can start to get like a real good understanding of the problem that I’m trying to solve. But then once I have that understanding and maybe people have explained to me some friction, they’ve explained to me sort of what’s going on, then I want to go and I want to like do the work somehow. And that at the moment I might sort of like wind down my one on ones. But I think that in general, like, I think a lot of people refer to this as sort of like a product oriented mindset or putting their product hat on. When you are trying to solve a problem, you need to make sure that the people that you’re delivering the value to are the ones who are giving you the feedback, you know, and the harder thing is like sometimes they’re going to ask you for things that may not be the best, you know, it’s just you have to really understand what they want, what they need, what the pressures are on them. So that when they ask for things that don’t make sense, you don’t immediately write it off, you know. But just because they asked for it also doesn’t mean that you’re necessarily going to do it. But having the relationships, having the product oriented mindset I think is what allows even engineers to produce valuable things that are in alignment with organizations, like wherever you happen to work. I think the other thing is I know that it’s really important to me to be in alignment with my organization. And I just sort of like, I shamelessly will sometimes just be like with my boss, I’ll just be like, am I doing everything I’m supposed to be right now? Right. Do you feel like I’m meeting my requirements and all that? And it’s not like I need him to be the only person to give me that answer. But like with certain people it’s just very valuable to get like a direct answer like, yes, you are no you’re not, you know, and build that relationship over time so that when you’re not in alignment, you know, and I think it’s important sometimes to not be in alignment. You can hear what they’re saying and you can then make decisions. You can say, oh, I didn’t know that I wasn’t in alignment, and I agree with you. Or you can go the harder route and you can be like, I think it’s important for me to do this, and here are the reasons why. And even though we’re not in alignment, what can I do to move forward with this project? Right. Because that’s where I think the most value comes through, in where you’re. You’re not 100% sure what you’re doing is going to work. And so having a strong relationship with your manager, with your, probably the team that you work on, allows you to know where you’re going to put those. You don’t get so many of those. Right. So, like, you got to make sure that those opportunities come along that you’re in at least alignment with some group of people that. So I think that’s really valuable is being able to just constantly be asking the organization, am I in alignment? So that you can know when you’re not in alignment and you can do the work that you think is important.

David: Yeah, I think you touched on a couple of really interesting things there. Like, for one. So one of the things I’ve observed with, you know, engineers who I think are really effective at this, is that the colloquialism would be sort of choosing your battles or like, you know, choose which hill you want to die on. But I think a better way to think about it is like an alignment vector has sort of multiple components, right? There’s the magnitude of the vector, but there’s also sort of the. There’s the direction of the vector and there’s the magnitude of the vector, I guess, like where the magnitude might be sort of like the how strongly you feel about the alignment or lack thereof. And so I guess not just feelings, but also like sort of what the impact of that is.

Alex: Right.

David: So there can be some things where I disagree really strongly with organizational leadership, but I also sort of can realize that really at the end of the day, the impact of them taking a different decision is not going to be, you know, I may strongly believe that it’s totally the wrong decision, but, like, it’s not going to affect anybody or anything. Or it’s like something that can be undone. And so in that case, it’s like, well, let’s not worry about that right now. Right. There’s other things, things to untangle. You said it really well. Like, we only have so many of those times where we can put up a fight. If you’re doing it all the time, no one’s going to listen to you. Right. And so you have to make your decisions. The other thing that you mentioned that I think is interesting is, like, the fact that it’s totally expected for people to be. Not be aligned. And not only is it expected in the sense of, like, oh, like people are going to be unaligned and then they’re going to talk and become aligned, but it’s also like, in a company, not everybody can be working on exactly the same thing, Right. So therefore, people are have to be heading in, like, different directions. Hopefully those directions add up to something. Right. You want to be going totally opposite directions, but you’re going to be pointing in kind of different areas. Right. And so, like, the analogy that a mentor of mine has used in the past is like, you know, people’s compasses are broken in different directions. Right. And, like, intentionally. Right. The company breaks people’s compasses in different directions. And so you’re going to have, like, you know, product people want to move, let’s say, really quickly. Right. Whereas infrastructure engineers move, might sort of have some concerns about how quickly the product people are moving because they want, you know, they’re very concerned about reliability. And then it’s possible that, you know, security engineers have a totally different perspective on this and they actually sort of would advise a different direction. Right. And like, all of those perspectives are valid and all of those are valuable for the company, but sort of how you combine them depends on a lot of factors.

Alex: Yeah, there’s this. I’ve been going down a rabbit hole for a couple of years into the sort of safety, reliability, resilience, set of knowledge that you can dig into. And someone who mostly runs sort of like classes and courses that you can take and not so much has written a book, is a practitioner. Her name is Martha Acosta, and she talks a lot about this thing called psychological capacity. And so it’s like built on sort of like psychological safety, but it’s also built on complex thinking. And what I love about a lot of the stuff that she teaches is that you have to find a way to hold all the perspectives and not find the one true perspective. And that ability to do complex thinking in organizations is how we build the capacity for the. As complexity grows, as it will in all organizations, holding all Those perspectives and making sure that they are represented, like there’s a full throated representation of them, and that you’re not just trying to wash them away is where you will gain the capacity for the next evolution. And so more and more that I sort of move away from, I think earlier in my career, I was naive in thinking that if you can get complete alignment, if everyone can be on the same page, that you’re somehow going to produce the best thing. And, like, sometimes that works in very short spurts, but, like, next year it won’t because you’ve created sort of like a monoculture. And so the work of incorporating different perspectives is difficult, but it’s necessarily difficult in order to produce a more strong outcome, you know, long term.

David: Yeah, that reads true. Switching gears again, kind of continuing along the path of the topics that we’ve often covered in these interviews. How do you think about mentorship and sponsorship in your work?

Alex: Yeah, I think, frankly, I think this is the thing I’m not as good at as, I think a lot of the people that we’ve talked to on the podcast. But I think the one thing I like to do is to make sure that I leave time for folks who have questions, who want to schedule time. I try to be very open, you know, with my schedule. So if someone has a question, you know, I let them know that they should always feel free to schedule time. But I, you know, frankly, I just don’t know if I’m that good at it yet. I want to be better at it. And that’s one of the reasons why I’ve been looking at things like the staff inch book. And the way I’ve really, really appreciated this podcast is that I get to talk to people who I think are better at it. And I think the biggest thing that I’m trying to do nowadays is focus more on what do they want, what are they looking for, what are their goals? And less like trying to be sort of like some pontificating professor trying to teach them some arcane bit of technology, which I think is a mistake I’ve made in the past. But you sort of, when they show up, I’d be like, what are you trying to get out of this? What goal are you trying to achieve? And just sort of work from that perspective, put them at the center. And I think that’s helped a lot, for sure. How about you?

David: I also don’t think it’s, like, really a strength area for me. It’s something that I’ve been working on. I’m fortunate that There’s. There’s a lot of people around me that, that I look up to and who have kind of filled mentorship roles for me. And so I think there’s, you know, I can learn a lot from how they’ve approached that and try to try to model that. I think one of the challenges that I have is that I’m a bit too quick to jump towards sort of suggesting solutions, and I’m working on sort of asking more questions and. And helping people that I talk to find their own solutions instead, which is really hard. So, yeah, I don’t think I’ve cracked that nut yet. So then, given that this has been sort of an opportunity for us to get mentorship, by the way, the other thing I’ll say is that I do think I’m a little bit better with sponsorship, and that’s a fun opportunity to sort of find areas where someone that I know in the organization could have impact and sort of recommend impact them for it. That’s a really fun one for me. I always enjoy doing that. I find it a little bit easier to do because it’s sort of less squishy than the mentorship. And so I’ve been able to do that and I try to do more of it. But anyway, moving on then. Since this has been sort of an outlet for us to receive mentorship from staff engineers that we respect, what are some of the takeaways from the interviews we’ve done that sort of were the most, you know, that had the biggest impact on you?

Alex: I think the number one thing that I learned while talking to folks is that there’s just a bunch of different ways that you can become a Senior ic. And that I think is really valuable because I think a lot of times we pattern match. We might, without even realizing it, have, you know, we have implicit biases. And so using this podcast as a way to sort of, like, remind oneself that there’s just a way, there’s a huge number of variations of getting to Senior ic, I think, is one of the ways that we can sort of combat any implicit bias that we might have around who we can and cannot become a Senior ic. So that’s really valuable for me. Is there anything any other takeaways that you have?

David: One thing that stood out to me, I don’t actually know if it came through in the interviews as much, but just the amount of humility that all these people have. Like, we talk to people who are extremely accomplished, and I look. Look up to a lot, and they would sort of be around the Interview sort of really be, you know, nervous about it or unsure, you know, that they’re the right person to be providing advice or like, you know, second guessing sort of the things they did say. And this would be sort of un. Often communicated to me privately before or after the interview or communicated to us. And you know, like, I think what that underscores for me is that, well, a couple things. So. So first of all, like, imposter syndrome is a real thing. Right. I also think, like, the pattern suggests to me that, that humility is in itself sort of an important attribute for senior technical leaders. And I think we don’t, you know, that’s not really celebrated in our culture. If I think about a lot of the most impactful staff engineers that I’ve worked with, staff plus engineers that I’ve worked with, they’re not really like very, very loud and outspoken. Some of them are. Right. There’s all sorts of different personalities out there. But it just sort of underscored for me this thing that I’ve talked about a couple times of like trying. And for me it’s kind of hard because my default is actually to be pretty self assured and sort of, you know, almost to the extent of being brash. And so one of the things that, that I’ve learned from the show and that I’ve tried to take away and try to sort of model in my behavior is like, take a step back, make more space, let more people talk, listen a lot more and just be humble.

Alex: Yeah. I think the other thing I was just thinking about that I feel like I’ve learned a lot is how many people focus on partnering and listen and like, not just sort of like giving folks approval, but actually listening and clarifying the value proposition and then using as many sort of like smart brains as they can to clarify the problem that they’re solving and to just continually push that and to make sure that they’re producing things that are in alignment with the organization, that the team is in alignment with, that their peers are in alignment with. And just sort of the high degree of cognitive complexity is involved, but you have to keep pushing through it in order to make sure that you’re actually solving problems that are valuable for the folks that you’re delivering them to. Sometimes it’s your customer, but sometimes that’s peers, sometimes that’s management. There’s all sorts of different groups that you’re delivering value to at any given point in time.

David: I think that’s actually a pretty core insight, is the idea of being able to recognize what’s valuable. Right. I think that’s sort of a theme that we’ve danced around a lot of times in these interviews. But you know, that’s not something that we learn in school, certainly not in computer science education. From what I can tell in my engineering degree we did learn, we did talk about sort of engineering economics, which is basically like understanding the ROI or the cost benefit analysis of a project. Right. But I think even that doesn’t really cover it because it’s not just about being able to do the analysis, but it’s about actually being able to recognize the areas in an organization or in a system where there is opportunity, where there is something that can be tweaked, where the cost is going to be less than the benefit.

Alex: Right.

David: And so, yeah, I mean, I think that is sort of an under discussed skill set of technical leaders. We’re getting close to time and you know, there’s the two questions. Right. So let’s do it. What are some resources that you would recommend to folks listening?

Alex: Oh man. I think what I’d start with is like there is still a lot of amazing stuff being published in sort of like blogs and stuff. And something that I haven’t seen a lot of people mention yet is using sort of like a feed reader. I highly recommend. Twitter is good, but like long form is also good. And so I still subscribe to anywhere I think between 100 and 200 sort of feeds from various things that just sort of like I love seeing new projects and like new takes on things. And so like I subscribe to a lot of like tagged resources, like what are all the new Ruby links? What are all the new JavaScript links? And because like sometimes projects will get announced that are really easy to miss, but they have like a really novel impact on something that you do every day. I think the second thing, the second big resource is, and this is really more of a jumping off and it might sound odd, but like one of the most important documents I’ve read in the last few years was the Etsy Debriefing Facilitator’s Guide, which is like a guide to how Etsy does sort of like incident debriefs, some people might call them postmortems and other stuff. Read that doc and then sort of use the sort of like citations in that doc and just keep going. Because understanding what they’re trying to do through postmortems and through incident analysis I think is an incredibly important window into the future of our work because things are only going to get more complex they’re not getting more simple. And every single one of us needs to become a systems thinker, I think at some point in order to do our job effectively. And postmortems are a really interesting way to probe complex systems. So I highly recommend reading that and then just sort of like continuing to simmer those ideas always. How about you?

David: I mean, first of all, those are interesting resources. I’ve actually heard you mentioned the Etsy document a couple of times and I haven’t read it yet. So that’s going to be somewhere I need to start. I’ll take it in the other direction though. I mean, I think, I think what you said is great, but I like sort of dead tree books and especially sort of older ones. Like, I think it’s interesting, it’s valuable for sure to sort of look ahead at where industry is going, but I think there’s also a lot to be gleaned from from what came before. One that I always really recommend to people that are interested in the technical leadership track is High Output Management by Andy Grove. And on the face of it, it’s a management book. Right, But Grove talks about in the book, I think he calls them know how managers, which are, he describes them as people who, you know, hold knowledge and disseminate knowledge within the company and, you know, identify work that needs to be done. But they don’t have direct reports. Right. And this is, you know, this is From I guess 20 or 30 years ago that he’s talking about that. But he’s talking about staff engineers, right? Or whatever. Like there’s, you know, these people have taken different forms and different times. But I think there’s a lot to be gleaned from that book and I think that, you know, there’s some interesting stories in it as well. Similarly, I’ve always been really interested in the overlap between the idea of like non commissioned officers in the military and staff engineers. I think like the idea of thinking about it. I mentioned before sort of the close partnership that I have with my manager and I sometimes think that that’s analogous to like the close partner that, you know, a sergeant might have with a lieutenant or something like that. I don’t know if I got those ranks right, but like, I think that that history is interesting. I don’t have like a canonical resource there, but it’s something that I’ve been digging into and you know, that might be an interesting thread for other people to pull on. And then the other thing I would say is like, you know, there’s a whole body of knowledge around things that are adjacent to our work. So, for instance, I mentioned how, like, my small, quite not accomplished background in sales has helped me in engineering work, and I think it would help a lot of other engineers. And, you know, that’s a field where there’s. There’s a ton of stuff to read. Two that I might point people toward is like the, you know, Dale Carnegie, how to Win Friends and Influence People. It’s like, terribly annoying title, but. But it actually probably can help. Some people just don’t, like, repeat someone’s first name 12 times in a. In a conversation, please. And then also there’s a book called Influence by Robert Cialdini. I don’t know if I pronounced that properly. And it’s maybe a little bit like, malicious. It’s kind of like a social engineer’s guide to persuading people to do things. But there’s sort of some interesting tidbits there. And, you know, I think for people that are sort of wired, like we are thinking about human relationships in terms of systems isn’t necessarily the worst idea for sort of getting a head start there. Yeah, I think that’s my list for now.

Alex: Nice. Yeah, there’s always more books, so I.

David: Guess that brings us to the last one. You saved the percentage till now. How much time do you still spend coding?

Alex: Yeah, I was thinking about this. I think it’s between 25 and 50% of my time, you know, and it just varies week to week. You know, like some weeks I feel like I’m writing a lot of docs, breaking projects down, trying to organize, you know, trying to talk about where we need to go in the future, try and influence where we’re going to go in the future. But there are still times where I’m getting down and writing code, and that’s still so satisfying when I, like when I fix a thing or I push some code out that I’ve been working on for a long time, I still find it’s like almost the easiest thing to get satisfaction from. And that’s maybe a problem. How about you, David?

David: No, I totally get what you’re saying. I have been in an unfortunate mode at work where the only coding that I do is like, is like when I’m hoisted by my own petard because I wrote something a long time ago that no one else can, can, can or wants to sort of take the time to fix. And so I have to fix it. I’m dealing with one of those right now. It’s been dragging on for weeks, so maybe I’m over indexing on that. But beyond that, I don’t really get to write a lot of code at work lately. And that fluctuates. Sometimes I write more than other times. I would say maybe averaged across the year, probably 10% of my time these days. And so I have a side project that I use just to, just to like, not only write code, but also sort of like remind myself that I can build things and ship them quickly and like, you know, sometimes inside organizations, you know, like the, like I said, the problems aren’t always technical problems and it’s, it can sort of be a little bit, it can bog you, it can feel a little bit like it’s bogging you down. Right. And it’s like, for me at least, my instinct is sort of then to sort of start second guessing what I’m doing. Right. Like, you know, why is this so hard? Am I approaching it wrong? And so it can. I get a lot of satisfaction out of like, you know, doing something in a weekend or whatever here and there when I can.

Alex: Yeah, I. For what it’s worth, I’m the same way. I just recently wrote a whole bunch of code to like create a book layout from a bunch of all like, like extracting notes from my note taker and then like, oh, cool. Introspecting a private SQLite database and then converting it into markdown and then producing like a 1500 page PDF and it’s incredibly complex, but, you know, it was like one of those things where like the tools just didn’t do what I wanted and you know, so you break out the tool set. I know how to write code and you just start going down that path and it reminds you of like, what you. I think for some of us, not all of us, like what brought us to this space in the first place.

David: Yeah, I think now we’re kind of going on a tangent, but that’s okay for me anyway. Well, you mentioned like, that’s, that’s what brought some of us here. And I think it’s. I’m sure there’s people out there where. That’s not why. Why they’re here. And that’s fine. I don’t mean to disparage them, but like, the engineers that I get are the ones who sort of view programming as a superpower. And you know, that’s why in our industry there’s sort of a lot of concern about like filtering resumes by people who have side projects like that. I think that’s totally fair. I know I’m about to become a dad, I’m not gonna have a lot of side projects, right? Like, that’s. That’s expected, and people go through different phases of life. But, you know, I’ve never. And again, I’m not saying this is wrong, but I’ve never understood the mentality of people who, like, don’t want to find projects. Like, to me, it just. It’s just like, you have this amazing power at the end of your fingertips. Why wouldn’t you want to use it, you know? Anyway, I digress.

Alex: No, not at all. I. For what it’s worth, it’s one of the things that I think that I got the most wrong. I actually wrote a blog post a long time ago, and I wrote some title, like, you know how two kids in two years is, like, my superpower? And I wrote it and I read it last year, actually, and I was like, who is this person? I don’t know who this person this is. And I was like, I actually talked to my wife. I was like, do I delete this? Because, like, I don’t agree with this at all anymore. And, you know, I talked to some other people, and they’re like, you know, good URLs don’t die. And I also agree with that. But I was like, but I don’t want anyone to stumble upon this and to get the wrong idea. And so I deleted it. And it’s just. I think you have to. I think what’s really important to know when you’re doing side projects is are you doing them because of sort of, like, hustle culture, or are you doing them because you’re having fun? Right.

David: Yep.

Alex: And that, to me, is always the main thing. It’s like, if you’re having fun, great. If you’re doing it because you feel like this is the only way to progress forward, you know, fine, as long as you’re having fun. But, like, if you’re, you know, just, like. Just really pay attention to, like, why you’re doing that thing, I think, and make sure that it brings you value somehow.

David: Yeah, I think. I think that’s a really good point. And I mean, look, like, hey, I have lots of other hobbies, and I think other people have lots of other hobbies, but one of my core hobbies is programming. Right. And it’s just like, I kind of acknowledge that about myself. But I think you’re right. If folks out there are doing it because they think they need to, then that’s definitely no good.

Alex: Yeah. Well, all right.

David: So with that. Oh, my goodness. This is. Oh, man. Tearful goodbyes.

Alex: Well, I really appreciate. Just like, you know, I really. You should put this in there. But, like, I, I think that this would not have happened without you. You put so much time and effort into this. You got all the guests like, well, most of the guests, and did all the work. So I really appreciate that you let me sort of hitch along for the ride. I really appreciate. I’m glad about what we’ve created, and I think it’s been a great experience.

David: I had a ton of fun. I’m really glad you came along for the ride. Thank you for doing that. And until the next podcast, Sa.