Josh Kaderlan (Lob)
Today’s guest is Josh Kaderlan, Staff Software Engineer at Lob, a direct mail and address verification API company that automates and simplifies direct mail and address verification, giving businesses greater flexibility, visibility, and accuracy of offline communications and data. There are so many different and non-traditional paths to becoming a staff engineer and, in today’s episode, you’ll hear a bit about Josh’s; starting in quality assurance, moving into development, and ultimately ending up where he is today, which he attributes to his wide breadth of knowledge and the valuable lessons he learned along the way. We discuss why Josh considers himself a generalist, the role that incident management plays in his work, and how he influences his peers by cultivating authentic relationships. Most important to Josh is how the work he does improves the experience of his colleagues and provides value to customers, and he shares some of his tips for staff engineers and organizations looking to have a similar impact. Tune in today to learn more and receive some practical advice and resources!
Links
Listen#
Transcript#
Note: This transcript was generated using automated transcription and may contain errors.
David: Welcome to the Staff Eng podcast where we interview software engineers who have progressed beyond the career level into staff levels and beyond. We’re interested in the areas of work that sets 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 Kessinger. We’re both staff plus engineers who have been working in software for over a decade. Alex, please tell us a bit about today’s guest. For sure.
Alex: Today’s guest is Josh Katerlin. Josh is a staff software engineer at lob. You know, there are so many different paths to staff engineer and Josh is no different. Starting in qva, he eventually moved into development and is now staff. This is a great conversation, so let’s get into it.
David: All right, well, Josh, thank you so much for taking the time to chat with us today. Could we start by just kind of having you tell us who you are and what you do?
Josh: My name is Josh Caterland. I’m currently a staff software engineer at lob, a print and mail and address verification API company.
David: For listeners, it’d be helpful to sort of have some background on sort of where you’re coming from, how you ended up at Lob, and then we can dig into a little bit of like what you’re doing at lob.
Josh: How I got here is a very long and twisty story. I don’t have any formal background in software. I got my undergraduate degree in French language and culture, which actually did provide me with my entry into the software industry. I’ve been in the industry for more than 20 years at this point. Got in back in the. In the dot com days and a friend of mine was working at a company that had a contractual obligation to provide tech support, email tech support for its product in French. And he knew that I spoke French fluently and he knew that I had an interest in computers even if I didn’t. Like, I wasn’t a programmer at the time. I had never like taken any CS classes in college or anything like that. And it was the dot com boom. So like, right, you could pretty much show up and say, yes, I know how to turn on a computer and get into the industry. And yeah, so that’s how I got into the industry in the first place. Did not have any intention of making a career out of software. I was just kind of like looking for the next thing. Not really looking for a career, but I discovered that I really like the industry. I Like the freedom. I like not having to show up at work exactly at 9:00 every morning. And I was like, you know what? If I can work someplace where I can do that, then this is the right industry for me. And so over the course of my time at that job, I learned more about testing, about qa. When I left that job, I went in, I was like, you know, okay, the industry is like, clearly the right place to be right now, so go get a job as a QA tester. So started doing black box testing as I went through that. Like just kind of like learn more and more about technology, about computers. Basically started teaching myself more of the tooling that I needed to make my life easier as a tester. And that was basically kind of like my entree into. Into programming per se. And so, like just over the course of my career, kept kind of like teaching myself more stuff. Getting further and further and further away from customer qa, moving further closer and closer and closer to product development, a long, slow progression through the various roles, and closer and closer and closer to product work.
David: That’s fascinating. I think something that Alex and I have observed over the course of doing this podcast is that non traditional paths are actually. I don’t want to say that they’re common, but they’re not uncommon for staff engineers. And I think part of it is that it gives us a bit of a more holistic view. Right. Like, I’m sure that your path through QA and customer support gave you sort of a different perspective than folks that are coming up through the engineering organization entirely.
Josh: I’ve had this conversation with co workers and friends. The thing that makes me a staff engineer is not that I have any particular knowledge, it’s that I have a really wide breadth of knowledge at this point. I’ve worked in a whole bunch of different environments. I have built the habits of teaching myself and diagnosing problems on my own, teaching myself how to solve them, teaching myself how to program. I really do attribute where I’ve ended up now to having followed that path.
David: Yeah, and I like that you’ve got the French degree too.
Josh: We should stick to English. I’ll sound better.
David: Yeah, fair enough. I think we may is Alex. I’m not sure unless Alex has some hidden French skills somewhere as well. And the other interesting thing is, you know, a non CS degree. I also don’t have a CS degree minus electrical engineering, so, you know, at least kind of adjacent. Alex, do you have a CS degree?
Alex: No, I don’t have a degree of any kind I have 9/10 of a broadcast communications degree is what I.
David: Awesome. That’s what I thought. I mean, I didn’t know what you had, but I didn’t think that you had cs. And so this is sort of consistent with what I’m saying is that I think people come up through a whole bunch of different backgrounds and get exposed to a lot of different things and it sort of helps in that role. So all that to say, like, how would you sort of describe the staff role?
Josh: If you think about the archetypes, Will Larsen’s archetypes of staff engineers, I actually forget which one it is. I think that the one of them is generalist, right?
Alex: Yeah.
Josh: That’s generally what the staff engineers at LOB fall into. That’s certainly not the only archetype that we expect people to fill. But if I were like characterize the people who are staff engineers now, that’s what I would say.
Alex: Cool.
Josh: The work really is basically. Honestly a lot of what I’ve done is been able to kind of drop into various projects and push them along either like through my own work or in working with other developers to kind of like get the projects moving along. So it’s in a lot of ways lately it’s been more technical work. That said, for the first period of time that I was at lob, really what the team needed was a lot of mentorship and a lot of guidance in learning how to be a developer and learning how to level up as developers. And so I wasn’t doing primarily technical work at that point. I was much more coaching and just kind of mentoring.
Alex: Cool. When you approach your job, you talked about how lob, a lot of the staff engineers take sort of like a generalist approach. Is that how you feel like you also approach the staff engineering role at lab?
Josh: Oh yeah. It’s funny, like, if you talk about like the staff engineer should be T shaped, I wouldn’t even necessarily describe myself as T shaped. I’m more just kind of like flat. Even before I became a staff engineer, the way that I described myself was I’m a full stack engineer, which means that I’m equally incompetent at all levels of the stack. And that really is what it is. The way that I think about it is the value that I bring is that I can drop into any situation and come up to speed relatively quickly and make sense of a system that I haven’t necessarily seen before. I would never like present myself as the person who’s going to solve like the naughtiest technical problem. That the company has. But, and this goes back to what I was saying before about, like, the breadth of my experience being, like, the thing that makes me a staff engineer. I have the confidence that I can take a system that I’ve never seen before and figure out how it’ll work. Can’t necessarily guarantee that I’m going to do it quickly, but. Right. I will be able to figure out how it works. I know how to search slack. I know how to search notion. I’m pretty good at googling at this point. And so, like, some of the work that I do is like, sitting there and like reading through, you know, git histories and trying to figure out what was going on there. But honestly, a lot of it is just like digging back through the wikis and going like, okay, what were people thinking when they first started, when they first built the system? What breadcrumbs did they leave me so that I can figure out what this thing is supposed to be doing?
Alex: Yeah, when we talk about, like, the general scroll like you talked about, like, there’s just all sorts of things that you do and you’ve mentioned sort of like doing some technical work, but coaching and mentoring. Are there other kinds of work that you take on that you feel like wouldn’t fall into those buckets?
Josh: Absolutely. One of the big interests that I’ve fallen into over the last few years is incident management, incident reviews, incident analysis. I was very fortunate at my last job to work with some of the people who, like, helped bring the whole notion of incident management to the industry in the first place from the firefighting community. I was fortunate enough to be trained by people who have backgrounds in both IT and firefighting. And so I learned a lot about how that works. And it was one of those things where it’s like, when I had the training at my last job, I was like, where has this been my entire life? This has been. This has been the thing that I’ve been, like, looking for my entire career. So when I came to lob, we didn’t have a super formalized incident management process. And so a lot of my work there has been to evangelize that, to like, honestly, I’ve commanded a ton of incidents just because I am one of the most experienced engineers in the company. I’m one of the most experienced incident commanders in the company. And even though I’ve never formally worked in an SRE role, I bring a lot of that perspective to the work that I do. So that’s been a huge part of the work that I’ve done there.
Alex: That’s interesting. I’m curious. I think a lot of folks, when you say I learned something from IT and firefighting, they might ask, what could you learn from firefighting that would apply to being a software engineer? Could you explain a little bit more about what you mean there?
Josh: Sure. The thing that I really like about the incident management system, which is a thing that was basically, it grew up out of the firefighting community in Southern California in the early 70s. It’s basically a lightweight structure and process for handling unexpected events. Not just unexpected events, but basically like emergent events. If you think about outages that you’ve been in or high priority bugs that have come in from customers or that sort of thing, in my experience, it really helps to have some sort of a structure to the response. Right. In exactly the same way that if you’re doing a sprint in an agile framework, you generally assign roles that people are filling. You have somebody who’s responsible for being the scrum master, you have all those sorts of things. It can be really, really beneficial to have that sort of structure in an incident process. You have basically the people who are responsible for the subject matter, experts, the responders, the people who are responsible for actually fixing the problem. Incidents are really stressful. Incidents are really cognitively taxing. And it makes sense to me at least to free up as many of their cognitive resources as you possibly can to focus on fixing the problem, not focus on things like making sure that the status page is updated, making sure that stakeholders are informed, making sure that like they’re driving the entire process forward. And that is very much what the incident management system is designed to do. It’s designed to break out the roles that people tend to normally fall into in that sort of a situation into slightly more formalized roles with defined responsibilities, and then just give people the support that they need to be able to work the problem without having to worry about all the other stuff.
David: Can you give some examples of an example of a typical thing that you might be involved with at lob? And I’m curious about that, but I’ll ask a twofer. Can you also sort of describe how in practice that incident response kind of plays out? Like, so, for instance, at LoB, to whatever extent you’re comfortable sharing, like, how is the incident response process defined? And like, what are the steps and who are the participants, etc.
Josh: There’s a certain amount of discussion around this, so I hesitate to speak for, like, how incidents work in general at lob.
David: Yep.
Josh: I can certainly like articulate what I have laid out the way that I tend to run incidents that I’m part of. I mean, I will say that one thing is I am generally way more aggressive than most people I’ve met about declaring something an incident. One of the things that I did take from the firefighting, like from having been trained by firefighters, is the notion that if you smell smoke, pull the fire alarm. Maybe it’s just like somebody burned something on their stove. But like, the firefighters are there, their job is to respond, is to respond to fire alarms. So if you’re not sure, pull the fire alarm. They’re used to running that process. So like, they’ll get their, their gear on, they’ll roll out, they’ll show up and maybe they show up and there’s, oh, no, wasn’t actually a fire. If it was a fire, though, better to have the firefighters on site right then rather than like, oh, wait, no, the entire building’s up in flames now. I did lay out, you know, basically like a relatively lightweight playbook for what an incident process looks like. Basically, we have a mechanism for getting each incident like a unique identifier. It’s pretty straightforward where you create a Slack channel, usually set up a zoom bridge so that people can coordinate in realer time than trying to do things in Slack, Just this higher bandwidth mode of communication. And I personally generally tend to take a more formalized, somewhat more structured approach to it than other people do. So I’m pretty anal about like appointing an incident commander, outlining who the responders are and what their roles and responsibilities are in the process of responding to the incident. And then it’s just, honestly just a matter of sitting down and working through the problem, like, right, sizing it up to figure out what the actual impact is, who’s affected by it, what the urgency of the issue actually needs to be, and then making sure that you’re propagating that information back out so that people aren’t sitting there going, wait, what’s going on? So part of the reason that this ties back into what I consider the work of a staff engineer is the way that I can consider the role of an incident commander is really, honestly, in a lot of ways, kind of a support role. The thing that I focus on when I’m an incident commander is reassuring people it’s important to have a sense of urgency because, right, like there’s a reason that you declared an incident because that means that something has, in this case, something has gone wrong. But these are also things that happen in software systems, like failure is inevitable, things will break. And it’s really important to me to let people know that they’re not alone and that there are other people who are there to support them, there are additional resources they can bring in if they need it, and to just keep pushing people along in a gentle fashion. One of the other roles that I see an incident commander fulfilling is like basically kind of herding cats, making sure that the conversations don’t rat hole, making sure that basically everybody’s keeping their eyes on, like, what we can do to mitigate the issue as quickly as possible, pushing people to consider alternative solutions. And that’s a lot of the work of a staff engineer is, in my view, it’s just the timelines are more compressed and as a result the pressure is a bit higher. But it’s fundamentally very, very similar to me.
David: Beyond sort of working toward instituting an incident response program or changing the incident response program at lob. What are some other examples of like, projects that you would drive or things that you might be asked to parachute into, etc.
Josh: At this point I probably have. I’m one of the people who’s got the widest range of knowledge about like the entire system. So honestly, a lot of what I do is just kind of answer questions on Slack. A lot of it really is just connecting people and being able to say, like, oh, hey, you’re working on this problem. This other person was working on this problem previously. You two should talk so you don’t duplicate work so that people get credit for the work that they have done in the past. If I think about like specific projects that I’ve worked on, honestly, a lot of it has just been reducing toil. We used to have some stuff that was a very manual process. Basically when things would fail, we would have to remediate them manually. And we had the framework to do that work automatically and redrive those things back through the system so that they would work again. And so a lot of it was like, I wasn’t even writing code. I was like teaching myself Docker files and like writing a Dockerfile, moving things from one environment to another.
Alex: I think it’s really interesting, the projects that we’ve talked about so far. So you’ve talked about sort of like driving an incident response and then also reducing toil. And both of those things are really curious because it’s hard sometimes to describe the value of reducing toil and incident response in a business context. And so I’m curious given sort of those things that you’ve chosen to take on how Are you making sure that the work that you’re choosing to do is aligned with your organizational goals? And how do you describe that to the organization?
Josh: To be honest, that is probably the part of the job that I’m weakest at. That is definitely something that I need to get better at. A lot of what motivates me is just wanting to make work better for my coworkers. Again, this is another one of those through lines throughout my career. When I think about the first software project that I ever built, built like really kind of on my own initiative. It was. I was working at Symantec. I was working on the anti spam product. At the time, we had a software package and then we also had an appliance that you could buy. So like back in the day when like, literally you buy, you would buy the hardware that had the OS installed on it, it had our software installed on it, and you could buy the full package from us. And so what that meant was that the nightly builds for testing were not just the software package, but like the full OS install. And when I got there, the way that you would install a build is you would download the build to your machine, you’d burn it onto a cd, you’d go into the server room, you’d stick the CD ROM into the drive, and then you’d stand there and you’d like, right, have to stand at the console and like, go through the whole installation process. And server rooms are not fun places to be. It meant that, like, if we had a build that a whole bunch of people needed to install, like, right? There was only one kvm. So you had to like, coordinate who was going to get access to the KVM when it also meant you couldn’t work from home. If we had to do a build on the weekend, like, you had to actually physically come into the office. So a lot of times what people would do is like, one person would go into the office and like, do a bunch of installs for other people. My girlfriend at the time was a large installation system administrator. She was working on like installing oss and software packages on thousands of machines at a time. And you don’t do that by burning installs to a CD and then going into a colo somewhere. In talking to her about how she was solving that problem at her job, I realized that I could take that same functionality, right, like it was pixie boot to machines and give a networked location that you was going to pull down the image from. And right, like the machines that we were using had the functionality Built in to do all of that. And so I taught myself how to write boot scripts to do that. And I built a little Django application so that you could like self serve, like subscribe your machine to the system and then go in and you know, like from the drop down, select which build you wanted to use, which machine you wanted to install it on. Right. Do all that sort of stuff. And you could do it all completely remotely. And it was really motivated by reducing toil, making everybody’s lives easier. Like, if nothing else, it was just a quality of life improvement for everybody at work. That really is the through line I’ve taken through like my entire career. And the problem is that, right, like, that is kind of a difficult thing to articulate to management and to leadership. It’s one of those things that everybody recognizes it when everybody’s happier and like, oh yeah, this thing works and it’s really great. But like, if you were to go to leadership and be like, I want to make everybody’s life 10% better, that’s not like a super easy sell. And so that is honestly something that I’m still working on is figuring out how to articulate that as far as the incident management goes. One of the things that I really do that I have a much better story for, because in my experience, leadership often gets every company that I’ve ever worked at, every company that I’ve ever talked to people who’ve worked at. When there’s an incident, leadership gets nervous, right? By definition, you were defending business value at that point. You were not growing business value. You’re either defending it or losing it. So that’s a stressful situation for leadership to be in. Also, a lot of times leadership doesn’t necessarily know what’s going on. They may not necessarily find out about the fact that there’s an incident from an internal process. They might find out about it because, you know, like, they’re trying to do something on the website and they’re like, wait, that’s not working. Or they see something go up on the status page. And so from my perspective, the way that I articulate the value of the incident management process is this is a way for leadership to get informed about what’s going on and to keep track of things while at the same time giving the people who are working on solving the problem the space that they need to solve the problem.
Alex: Yeah, that’s really interesting. Is it safe to say that you, you sort of become like the interface by which the business speaks to engineering almost? And maybe that is like A function of staff engineering is that you can go both ways.
Josh: Oh, absolutely. That is, yes. Again, it’s the same thing. Like, right, if I’m commanding an incident, right. I need to talk to customer support because A, I need to find out like, what’s coming in from them, are they getting customer reports about these issues? And B, I need to work with them on like, what the messaging is going to be around a particular thing. And yeah, it’s exactly the same work that I need to do as a staff engineer. Right. Like, engineering doesn’t and can’t exist in a vacuum. Engineering exists to provide value to customers.
Alex: Yeah.
Josh: And if you’re not talking to the other parts of the business, you don’t know how to provide value to customers.
Alex: Right. Yeah. Going back to your story about making things better for engineers, I find it striking because it’s, I think, an example I’ve heard a lot where it’s just like, this thing sucked and someone was like, well, if I take these three things that I just learned about and I put them together, I might make it better. And then you do. And then I think there’s like this collective sigh of relief, like, oh man, that’s so much better. But like, it’s just, no one really talks about it. And so sometimes in those situations, I wonder if it’s just like the affirmation that you’ve done something valuable is your continued employment at the company.
Josh: That is absolutely true. Yes.
Alex: Because you took a bunch of time, your time, company’s time. You did something, you know, you did an experiment, you took a risk and it paid off. And no one was like, wait, why did you waste three months or something? Because you didn’t, you didn’t waste three months. You made things better.
Josh: Right. That’s the other thing. When I think about how you take satisfaction as a staff engineer. This is a problem that managers face. This is a problem that you face. As you go further and further up any ladder. Your role in particular situations often gets more abstract and more indirectly. It gets increasingly difficult to articulate the value that you bring. And I personally fundamentally think that it’s a failing to take a lot of credit in a situation like that. And so the satisfaction that I take and the value that I take from my job is really like seeing that people’s lives have gotten better or seeing that things suck less for people, rather than like really explicit validation in the form of props in a public channel or like recognition at an all hands or something like that. I don’t think that it’s Realistic to expect that those sorts of things will get recognized in quite that way. And like I said, I also do think that like to the extent that you’re looking for that sort of recognition, it’s going to lead you to not work on the right things.
David: So what we’re seeing is that the extent of recognition the staff engineer should seek is to not get fired.
Josh: No, I will say I’ve had co workers say included incredibly like personally meaningful and touching things about the ways that I have helped them and the ways that I have like shaped the perspectives that they take on things that like that is really like the most gratifying thing to me just to. There is a message that one of my co workers, a little speech that she gave at my one year anniversary at the all hands last year that I still have saved because it was just like it was one of the most touching and gratifying things that anybody’s ever said about me.
David: Wow. To be clear, I’m of course being.
Josh: Facetious, but I get earnest about this stuff.
David: I do think that it’s interesting when I up level to staff and when I sort of started to get interested in discussing the staff level with other folks, I realized that like a frequent topic of conversation was sort of like performance reviews. And I thought that was sort of concerning. I’m like, is the reason that all these people have gotten to this level because they’re laser focused on getting good performance reviews? In fairness, maybe there’s an aspect of that, but I think there’s also or the causation might be reversed in the sense that I think what we’re touching on here is that it can be really hard, as you put it, Josh, to articulate the impact that we’ve had in the organization. Right. And in that case, especially for staff engineers that are joining a new organization or that have a new manager or something like that, the concept of performance reviews becomes pretty daunting. It’s like how do I show the impact that I’ve had? Right. So anyway, I think that’s kind of an interesting thread switching gears a little bit though. You’ve talked a bit about. It’s not your strength, but sort of how do you influence upward within your organization? But I think sort of the, the corollary is how do you influence your peers and the people that are in lower levels of the organization? Especially as a staff engineer, we’re not endowed with organizational authority. And so there’s to a certain degree we still get some of it, but I think there’s a lot that we have to do by just influencing people, convincing them that our ideas are good. And so I’m curious how you go about that.
Josh: Fundamentally, this is all about building personal relationships with people. That is really the key to me is being able to build an authentic personal relationship with someone and an authentic personal relationship in, like, the context of work. Right. Like, I’m not talking about, like, everybody’s got to be best buds outside of work or, like. Right. But within the context of work, it’s important to take people seriously as people and to respect them as. As humans, regardless of where they are on the corporate ladder, you know, like, how much experience or how little experience they have in the industry. Right. Like, you need to take everybody with that baseline level of respect and really be willing to listen to what they have to say. There are a few different ways that I approach that. One is when I present ideas, when I, you know, kind of talk through problems with people, I am very, very, very explicit that I don’t have all the answers, that there are cognitive blind spots that I have, that there are things that I don’t know about, and that to the extent that people are just like, oh, yeah, Josh is going to go off and do the thing and, like, it’ll be great. I’m like, no, it’s not going to be the. It’s not going to be that great. I can’t do the best work that I can do completely in isolation. Right. I depend on my co workers. I need their help to get us all to the best solution for the problem. That’s definitely a challenge with more junior people. A lot of junior people feel, in my experience, like, that they’re not necessarily qualified or, like. Right. They don’t feel comfortable with the idea of pushing back or even just articulating their opinions about something. But it’s constant work to reaffirm that. I want to hear what they have to say. Another part of it is I started up a n random channel in our company, Slack, because I wanted to. I mean, like, honestly, I just wanted a place to, like, share dumb jokes that wouldn’t make sense to people who, like, didn’t spend all their days programming, you know, like, technical articles that weren’t necessarily specifically relevant to the jobs that we’re all doing. Part of the way that I have leveled up over the course of my career is, like, I read about this stuff, like, for fun, you know, just like, kind of building that habit of, like, periodically, just like reading a blog post, even if. Even if it’s not about something, not about Anything that I ever expect to be dealing with in my current job. There are definitely been situations where it’s like years later I’m in a different job and I’m like, hey, wait a second, I remember I read a blog post in like 2013 about this thing. Let me go find it. So I started up the Enderandom channel so that I just have a place to put that sort of thing. I started up an engineering book club at work. It’s really, really, really valuable in my experience to have some sort of venue to share information that’s not in a like strictly task oriented fashion. Right. It’s not you are trying to accomplish this one specific thing. It’s just, hey, this industry that we work in is kind of cool sometimes and like people are doing some really interesting things. And like, sure. Like did I ever expect that I was going to necessarily need to know about like how databases were implemented at the file system level? No, not really. But it turns out that it’s actually kind of relevant to stuff that I’m working on now. Doing those things, like I said, that are not strictly task oriented. Being willing to just talk to people honestly. The other way that I do it is pairing. Pairing or mob programming is a really like, honestly, fundamentally the best way of teaching that I’ve ever found. It’s just really valuable to get on a zoom call sometimes with somebody and like just work through a problem together. Especially now in Covid times when like everybody is remote and like sometimes you need to see somebody else and like feel like you’re not alone working on the problem by yourself.
David: Cool. There’s lots that I would dig into there, but we’re getting close on time. Kind of two questions that we try to ask everybody. And the first one is for someone who’s sort of interested in either becoming a staff engineer or who is already a staff engineer but who wants to be better at it. What are like the resources that have influenced you or that you would recommend? So that could be like people or it could be, you know, blogs, books, podcasts, et cetera. Where would you point folks?
Josh: The places that I generally go. I do find hacker news. Hacker news is. I’m not personally wild about the community there, but I do find that like the like just as a link aggregator, it’s a really great source. That’s probably the single best place that I’ve found of finding useful links in terms of communities. Will mentions this in the Staff Engineer book. The Rans Leadership Slack has been like, honestly, a cheat code for me. It is the single most valuable resource that I have found anywhere, not just in my career. Like, I do not know of anything else like it. I always want to challenge the premise of the question, and I would say that if you want to be a staff engineer, well, you’re almost asking the wrong question. I don’t think that it’s something that you can necessarily set out to be. And then to the extent that you make that an explicit goal, I almost feel like it’s going to lead you in the wrong directions. Because the fact of the matter is that the things that really get, and unfortunately a lot of organizations, the things that get you promoted are not actually necessarily solutions to the problems that everybody have. They’re the things that are easiest to articulate. The value of learning the skills of figuring out where the pain points in an organization are, figuring out how to talk to people to figure out what the pain points are, in my experience are really the most valuable skills. And I mean, this is obviously also to a certain extent, self serving because it’s how I’ve done it.
Alex: It’s a really interesting response to that question. So the last question that we ask is how much time you spend coding nowadays?
Josh: That totally varies. There have been periods where I’ve spent days coding, much less frequent at this point. And there have been specific projects where like the work that I’ve been doing has been actual coding. But if I were to look at. So I’ve been at lob for a little over 18 months now. If I were to look at the amount of time that I’ve spent spent coding at this job, honestly, I’d be shocked if it even hit 33% of the time. Maybe not even 20% of the time. Like that is not the focus of my job at this point.
Alex: Cool. Thanks for being here.
Josh: Thank you for the invite. This is a really great conversation and I was really honored that you invited me to come on.
David: That’s it. Thanks so much for listening to to staff Eng. If you enjoyed today’s show, please consider adding a review on itunes, Spotify or your podcaster of choice. It helps others find the show and is a really useful signal to us that folks are finding value of this so that we keep doing it.
Alex: You can find the notes from today’s episode at our website podcast.staffenge.com the website also has our contact info. Please don’t be shy.