The Pair Program
The Pair Program

Episode 8 · 3 months ago

Managing Technical Debt: Why Startups Aren’t Afraid to Take It On | The Pair Program Ep08


Join us as our hosts, Tim and Mike, talk to startup leaders Jeff Nettleton and Leo Hentschker. Jeff has developed a specialty building software products in the health-tech space. His career journey has included working as the Director of Engineering at Aledade and has most recently brought him to Color, where he is currently the Staff Software Engineer. As the CTO of public notice startup, Column, Leo is currently focused on building the engineering team. Prior to that, he was one of the early engineers at Quorum, a public affairs startup.

In this episode we discuss how startup teams approach technical debt.

You’ll learn:

  • Why tech debt occurs (and why some engineering leaders choose to take it on)
  • The impact of too much tech debt and how to manage it
  • How engineering leaders can communicate with other departments about tech debt
  • And much more!

Check out Leadership and Self-Deception here: 

Welcome to the pair program From Hatch Pad, the podcast that gives you a front row seat two candid conversations with tech leaders from the startup world. I'm your host, Tim Winkler, the Creator of Hatch Pad, and I'm your other host, Mike Ruin. Join us. Each episode is we bring together two guests to dissect topics at the intersection of technology, startups and career growth. Hey, what's up everyone? We're back for another episode of the pair program I'm your host Tim, accompanied with my cohost Mike. Mike, has it gone? It's going great. How are you doing? Doing good, doing good. I'm excited for today's episode. So today we're going to be talking about a topic covering tech debt. So, you know, something that most products startups will face at some point in their evolution. You will define it, you know, we'll discuss some of the different types, will recommend some ways of manage it, managing it, and we have some excellent guests here to help us dissect that topic. So, Leo and Jeff, thanks again for joining us, guys. He's cool. All right. So, before we dive into the discussion, as as you guys are aware, you know we like to kick things off with the fun segment that we call pair me up up classic. So this is a segment where we all go around the room, we call out complimentary pairings and Mike kick things off for us. MA'AM, don't you start with with pairing. I think my parents going to be bad hair and a hat, because that's what's going on today. My Barber moved and I haven't found a new one, and that was back in like November. So, Oh gosh, that's it's another good one. No hair to hat, no hair. That's a good one. So there you go, Si yeah, now throw it back to you. Yeah, so I'll I'M gonna go with memes, stocks and Fomo, and this is something that I've honest I'd fall victim to the craze. Try Riding like the game stop wave at one point. Didn't work out and you know, by the time I hear about it, like most folks, it seems like it's obviously too late. And Yeah, I have this sense of Fomo. So I thought that was kind of a paring. I was curious if any of you guys have any of you get in it on any of the meme stocks at the right time. Yeah, I need a hundred dollars, a name, seeing lostons goings. It's the it's the circle of light. Right, yeah, even, you're even. You're good. Cool. Well, let's let's pass it over to our guests. Leo, I'd love to get your intro and you know what you're paring is awesome. My Name is Leo Henchkar. I'm the CTEO at column were Public Benefit Corporation based all over the place in the US. Were remote, but now about forty folks actually got to know the hatch folks from DC. Now I am headquartered in Miami and I would say that my my pairing is going to be a cold brew and chocolate croissants. And there's I've just recently discovered a bakery across the street for me which blows my mind. It's called Zack the baker. I am obsessed with this place and to my recent, slightly dangerous morning routine is I get too cold brews and a chocolate croissant and it is just it's just amazing. It hasn't materially improved my quality of existence by just an egregious factor. Nice one of the shakes set in exactly. Don't worry, they're already there. It's good. That's great. Cool. Well, Jeff. Yeah, quick intro and you're pairing. Yeah, Jeff, middles most stuff, as you're a color, which is a health check company own in San Francisco. Do a lot of covid testing and VAX nation right now. Yeah, I know that. That fokes from DC as well when I was at LD and yeah, always had a great time working with them, enough to say my favorite pairing right now is Zim and Z show with just a powerful, powerful toolox. So so I've heard. Maybe not us. I'm old school. I'd like run VIM but as in VI mode, shutdown everything and also the still use the same shell that I've always used since college. So t shell. But I do love Ze sheell. But yeah, but yeah, no, VIM is. That's a powerful KAMBA. Really see nerd stuff, real nice stuff. You exactly today. That's a dangerous take. That's that's not saying your provram absent checking or they like the other members that a group to see if they're stronger pasience. It's I'm sure we'll get some comments on it. That's fine. will embrace that. I'm sure there's a bunch of emacs users out there still trying to figure how to exit him. So we're all I have to seek an attempt to move our development, to get up code spaces, because novious co well, good stuff. Let's let's dive into the discussion here,...

...guys. I want to make the most of our time. And yes, as I mentioned before, you know this is going to be an episode talking about tech debt and I thought I'd be cool just kind of kick off with a quote from Ward Cunningham, who's iconic software engineer. He is credited with kind of coining the phrase tech debt back in one thousand nine hundred and ninety two, and a quote from him saying shipping first time code is like going into debt. A little debt speeds development, so long as it is paid back promptly with a rewrite. The danger occurs when the debt is not repaid. Every minute spent on not quite right code counts as interest on that debt. Entire Engineering Organizations can be brought to a standstill under the debt load of an unconsolidated implementation, object oriented or otherwise. So I yeah, obviously that's a little bit more wordy and technical, but Leo, you know, let's start with you and maybe like simplify this for our audience once you begin and kind of described, maybe would detect that means to you. Yeah, well, I would say also clearly that person has never heard of Mon on modern monetary theory, because dead. Who Cares these days? No, but my my, when I think about tech that, I really think about kind of the experience I have pretty frequently in my role of looking back at the codebase, looking at the things that we've written and wishing that we could move faster, but feeling held back by the constraints of decisions that we made in the past, whether it be the decision not to not to spend the time that we needed on testing, the decision to implement something in a way that ended up being not scalable, the decision to do something quickly that we knew would not cover all the edge cases we need. And it's pretty constant. Right I think I would really challenge you to find any endually engineering leader who says wow, looking back at this code I wrote and my team wrote a year ago, I am so happy with every possible decision that we made. But I think for me really, when I think about what tech dead is, is it goes down to that feeling of looking back and looking at decisions we made that were local optimal, that were decisions that we made get the resources, decisionmaking process and kind of structures we had in place at the time that have since proved to be a very local optimal, very not even close to the global and that that's generally how I think about it. It's the decisions you make on a given point in time that, upon later reflection, turn out to be materially not correct in hindsight. Good stuff. Yeah, Mike, if you want to maybe follow up on that? Yeah, I know, I'm it's interesting because I think of I think about technical debt, I think to me, the big and the the important part is the products sort of involved, like everybody's involved in making that decision. Like we're going, like, we recognize that this is suboptimal, were but we're going to do speak, you know, we've decided that, like we need to just stop the analysis paralysis and get something chipped and so and we'll revisit this and I think your take. I'm curious where the route because you're saying about like looking in hindsight at some of the suboptimal decisions we made. There's some decisions that you make that you can't foresee where the problem is going to be, and for those I tend not to think too much in terms of technical debt, in terms of like where I think about it is like, okay, as soon as we've identified the problem and we've raised the problem, at the moment that we've raised the problem and decided not to address it, that's when the sort of tech debt clock kind of starts. Like that, you can make lots of decisions that turn out to be suboptimal right, but like I would prefer but the other thing the the counter. That is like you can you can spend a year trying to figure out all possible things and make something scalable and then you haven't delivered shit, so you're out of business totally. So there's definitely yeah, I'm curious what your thoughts are. So I actually don't I don't draw a distinction between those two things and I think part of it comes down to at the end of the day, I do not believe that myself or other members or other people that I work with or making the conscious decision to do bad work. I really don't think that happens frequently. I think it's much more common that someone is in the and maybe bad work is the wrong term, as you say, or you can band word the work right. Yeah, I let me let me update that. That's all out. It's I don't think that people are making the conscious decision to do incomplete work. It's just in the framework that you have at the company at a given period of time and based on what you define as being complete, things get out right and so and from my perspective it doesn't really matter if it's lack of foresight or it's lack of a framework in place to create scalable, high quality work. It has the same result, right, it ends up being being in kind of that outcome oriented mind. It has the same outcome hero looking in hindsight and being frustrated and unhappy with what you've done in the past. There and I think that's why I really do view technical debt as being inevitable. I think it's impossible to move aroun absolutely is impossible toly...

...knowable. M Yeah, and I think in that light I really like the framing of kind of viewing it as such, because I think it removes some of that stigma that otherwise happens when you frame it more in the line of making that conscious effort to do something and avoid some work, is that it's no really, most frequently this is a product of the way that your team works, the structures you have in place and kind of the resources you have available. It's not down to individual agency as much, at least as my perspective. So see he speaking as someone who has intentionally done down to work for the sake of expediency. But I think they can actually absolutely be true that sometimes that's that's for the greater good. For instance, you need to get a contracts on. They want you to have the simpleness of next week. The only way to do it right is going to take three weeks. So you do the hecky version, get the contract signed and the reasons it it. I think that's that's absolutely a thing that happens. The thing that that I've done and the thing that I fixed later. So yeah, but but you're right that in most most cases it is just a product of the way that the team works. I think where the danger comes in is when the team becomes habituated to working that way and then doesn't ever change that and then you start getting into the phase where you are spending so much time paying back the depth that you're making your little Ford purpose right, at which point then somebody will inevitably suggest we should just replatform, not really recognizing that, like all of those like terrible like scars and things, the battle hardened thing that you currently have, it's not going to be as easy to it's never is easy, but and that's not a great way to repay technical daddy like who like buys a house and then like doesn't maintain it and then's like, okay, our house is falling down around us, we shoul buy a new house like it. But yeah, I mean, and I'm with you on the same thing, like I've made those same decisions, like I've intentionally right. If it's professional services or there's something that's going on, there are times when you're consciously making the choice and I think as an engineer, my job is to make sure that I'm at least throwing a flag, that I'm at least letting someone know we are consciously making like this is we all agree that we're making this choice. There's nothing more frustrating than being in a meeting where someone where you later learned what we made this choice, but nobody bothered saying anything, and now we're we like we didn't actually all get to weigh in on whether or not that was the right decision. Yeah, yeah, really like. I like what you said, Leo, about destigmatizing it, because it's it has a negative connotation to it, and you hear debt, you know, and every wants to associate that with their know, who they are or their future. But, Jeff, maybe was you that we that touched on this when we were first speaking about this. Is like reorienting your thinking about it. That, I was a creative way of portraying it. Yeah, so I think that if you consider tech, that to be a positive in and RELEASEAF orgization, but at the same time always assessing where is irresponsible to do it. You can really make a lot of good average out of tecta in this. Like Bird, example, you're eighteen years old. It makes sense to take on debt to go to university, but it doesn't make sense to take on debt when you don't, when you want to buy Houts, a jury team. You know, I don't have a job, I'm going to I'm to buy a house. Not Good, but I want to go to college so I can get a better job and then buy us it's and yeah, I have spent a lot of time, several jobs, fixing tecta day and day, and there have been plenty that it was, you know, just a straightforward refactor and I could totally see why they made this decision. There have been others where it was, you know, just endle was digging out of the hole and why did they do this? This? This was that. The worst example was there was even a spreadsheet from the start of the company where they had a pros and cons underious technical choices, and my seat will have this extremely long list of cons and no pros. Poster has had this extremely long list of pros and no cons and they went with my peepinting it just that is incredible. I love that. So that's amazing. It been him in the ass forever, you know, probably still little else. I mean. I would say, I think I was also telling the group here that I just had a funny experience this morning in which I think a lack of gates and checks on a build process that we have caused an issue. What caused material is you, and actually, literally before this call I think I was scrambling a little bit to make sure, like,...

Hey, are we going to be fine? Am I going to have to jump off on some random at some random point here to fight a fire? But I think, if just because, why not continue to beat the dead horse of the financial analogy? But I feel I feel like a lot of a job of being an engine engineering leader, especially at something early stage, is like being being drone Powell and saying, Hey, like this is this is what we can handle, this is the level that we're comfortable with at this moment in time. Right like there's this is what we're comfortable doing to be able to gain to gain velocity and move quicker here and then as the organization progresses. I think, Jeff, one of the things that you said before this that also really really resonated with me, with me, was this idea of getting addicted to speed and getting addicted to doing things quickly and getting addicted to that kind of leverage that you can give on yourself. And as I saw today and as we're seeing more and more as the company grows, we're now forty as opposed to five, there's consequences of us not being much more tightly regulated with the way that we make some of these decisions. Yeah, I mean I've definitely lived through the addicted to speed where suddenly you're like, okay, we're going to we've added more people, we've added more product management, and then suddenly there's these all these why are we moving faster? We have forty, forty FN engineers. Why can't? Why is this taking so long? And it's like well, turns out like we have more what we're shipping, though, is better quality. Like what we were doing before was very, very quick, but it also relied on us then going in and quickly fixing it. Like it felt like we were making a lot of progress, but really it was a lot of, you know, a lot of iterative fast development. I think that's an interesting take. Is the getting addicted to speed. Yeah, I think engineering can sometimes be misunderstood by non Engineering Company leadership, where, you know, the company's throwing their saying let's bring in some really senior engineers, and then the senior engineers and up spending all their time fixing tick that, and so you know, why, why aren't we doing the big stuff we're talking about when we are these people and it's like, oh well, they're dealing with the consequences of our position. You know, I guess I'm curious on to dive a little bit deeper on that in terms of like ways of managing it, you know, and getting in front of it early on. Anything specific that that you've seen that was helpful for you and your past life, Jeff, and I love to hear Leo's take to after that, after that, because Leo, you're in a very unique situation with that company that's scaling very quickly, going from seed to a and this really interesting size. So I'd love to hear that perspective as well. Yeah, I think one thing that you can do that that really really helps is even if you're writing code that is suboptimal for the reasons of, you know, speed or team's eyes or whatever, if you keep really high, you know, like ninety nine percent test coverage, you can always refactor it's safely. But if you don't have good test coverage, there will always be some unexpected behavior. Then you end up with the proud out and then you're sending more time fifteen things and not moving forward. And Yeah, that is something that I have learned your experience going quickly and not ready to US really bad. There are any of that? Of course, is that test of the first thing you discard when trying to move quickly? Yes, that's the first bit of technical debt year crew. Yeah, yeah, yeah, one of the things that I actually had a really fun conversation recently with someone who is the CD of a company also in a really similar stage, and we just spent half of our time talking about how quickly irrelevant all of our jest tests became. We spent all both of us made this this big kind of cohes of push within the teams like okay, great, we're gonna buckle down, we're going to get these tests and we're going to really, really orienter and getting these good, spend time, reduced flakiness, get these in there. And then in just unbelievably short order it felt like all of that work became incredibly irrelevant. But Hey, it was a stable time and so I think I can't, I can't, I can't argue with the results on that front. I'm curious that you guys like what you guys have dealt with, like in terms of for the non engineering right for like, I think it's pretty easy. Like product a good product manager usually gets it and it's not that big a deal. But as you get further and further away from engineering, you get into other parts of the organization, like do you even talk about technical debt or do you try and phrase it in other ways because there's such a negative stigma, or do you try and talk about how technical that actually is a positive thing? Like I'm just curious what your what your take on that is and how you talk to other parts of the org about tech that. Yeah, I really like the maybe just still of the saying you can have fast, right and cheap pick to, and you know fast and cheap is really great. You know that right is the tech that and I think that can really help people understand what's what's its stake.

You know, you can do all sorts of analogies, like hey, you're getting an extension onto your house. You want to fast, right and cheap pick too, and we'll sort of see the light there. One of the things that we were in the early phases of this, and so I'm can be curious to see how this goes and what and how. At the moment I'm very happy with that, but we'll see if this kind of translates. Is that we started to get much, much more explicit around effectively tracking things within Gira. We actually just made a switch from get up to Gira chipping. kind of life changing, honestly, because what we've now been able to do is wait. So the first thing we did here was we literally within our CI inforce that you are unable to merge to any we are unable to merge to either staging or production branch APPs and linking to a GIA ticket and having a category on that GIA ticket. And what it did for the first time was forced visibility across what are the changes across the organization actually bench parked on? Like what are they? What are they against? Why are they happening? What are they? And it put us today in this in this kind of magical position of being able to kind of communicate externally for the first time. Of this is the percentage of work being done on things that we are tag bug that things are tag backlog things that are tagged. We do debt by like things that are tagged in that sense, because before that I think we were never able to quantify that in anyway. It was always just this nebulous note of well, we have to spend all this time making sure things are working well, whereas now I feel much more confidence saying actually, x percentage of the work that we do on a going forward basis is likely going to be tied towards system improvement, which gives us, Hey, if we have this, if it's x percentage of a required for system improvement, we have a fixed costs related to go lives of the expectation is for the implementations that we're doing, those going to be a fixed cost. That gives us this much bandwidth for new product work. If we want to increase that number, awesome, let's hire more people. Otherwise that number is going to stay here and we're only gonna be able to do x on a personencycle basis. But I think that type of analysis pre more effectively tracking in Gia is never something that we were able to do. It's funny because I had almost identical experiences twice. First when I hired a program manager and she spent all this time going into confluence in Jere and building all these things that could actually accurately show us, like this is the amount of new work we're working on and this is the amount of rework. Let's all agree rework is bad, new work is good, and once we started tracking that and being able to see that, that was like yeah, definitely life changing in terms of being able to communicate that. And then my last job I'd basically like that work really well. So I did that again where we just sort of tag things a little bit and I was able to in in my management meeting, say like okay, this is this is a percentage of new stuff we're working on, this is rework, this is my like goal, like I have an Okr around trying to get us to this and we can drive towards that. And then when they were like weird spikes or whatever, I could like, Oh yeah, well, this was when we decided that we want, like we may remember when we made this terrible decision and I said it was a terrible decision. Well, this is the rework of that terrible decision. We all agreed that we were going to do and and it made the conversations a lot easier, like because I was able to say, like, by the way, we will be paying this off at some point in the future, and then when it happened, I would be able to tag it and say like this is, this is it. This was the result of our decision. Next time we're having this conversation, I'm going to pull this up and you're going to dying to know what we're getting into. So was I have very similar experience. I think it's a great way to sort of frame it up. I will say on the subject not allowing birds without her tickets, I have a couple companies had the experience of a large purse of my job being like blunking through the monitoring to see which in points of a hid two hundred and ninety five and then going into that end point, tacing some query. Sixteen CNTAL Slung Prom long and you know they get blams from six years ago from an engineer to left four years ago. There's, of course, of gear ticket. It's just like, you know, you just write his detail, that commit descriptions. You can and call that yet yeah, I think a one of the points that were covering here, which I think is is fascinating, which a lot of people don't think through as a derivative of tech, that is like how it impacts the the work environment, like the culture, and how, if it's not address or I like the way that you put it, Leeo, of like like that visibility across the org to eliminate what what a lot of folks have said, like the blame game. Right. I'm curious if there's any specific examples or, you know what, what else you've seen of like how this can impact the work culture, because you've got these different teams all working towards this product, but maybe it's like feature prioritization and who's on who knows what's coming out first, and any specific thoughts on that? I will say that you just said a very interesting word.

That is a concept that I have been thinking about recently in going into courting this its podcasts. The derivative. You know, I watched some movies about to be short recently and I've been thinking about you know, the whole financial housing market collapse was based on taking making additional financial prom let's bay self of death, and it is possible to build more tact as a derivative of existing Teca. That not only get you dee bur into the hole but means that you cannot fix the original tech that until you fix the tech that that derives from it, and that is something that is even harder to explain to no technical folks like like we fix the same's. Oh this whole other thing we're doing, we have to fix that first. Yeah, sorry that then it's your original question, but they said derivative and it's tough with it. I think that's an interesting topic, but I do think, you know what the the cultures thing. I think there is some impact. I think there's impact lots of different places for culture and I'm curious what you guys thoughts are. But like, engineers have a totally different like if you have a lot of tech dead, I think it can be frustrating for engineers to work in an environment where that's the case because they feel very high hamstrung. And then there's other people who feel frustrated, but in a different way because we're not moving fast actors, like from a culture perspective, when you have a lot of that sort of going on, curious what your thoughts are on like. Yet how does that affect company culture overall? Yeah, I think one thing that can really affect company culture is when you have a large proportion of engineers whose first and only job was that a company that does everything based on tech, that even getting them to understand that there is a different way can be hard. HMM, like not only should we not be doing this, but let me through teach you the throusably that isn't death. And you know, teaching people new habits is one of the hardest things about humans and that can be a huge component of the culture where you know you've got to not only convince people to change, but convince them that changing is even possible. Right for the right thing to do. Yeah, for sure. I think also the note around kind of team impact, is super relevant here because I at least personally in it, and I think I've seen this a lot, is that the kind of selfconception of a group of people is incredibly impactful for the work that they do. And I think if folks spend too much time or the the like, majority, plurality or whatever at their time exclusively focused on what feels like a mistake, a selfconception is, oh, we're team who makes mistakes. Right where? That's that's like the dominant mental story of like, Oh, most of my time spent picking mistakes. That's because most of what we will mostly we're not good. Right, like we're well, maybe we're not good, maybe we can't do things right, maybe we're not a group who's able to do this, and I think that I've seen this particularly when teams that I have been on our kind of strap for resources in terms of bumper of people, because it at least for us and our business, there is a certain fixed amount of work that's required for supporting customers that we have, and so if the combination of the fixed amount of work for supporting customers in the early phases of when they're going live, plus technical debt is the totality of time, that can really make it feel like, oh no, we're not a group WHO's in a position to really innovate here. We don't have the resources, we don't have the bandwidth that's really innovate. And I think that's it's not it's not a product of the group being incapable. It's just really a function of hours that are available within a group to even try to solve that problem. And if you don't ever make it past that threshold to even have the resources available to actually start making progress, they can be hard. And then the selfconception is a group that doesn't ship new things, and that's that's what that's a really interesting one because there's, I think there's two components to that, there's the resources and resource availability. Right, like everything you know, there's there's a fixed amount of whatever, whether it's people to do, work hours, whatever, all comes down to fixed number of resources, which gets into prior today, say prioritization and how you prioritize. And frequently I think people are like, oh, we don't make time to do blow or we don't know. It's like no, we we're prioritizing on boarding new customers. That's what we're prot with, that's what we've decided to prioritize and fixing technical debt and not innovating. And so I think sometimes engineers especially can only that's what they feel and that's what they see, and I think it's important to maybe try to address that in some sort of way of like well, we're making this conscious decision because getting more customers on boarded...

...bolly to more money, which will allow us to hire more engineers, which will allow us to actually start innovating, versus a lot of like in I remember really early on, like me thinking like man, if these guys were just stopped and slow down a little bit, like we could fix this. And it's like well, yeah, if we stop and slow down a little bit will also go out of business and it's like you don't quite you don't have all of the information when you're when you're selling in the code. So I think it's important to actually talk about that stuff to try and explain why we're making the decisions we're making and why we're prioritizing up with priority island. That can go a long way to sort of addressing that very like we don't have enough resources to do everything. HMM. Yeah, speaking of resources to I mean, I guess this is a point that we can certainly talk on from a, you know, a recruiting and hiring perspective, right, like from a timing, you know, issue of, you know, how long is it going to take us to get the the right engineers in here for this build? This is where, you know, you kind of had to let a little bit of your guard down in terms of how picky you want to be, because the longer that that is delayed, you know, you talk about that, that debt build up, you know it's gonna it's going to calls cause a lot of toxic things to the company at large and they're like, well, why is in that position getting filled while it's partially because you're looking for this you, this Unicorn Engineer. You might need to flex a little bit on that, because we can find you somebody a little quicker if you tweak, tweak the requirement just a just a tad the new ground that has ten years of experience. Yeah, yeah, that's right. And also, I think especially, and this is now, please forgive what is going to be a slightly brief soapbox here, of I think when you especially at some of these early stages, when you're looking for people to join an early stage engineering organization, often the best predictor for effectiveness within that organization is not the best predictor for effectiveness within a large, large engineering company that has been existing for ten years. It's different things. It's absolutely different things, and I think from our end we have seen that literally, like in we have seen that literally of that some of the people at the company who are the most affected came in with the least background and some of the folks who took longer run but ramp up have more experience, and that's supernatural, I think, for early stage companies. I think if you talked almost anyone across the board, they're going to see that and I think both folks have a really material role to play. Of having someone who is early in a job, who wants to get in the weeds, who wants to splunk and learn things and figure things out and be a part of that like rough and tumble of the early stages is incredibly powerful and I also think, so much more powerful when you have that person with a senior engineer and just people who are senior engineers, who are objective, who go come in to environment be like, Oh my God, this is one tenth of what I would want or what I used to Provit in my other context, but actually, in this position does I have this person coupled with someone who wants to learn what this person knows and they can work together to actually improve a system. I think that is so magical. I think that is so unbelievably magical. Completely agree. I think that there's they're they're different engineers for different stage companies. It's not necessarily the case that an engineer can't be successful at those different stages, but there's a different mindset when you're early on versus and so and so forth, and to recognize that. I think the other thing to Tim's point that I think is interesting. I can't tell you how many times I've had like conversations of like yeah, if we had hired somebody three months ago, we would have been a much better position. But like, like and we're now. We're we've almost created like recruiting debt. We're like interviewing dead or whatever. We're like the amount of work we have to get done precludes us from even spending the time to try and find the right people and to like do the to do effective interviews and like. It can be kind of daunting and it's like well, you know what, after this sprint will get to it, and then it's like it just sort of you sort of kick the can and then you sort of don't really do the hiring that you need to do to address like what you know is coming down the pike. HMM, I'm Curius held up somewhere. Yeah, that's true. You can remember sometimes holiday when we were thrown out, like you don't have any time to interviews, so only send this people. You know that this is this. Yeah, I've got some some early gray hairs, I think, as a result for some of that. But yeah, I mean this is a topic that's an episode in itself, honestly, is is that mold of a startup engineer and you know, those foundations that maybe it's like yeah, that that is a piece of a mold of an engineer that maybe is a little bit more adapted to like, you know, understanding tech debt, because they've been in the startup environment an early stage and it's been a little bit more of like, you know, it's almost like you you know that you guys, you got to play with a little bit of a budget here. It's not just go go wild on your spend, you know, which also, and yeah, totally. And also to that, to one of the one of the people who I the wors of, like Whoi I'd look up to so, so unbelievably highly in the space, is charity majors, who has this knows that I love about starter teams as well as that, when you're hiring, it's about the team. It's not about individuals that you're bringing on that team, it's about the team dynamic and the team structure, and that that has been incredibly impactful for me for how I think about this as well. Because,...

...yeah, having having six people come in who have only worked in an environment absent any that of that type of issue. I do not think would work well. Yea, a very quick contake that I'm going to throw out there that I'm curious to see if people disagree with is, I would say, every single time we have ever in the history of this company implemented a class, hierarchy or abstraction, it has been a horrible idea. Part of if they're that, I'm not ever kidding, like pretty much every single time we have absent a literal year of getting things slightly more extensible, I have regretted it every single time, and every single time I've ever imported image magic, I have been said. Those are rights of my two things. If I have ever using image magic, I know it's because there's I know there's going to be a catastrophe in six months, I just know it. And if we're, if there, if I if there was a class, I will hate it shortly. That those are my two things. I could always turn back to. That I know will be the case. You pillows that image Magic Imaging Library and Yeah, sure, you almost never need inheritance unless you're modifying some freework that is yours. It's so true, and that to me because, like one of those interesting, meaningful deviations from what you learn and too in practice, of you really rarely need inheritance. Almost never. It's almost always the incorrect call, and that is always so shocking to me. From but like on every access of readability, maintenance, simplicity, I will almost every single time we have chosen for up, we have chosen abstraction over copying and pacing something in two different places. We have regretted. It doesn't sound very enterprise. I'm kidding. I mean that a lot of if you think about where Oh came from, an inheritance and the rest of it, it's also from the days when we had waterfall like methodologies. Like it's just a different time. I think that there's it's probably a whole other topic. I mean, like like the Vose, this is a product of the stage the companies at, because all everything we're doing right now is encountering the fact that early on we made the incorrect we made those in corn structural decisions right in. The fact is, I think most engineering decisions are like suboptimal optimization, like we don't understand the optimization work. Anytime were trying to optimize, we're a little an optimizing human suck at it. I'm seeing this is one benefit of starting with a language like see, where you don't have any of that in just to learn the best practices without any sort of like modern pair of line at all. Is Is it really powerful tool? And the schools I've stopped doing that's not teorr. Are you saying like from a company perspective or from an individual learning perspective? Individual perspective? Yeah, thank God, getting first. I'm advocating for for assembly. That's all we're going to write in. Okay, I had a professor. Okay, for my choice. I'd rewrite it and rust. I had a I had a professor who it was just it was. It was amazing speaking with them because you like see, blow where. I don't use it. Never anything. Are you really blow where? He's like, yes, inefficient, blow where. Don't even show me it. I was listening. Maybe laugh. That's amazing. Yeah, we had a lot of hot takes on this one. I like best all out one to it as well. So like your big short reference, Jeff, I think Adam McKay is when the greatest directors of like our time. It's just genius, like the Inkerman to like thinker man was just freaking great. But yeah, just being mindful here. So we do want to transition into another segment. We've got about ten minutes left, so I'm gonna I'm gonna ask it. You guys have any last comments on the on Tech DEP before we transition? Probably need another episode, be honest with you, just to to dissect it deeper. But yeah, I think that was I think that was a good, good riff for about twenty, thirty minutes. So cool. Well, let's dive into this next segment. This community wheel behind me is a segment called round out my career, and this is an area where, you know, we kind of crowdsource some topics and questions from the hatch bad community and it's more, you know, a little bit more geared around career growth. Hence the name. So the topics can range anything from like compensation to diversity to interviewing. So we'll go to give it a spin and see what see what today's topic is. Are we getting a lucky Ras Perry by winner? Never those time winners. All right, we're saving...

...on our debt through the No, yeah, say, I love it. Cause a literal day. I think I think we need to readthink something. Yeah, we're school. Is that publicly? All Right? So it landed on mentorship. So could be mentorships, coaching here. Let me see here. I'm was full something that we've gotten this category. All right. So what are areas outside of the engineering or product department that you believe are the most valuable to the groups, to the growth of a startup? Technologists, Jeff, be able to understand what a business does, why they do it, and being able to now but you're doing is an engineer to that it's huge. I think a lot of people also able to make that connection to okay, we have this feature for this client that does this, in this feature for this fine, does this, but at their core they're both doing this some business abstraction that can be implemented in and can really help you. Kens come to you with. We've got this requirement. You can understand why that's a requirement, even if it likes in Velocitar. That's fantastic. I love that. Yeah, I put the question in the comments here, so Leo, if you in case you forgot the question. It's kind of a silly one, but I think having someone teach you how to send the emails is really helpful. Something that I see really frequently, and this is something that was true for me early on and very frequent for folks on development teams early on, is that there's kind of a cadence to professional email sending that if no one tells you, you don't learn and makes the communication you have incredibly unclear and it's it's one of that, I think, most impactful experiences for me. It was I was working at a previous company. Basically it was actually Corem, which is one of the one of the coming space in the DC area, which I think some of the folks that have don as well, and I was writing an email and it was like three massive block paragraphs and it was just horrendous and then someone came up to me, looked at it and said who was reading this? Literally, who was reading that? It was a bit of a wake up call from me like, oh right, maybe there's a bit of an art here that I've always discounted to these folks on the business side who spend all their time talking about how good their email cadences are. So I I think that there's really really quickly, if you are either growing in your role or speaking with folks externally the dominant medium of communication that you end up using his email and being able to do that well, succinctly powerfully is just game changing, and so that's one that I would high like. I would I would I would go so far to say just communication drone, because I do agree that email, especially if you're talking external right last few organizations have worked at I've made it a rule like we internal communications don't happen over email, like we should use slack for quick things and Google docs or office three, six, five, whatever it is. For long form, like I don't want like to me, email is like terrible, like it's we could probably have a segment where Mike just hate's on email. I kind of take on that, but take anyway emails here for extra communications, but whatever. Well, let's just move on. I agree, though, that communication in general is an area where a lot of engineers struggle a little bit with the long form. How to actually, you know, like the I didn't have time to write a short email like that type. I like, like sometimes it's just really long, but it doesn't need to be that long, like just get to it. Similarly, reading. I think it's not just about writing, it's about being able to read a communication and recognize that the voice of the other person isn't malevolent, like. They're not like. There's a lot of people, I think, who take things very like, who might take a direct communication and read a little too much into it, and so I think it's not just writing, it's also the being able to read an email. Well, on that subject, that's a great printing. My old boss that but isn't sit to the Mose, made me read this book that the turn, was very annoyed that, I had to bet. The whole concept of the book is this idea of you can be in the box where you have a preconceived notion about another person's intentions and you not that motion to everything that they say. And so they...

...told you you couldn't implement something one time, so they don't like you and you read every email through that Lens. And that's a really easy trap to follow too. Something please. And you know, like you said, the texts no emotion, attempts to it right. So it's very easy to filter that in instiple ways. I always advocate, you know, always assuming someone's good intentions. It's only prove that they done. But even then I like I've worked with even then, like just because they had bad att like. You can't just always assume that that that person is that way. To that point with the the person in the box, yeah, I know it's true. And also one thing that I think is fair and hard to realize that just because someone can be incredibly heady, enjoy you as a person and be unhappy with what you did yes, and that it's not because they're a bad person, it's not because you're a bad person, it's not because you're a bad at a job or they're a bad at their job. It's that there are situations people find themselves in in which the outcome does not work out. The outcome was insumation for one of the two parties. No one's fault, but that is what happened and I think being comfortable with that and separating that from a personal relationship. He's incredibly hard, think unbelievably hard. But to that point of it, you have to learn to be able to do that and I whatever that book is, I would love to know it. Yeah, we'll get the leadership in the art of self deception just to we'll type it in the chat. Cool. Yeah, well, show notes another good one for sort of non engineer days is it's totally okay to scrap. You're not going to get fired. I mean like these. That's on you, but I mean is it. There are out you know it happens. I've had more than last share. You know, it is what it is. You learn from it. Don't eat yourself. You know the CEO is not going to come to your desk and punch in the face like it's it is. It is what it is. You know, people are people. Yep, it's act. It's funny that you bring that because that's one of my favorite stories. When I like my start engineer, like managing a team or a new team or whatever, I'll sort of talk about some of them my history or whatever, and I still remember my very first big screw up where like customer on the phone running my install script deleted, like basically just deleted from root on down. Like learned a very valuable lesson, like install script have rm in them. They should have moved stuff like that, minor things, but he like that so fair. He lost it on the call and I remember thinking like I'm so like, this is not good, and my manager put the phone on mute and said, don't worry about it, my fault. I should have actually reviewed some of this before went out that, like, HMM, just take a deep breath, don't worry, everything's going to be fine. And like we had, and most recently we had a similar incident where there was a security incident. Some things sort of think, go great, recovered, it was reported, it was dealt with. The person felt are as like you gotta not feel terrible, like everybody makes mistakes. It's totally okay, it's it's just part of the job, and I think that that's an important thing to recognize and call out. It's an engineering team, you know. Yeah, it's not huge. Screw it up. There was a little chain of failures here and right. One big thing. I'm a huge job the cause of his blameless incidents. So anytimes something goes wrong, you know, an incident post Mordom, and it's nobody's fault. But they were contributing actors. Some of the contributed more than others. That doesn't mean that their faults all right. And if you get a new habit of any sense of it goes wrong right up into the out of this searchable yeah, I guess I'd had Jeff, I really liked your first point to about, you know, kind of almost like getting a better sense or a view of the business at large versus just like what is my role here and what is my lane? I like this concept that that some startups have done where they've almost had this rotational program where you get a chance to get a taste of each department. Maybe do like a shadow, you know, one week of the Marketing Department or you know, you know, maybe it's not as appealing, but you know you want to get to get a sit down with like the the CFO or the finance side of things, just well rounding you as a business person at large and then giving you board, more buy in and to you know, the the company and what you're doing with them, versus like feeling like you're just this role and that's your depart Brit and that's it. So I think I really like that that point of, you know, getting a getting on board with the bigger business as an operation versus just young I'm a technologist here, I'm an engineer here. Also, at the end of the day, like works. It did two works neat people. In some sense it's like yeah, these are the people that you're trying yourself with, and I think broadly it is. At least for myself, I like spending time with the people who have chosen to also work on the same thing that I care about. That is just fun. I just enjoy that, and so you like, independent even of what the focus is,...

...that that's something that really kind of the something that matters for me. Good stuff. It's just a job and if you're not having fun anymore, it's okay. Yeah, yeah, it's right. Cool. I think that's a good stopping point. You know, thanks, guys, for hanging out with this and tackling this topic of tech debt. Anywhere specific that you want to shout out that you know listeners can confind you or follow you? Feel free to do so now, or we can also, you know, post it later. Maybe a bum linkedin. It's all I gonna then we're gonna gey saying. Okay, I don't know. I've actually never been asked this question. That's kind of bud. I guess. Liked it or twitter. I yeah, I get I give you all side. I'll get by by twitter handle after the fact. Cool, cool, awesome. I thank you for listening to the pair program if you'd like to continue the conversation from this week's episode, you can do so with the hatchpad community. Join US AT CHAT DOT my hatchpadcom.

In-Stream Audio Search


Search across all episodes within this podcast

Episodes (15)