Soft Skills Engineering - Episode 379: Someone fixed my ticket and is tech debt bad for my career

Episode Date: October 23, 2023

In this episode, Dave and Jamison answer these questions: “Hi! Love the show, long time listener. So an architect noticed an issue with credentials embedded into request body being logged. I had planned to resolve that, and someone already had done so for another instance. I took a day or two to figure out how to fix it globally, and even tied it into another filtering we did. That would mean one list of sensitive data patterns to maintain – that we already had, and don’t need to worry about which context keys to scan in. Scan them all, CPU time is free after all /s I opened this PR, and received no feedback for a day. Another engineer did mention an alternate approach that would resolve this particular case, but I was trying to fix it globally so we didn’t have to maintain a list of keys to scan on. Next day he mentioned he made some click ops change that resolved THIS PARTICULAR INSTANCE, meanwhile still not providing any feedback on the PR. This approach is IMO a maintenance burden: keep two different filtering in sync, proactively add keys to strip. High chance of mistakes slipping in over time. So I said OK works with some caveats, and rejected my PR. I can not explain why but this incident tilted me hard. For one thing he essentially grabbed my ticket with no communication and resolved it himself. Then he provided no feedback and went with a different approach without consulting anyone else. Worst of all, he ended up with an (IMO) markedly worse fix that I had already dismissed as being too brittle and likely to miss things in the future. What do? Am I unreasonable to feel undermined and disrespected?” Hi Dave and Jamison, long time listener love the show. I work on a team that is relatively small in size but we own a huge scope including multiple flavors of client-side app and a bunch of backend integrations. We recently launched our product and since then there have been constant fire due to various tech debt that we never fix. Our manager has attempted to ask the team to share the burden of solving these tech debts, but there are only very few that are actually doing it. I can think of many reason why they are not able/willing to take on the task, likely due to other priorities or unfamiliarity with the part of the codebase. Due to my familiarity with various component, I’m usually the one proposing the fix and actually fixing it. I have started to feel this is taking a toll on my own career development because I ended up not having bandwidth to work on those bigger projects/features that have high visibility and good for promotion. I do think solving the tech debt is important work and don’t mind doing them. How would you navigate this situation? Thanks for the awesome podcast!

it takes more than having your important work being blocked by your critical work to be a great engineer this is soft skills engineering episode 379 i'm your host dave smith i'm your host jameson dance soft skills engineering is a weekly advice podcast for software developers who are constantly blocked by work that's more important than the most important work your ultra high priority work has been blocked by the super ultra mega giga high priority work this time when i read critical work i just thought critical strike i don't know why this is a critical pull request does plus 200 damage plus 200 outage duration your prod database has received a critical strike

ah that sounds just like the kind of work i do a skilled engineer working on critical systems yeah critical failures this episode is sponsored by compiler which is an original podcast from red hat discussing tech topics big small and strange you will hear more about that later all right shall i thank our patrons please do gotta preamble this with an apology for being out late this month with the new batch of our illustrious patron crew sorry about that you know the last week of october is not a bad time to it's still in october all right we have type hero.dev full stack contractor looking for job corp to corp never is not just a crater on mars flamingo emoji i like chicken i like liver

meow mix meow mix please deliver trash panda the computer science book.com santa hope r kent c dodds jenny kim owen shartle craig craig motlin the stochastic parrot alice jost muskingham ohio patreon.com we're hiring ira chan monkey face emoji jonathan king web tau awesome end-to-end testing will angel ragnar nick hathaway ragnar nick hathaway someone put will angel ragnar nick hathaway on a single line the next line is ragnar the next line is nick hathaway there really are two nick hathaways now travis brayden canes john grant cody sale nick cantar and a one-time shout out to el davamos thank you so much to everyone who contributes to this list if you'd like to join this illustrious duplicative permutational crew go to soft skills.audio and click the

support us on patreon button where if you contribute enough we will read anything you want us to read that's safe for work and even if that's the names of other people on this list and any amount greater than zero will get you access to our slack community we send out those invites at the beginning of each month again apologies to our october illustrious crew who got the invites a week or two late that was that was jameson's fault just kidding it was my fault i transfer the blame to our intern that yes that slug of bed our un our unpaid intern we got what we paid for our unpaid incorporeal intern yes all right would you like to read our first question so much this is from checked out engineer hi i love the show long time listener

well thank you so an architect noticed an issue with credentials embedded into request bodies being logged i had planned to resolve it and someone already had done so for another instance i took a day or two to figure out how to fix it globally and even tied it into another filtering thing we did that would mean one list of sensitive data patterns to maintain that we already had and Don't need to worry about which context keys to scan it. Scan them all. CPU time is free after all. With the little sarcastic symbol.

Slash S. The sarcasm indicator. Yeah. I opened this PR and received no feedback for a day. Another engineer did mention an alternative approach that would resolve this particular case, but I was trying to fix it globally so we didn't have to maintain a list of keys to scan on. The next day, he mentioned he made some click ops change that resolved this particular instance. Meanwhile, he still did not provide any feedback on the pull request.

this approach is a maintenance burden we are trying to keep two different filtering sets in sync proactively adding keys to strip out there's a high chance of chance of mistakes slipping in over time so i said okay it works with some caveats and i rejected my own pr i cannot explain why but this instant tilted me hard for one thing he essentially grabbed my ticket with no communication and resolved it himself then he provided no feedback and went with a different approach without consulting anyone else worst of all he ended up with an in my opinion markedly worse fix than what i had that i had already dismissed as being too brittle and likely to miss things in the future what to do am i unreasonable to feel undermined and disrespected

ah so first i just have to say i had heard the word click ops but it never really clicked no pun intended with me what it means but i love this word now have you heard that before define it oh Oh, yeah. I'm a skilled practitioner of the art of ClickOps. Oh, as a longtime AWS console user, I can say that there's a lot of clicking. So ClickOps is the time-consuming, error-prone, clicking through various visual menus in typically cloud providers, I guess, or just any kind of technical infrastructure that requires lots and lots of clicking. I think AWS inspired ClickOps is my guess, because there is a lot of clicking. it's often contrasted it's it's the it's the bad way where the good way is some kind of

infrastructure as code like terraform or cloud formation or something like that set up and that turns into keystroke ops yeah so much yaml that's type ops click ops and uh it's it's so much easier to click up something you don't really understand like if you're playing with a brand new thing that you haven't used before it's pretty tough to go write a reasonable terraform yeah config for it exactly at least in a in a clicking world there's a finite set of things you can click on yeah usually they do a pretty good job of making you click okay a bunch of times then you get a reasonable yeah get started next next next next next next next next all right i have a functioning stack and that's what inspired the new ai supported coding workflows that we have now today where you

just type do the thing and then hit next a bunch of times and then a bunch of code appears give me a mean stack here's the tariff one mean stack please yeah so click offs and and it's bad just to be clear click ops it bad it means that this person clicked their way to glory to fix one particular issue but did not apply a global fix was thinking small and you were trying to do the right thing in this case the listener trying to do the right thing and then got shut down by someone who did the wrong thing, but then basically removed all incentive to do the right thing or to do anything. That's what I see at the core of this issue.

You're making a prediction about the future. And all design is making a prediction about the future in some ways. But I just wanted to call that out, that if the list of sensitive data never changes again, it's possible this solution is actually better because it's less effort and it was faster to do. And there's plenty of reasons why even if it still never changes, it could be a bad solution. but there are some assumptions that you're making in your solution which is like we're

going to need to maintain this which is often reasonable but or we're going to find other instances in some other context right yeah yeah like we'll need to generalize this it sounds like you generalize the thing and that's often takes more time than solving it in the specific instance which is why they defeated you in ticket combat ticket combat ticket ops so i think it yeah it it makes sense that you are frustrated by it i think you you have a i like what you said dave that the incentive to fix it is now destroyed because you can't you can't tie your generic system for solving this problem more broadly to an actual current like acute specific issue right and and that's often the easiest way to sneak in like system changes is is there's a bug and we

will fix the bug and make it so this type of bug will never happen again and then instead of just band-aid over the bug but i think you can still sell it to the team as worth doing by pointing out the likelihood of needing to you're you're protecting against the future work or outages or security incidents caused by this list changing changing yeah and this one's kind of a hard sell or is it sell or sale it's hard to convince the team of what to do here because not only is the problem gone but also the problem will only exist again if an engineer makes a mistake because what that's what i think happened here is that something that's not supposed to be in the logs got into the logs and presumably that's because someone made a mistake and so i found it's actually

kind of hard to sell preventive stuff to engineering teams if the prevention if the thing you're preventing is them making mistakes they're like wait what i don't make mistakes like i never try to make mistakes so we don't need this yeah i don't think people say that out loud by the way i think it operates i think it motivates behavior that sentiment that's interesting i'm just so acutely aware of my own failures and shortcomings that i i feel like i'm very easily convinced by someone saying this this is a pitfall this is a thing that you could mess up let's make it so you cannot mess this thing up this way yeah because i as a frequent messer upper yes you want more messer upper prevention yeah i want i want guardrails because i'm lazy and sloppy and

yeah some yeah i've just noticed there are some developers who are exceedingly careful and and diligent and I am just not that way at all when you drive your car down the highway do you just kind of bounce off the guardrails like I don't even touch the steering wheel I just hit the left side then the right side then the left side again yeah I'm actually in like a big hamster ball type thing so it's like a gutter ball minimal damage now what are they called bumper lanes in bowling yeah I was thinking about bumper lanes in bowling wouldn't it be nice I guess those are sort of trains yeah pretty much it's hard mode to drive the train without the tracks that's like bowling without the bumpers on requires great skill just point this thing in the right direction it's all

in the pointing yeah it makes sense why this would affect you and why it tilted you hard and did it say I plan to resolve it so I see that you planned on working on it you thought about it, you started working on it you submitted a PR the other person, you said they grabbed your ticket and I wonder if

this was sort of an eager beaver someone who saw, oh there's this high profile thing busted i i want to jump in and help out and and there's kind of a communication gap here where they didn't check to see is someone else already assigned to this thing or like if they had known someone was already working on it maybe they would have been less likely to just go race through and do it yeah so you're saying like maybe they didn't realize you were working on a general solution yeah yeah so maybe like maybe you need to get better about your you meaning your team needs to get better about checking the status of whatever system you use to allocate work to

make sure you're not stepping on toes. Or alternatively, you can be really vocal about broadcasting. Hey, I'm working on this thing. Any feedback or ideas, let me know. But just to avoid multiple people in silos working on the same thing. That is one charitable explanation. And I kind of feel like a historical apologist right now. What else could it possibly explain this behavior in a positive light? And another way could be that they've actually wanted you to finish your generalized solution, but they also wanted to fix it now so that while they wait another day or two for you to fix your generalized solution, they're not still logging sensitive data in the logs.

It's like, look, let's stop the bleeding and put in place the airbag so that next time you crash your car, you don't break your nose on the steering wheel. You know? Yeah. But let's fix your broken nose right now. and then you know we get to work on that airbag all right yeah that's a common practice in incidents or outages is like you you do the fastest possible thing stem the bleeding i think is is what they call it at some places you just you stop the bleeding as fast as possible and

then you kind of go back and work on the system yeah exactly and i that's one possible explanation i'm also thinking about what is a mental strategy or a mental thought process you could adopt in this situation to make you feel better about it. And I could think of one, which is, look, you either predicted the future right or wrong. And predicting the future right looks like this is going to happen again. And if it happens again, then you were right. And you can reopen your PR and you can now with much stronger evidence say to the team, I'm going to put a full day of work into this. And it's right to do it because we've already had two instances of this problem. And here's a third one so that that will make you feel good and your work won't be wasted because

you you know you started the work you can then go and pull it in and resume it but for now you've just pressed pause on it hedging against the fact that your prediction was wrong which is also a possible outcome like this may never happen again in the life of this company at which point it actually was the right thing to stop working on that pr and throw it away so either way you get to be right i like that i like it i like getting to be right it's like the kobayashi maru of prs yeah but the the good kind where you win yeah even though the system all the decisions are the right decisions yes it's like it's like the easy mode kobayashi maru no matter what you do you're gonna pass this test yeah i think it would be worth asking specifically for feedback on the

pr because it's possible yeah i don't know why i keep getting sucked into doing the same thing that you just described of like explaining why this person is reasonable and right but pr is often languish i feel like it's a pretty common problem yeah reviews take too long to happen and this is a good general skill to have to be able to round up reviews for your stuff i think it'd be worth shoulder tapping this person and saying hey thank you for fixing this specific instance i believe i have the fix that's more generic and i'm making some assumptions here that it's not gonna your fix has not been invalidated by the change but it's so maybe maybe this means there's actually more work you have to go do on the pr but assuming it's still something that could get

merged in relatively easily i think it's still worth saying thanks for fixing this please help me fix it for real and give me a review. If you ask and get ignored, that's a bigger problem. But people not reviewing your stuff is a normal failure mode. Yeah, that is true. I don't know if I would go rattle that cage. It kind of seems like, well, I guess it depends on how you perceive the behavior of this person. If this person was annoyed with you and just wanted to get this done and didn't really see the value in what you're doing, I might just move on and let it go and wait for that sweet, sweet vindication that's going to come when the issue resurfaces because this person's fix was inadequate. And then bring it up when you've got nice concrete evidence

that your solution was the necessary solution. So you think there's a possibility that they deliberately didn't review your PR because they don't want to do that thing? I don't know. Maybe a chance of it. I think the lazy explanation is the better one or just the miscommunication is the better explanation, you know, where they just maybe they didn't see it. Yeah. I hope that the team is good enough at communicating that if someone really thinks this shouldn't happen, they're willing to say that and explain why and talk about it instead of just shun the pull request. Feedback via shunning is ambiguous and tough. Yes. And I do see in the question, though, kind of reading it a little more carefully, that

an engineer did mention an alternate approach that would resolve this particular case. the next day he mentioned that he had done some click ops that resolved this instance so i think the engineer saw it and chose to just go resolve it so i mean if you want to go have a conversation with that engineer it's it's gonna be something like hey do you think it do you at least the way i would suggest it do you think we should proceed with a generalized solution or not yeah and and i really wouldn't i wouldn't spend too much time on it honestly i just there's probably much bigger fish to fry and higher impact beneficial things that need to be done on your product and uh this one while possibly important might not be critical or

mega critical yeah or super hyper mega super critical you could also assume that the engineer went and did this solution because of your pull request right it sparked them into action so even though you didn't do it you still caused it to be solved so you did it is that what you're saying yeah you did it if you really want your pr reviewed i'll review it send it here but be warned i'll be a harsh critic yeah those spaces better all be correct the most important pr review yeah what it looks like okay have we answered the question i think so i think just one last thought for me though and nothing from you jameson unless you want to and then yes i think i do think that you this person is wise to have identified that maybe they're being

they're feeling overly strong about the about this situation and i would as an as a mental exercise i would put myself in the in the mindset of the organization that you're serving by working on this code and the mindset of that organization would be hey great we're no longer logging sensitive information, it's fixed for this instance. That is a step forward. That is not a step backwards. Now, you didn't get to do your version of the fix, which is a generalized solution. And maybe that would be better. But as far as the organization is concerned and kind of the objective of the product doing its job, things are better because of these click ops, at least for now, right? The bleeding has stopped. And so I would try to adopt that mindset of, look,

I'm just here to contribute to the overall health and wellbeing of this software and it is better off now. So that's a net win. And I can take that win, even though my particular idea didn't get, didn't get implemented. And I'll just say last but not least on that, I believe the reason this person feels bad is mostly because of ego and not because of like something truly bad has happened here. And I was like, my thing didn't get done. And, and it, I found that the more I can let go of that the happier i am yeah i'm happier the more you let go of your ego too most people most people are you know what i like the most dave when you don't talk about what you want all right okay dave can we have an honest natural conversation about a podcast

from Red Hat called Compiler. Yes. Red Hat Compiler is a really cool podcast. It's from the people at Red Hat, which is a company I've admired for literally 20 years. Red Hat employs a bunch of really interesting people, everything from actual compiler developers to engineering managers.

Listening to them share their perspectives over the years has been eye-opening for me. I really liked the recent episode in Defensive Legacy where they talked to some experts about how you dig through old legacy systems. It feels a little bit like code archaeology. You're trying to piece together truths about the past from these artifacts that you have.

It's fascinating to listen to. Yeah, they also have a series on software technology stacks, describing databases, programming languages, front-end frameworks, back-end technologies, and even test frameworks. Their production value is so good, too. Like, put us to shame good.

Yes, it's like what we aspire to be. Listen to Compiler from Red Hat, anywhere you listen to podcasts. All right, here comes the next question. This comes from an anonymous listener who says, hi, Dave and Jamison, long-time listener, love the show. Thank you so much. I work on a team that is relatively small in size,

but we own a huge scope including multiple flavors of client-side app and a bunch of backend integrations. We recently launched our product and since then there have been constant fires due to various tech debt that we never fix. Our manager has attempted to ask the team to share the burden of solving these tech debts but there are only very few that are actually doing it. I can think of many reasons why they are not able slash willing to take on the task likely due to other priorities or unfamiliarity with the part of the code base. Due to my familiarity with various components, I am usually the one proposing the fix and actually fixing it. I have started to feel this is taking a toll on my own career development because I end up not having bandwidth

to work on those bigger projects and features that have high visibility and good for promotion. I do think solving the extra tech debt is important work and don't mind doing them. How would you navigate the situation? Thanks for the awesome podcast. Well, it's time for the next evolution of our no bugs driven development philosophy, which is don't write any tech debt driven development don't create tech debt driven software development it's the dwtd don't write tech debt yeah philosophy yeah that solves all problems it does require a time machine though yeah well that's easy i mean when you have a time machine it's easy to go back and it's like it's like p equals np where you can reduce a bunch of problems

to it and then assuming you assuming you solve that then you solve all those other ones too so once you solve the time machine problem you've essentially solved all problems yeah all these all the class of problems that can be all the class of time machine hard problems i don't know tm hard yeah yeah i know what you mean that's in all the textbooks yeah managers attempted to ask the team to share the burden of solving these tech debts okay i think it depends quite a bit on how much how your manager feels about you working on the tech debt if they are championing you doing it and pushing you to do it and and able to articulate to other people the valuable contributions that you are making by

solving these tech debt problems, then that can be good for your career. The classic argument about fixing tech debt is it's a high leverage activity where it's going to help everyone go faster. It'll help everyone avoid this problem in the future. And if you have your manager kind of recognizing you are helping everyone go faster, you're helping everyone avoid this problem in the future, I think that's a pretty impactful change. If they are begrudgingly allowing you to noodle away on it then and they don't perceive it as a high value thing then it's definitely going to affect your career yeah that's not telling you what you should do but it's it's one way you can evaluate how how might this impact my career do they do they think i'm doing the most

important thing for the business right now by fixing this tech debt or are they like i guess engineers can have a little tech debt as a treat this person just always wants me to give treats doesn't do any real work because there is this thing that happens when you move into management that you you suddenly become so much more okay with the idea of tech debt i know that's so true it loses its visceral painful hooks into you it's like yeah you know it's there but it's always there i don't know you still gotta get stuff done yeah like wait is it still bringing in revenue okay is it gonna slow down revenue no all right leave it alone yeah so i think there is a danger I think you're correct in that it's possible that there's this perception that you're not

doing impactful stuff. You should investigate that and see if that perception exists, if your manager feels that way. Yeah, I think that's a worthwhile investigation. There is another angle on this, which is, this is an opportunity. Here you are, we're in a down economy, layoffs are happening. You're the only person who can do tech debt. What if when you fix one tech debt, you leave the system with more?

thus ensuring job security ah it's brilliant what could possibly go wrong do you remember that fresco that some woman some poor old woman tried to fix it was kind of peeling and cracked and she basically turned it into a smiley face oh i think so it was like an ancient painting yeah yeah it's yeah i'll drop it in our slack that one oh wait that didn't work that one yes i've seen this one if you've been on the internet you've seen it it looks like jesus got put in a blender or something i don't know yes i'll just touch this up here and it'll be better when i'm done yeah i think of this when i think about tech debt because she correctly identified there there is some damage to this painting but the fix is so much worse and you

can definitely do that with tech debt you can yes you can identify this thing is bad and stand back let me get to work on it and then produce a monstrosity in your attempt to fix it yes stand back don't worry i've got my paints oh my goodness i practiced several times it really is so bad yeah and you could use that in two ways one way is is you convince people that art is subjective and it's all about the experience you have when you view it and really yeah this is art right like no one had heard of this painting until this happened and now it's famous so really it was

it was better you can ask your friends hey did you hear about that multi-day outage on that really popular web service that everyone uses that was my tech debt getting fixed yeah it's like that pirates of the caribbean line where you're the worst pirate i've ever heard of but you have heard of me like this is the worst code i've ever seen but you have seen it you have seen it so that's one way or the other way is is just dampen your foolish optimism that you will solve tech debt and just accept it it's it's tough sometimes you know what to do and you can prove it's going to be better sometimes you don't i do think it's wise to balance tech debt with more i'll say business facing contributions as a as a hedge against the risk that either you create

the the crappy finger painting version of of the fresco or someone likes the old one better or something i don't know there's lots of ways this can go wrong so i i think i think i would make sure to do impactful product work sometimes and i think it also helps ground you in your tech debt fixes if if you are not experiencing the day-to-day life of a working humble developer whose job is to produce code that makes money and you're just kind of focused on the meta you can lose touch with where the actual problems are that affect developers the most. So I think it's also useful to target your refactoring in tech debt. So you're saying you don't want to get down that rabbit hole where you end up creating a development framework and tooling environment whose only

purpose is to help other developers resolve tech debt. Yeah. It's like a tech debt resolution framework. Yeah. It's easy to convince yourself that by stepping back and abstracting more, you're applying more leverage, but you might be abstracting something that doesn't matter. It kind of anchors you in the real world a little more. Yeah. So, I mean, if that's an option, I think that can make sense. Basically, what you're saying is really try to reduce the... Basically, Jamin hates fixing tech debt is what I'm hearing. That is what I sound like to myself. I don't hate it. And I do it sometimes,

and it needs to happen sometimes. But there's a bit of the boy who cried wolf thing going on with me, the engineer who cried tech debt. Engineers always say tech debt, always, always, always, always for everything ever, always. And sometimes it doesn't matter. Yeah, it sometimes doesn't. Now, in this case, I'm reading a little into the question

that says, we launched our product and then have had constant fires due to tech debt. So what I think is actually probably happening here is that they took shortcuts to get the product launched fast and surprise when the product had first contact with users it was like all these little things all these little shortcuts you took came to light in the form of it doesn't work you know which is very different from our code needs to be refactored and it needs to use behavioral driven design sensibilities yeah exactly you know we we need you know insert style du jour yeah that needs to happen now or else i

can't work in this code base anymore but i don't really think that's what's happening here i think we have like in in this case a whole bunch of fires and only one person who can put them out and that can be i think that can be bad for your career over time if especially if it degenerates or devolves into a dynamic where you have one team member who fixes the messes of all the other team members that's just a self-fulfilling uh vicious cycle because the developers never get to learn a firsthand, they never get to learn basically accountability for the stuff they create and owning it.

Instead, they're just like, man, all the code I write, I never hear any issues about it. I must be the best developer ever. And I'm so fast at it. All these shortcuts that they warned me wouldn't work, work fine. And so, you know,

if you have that dynamic going on, one way to resolve it is to force the team, which can be very hard after a fresh launch, but force the team to round robin assign this tech debt to be resolved and you might have to actually pair program with the first few iterations of this it's also good for the team to spread the knowledge around a little bit i think if you told your manager you know how our software is broken all the time i'm the only one that can fix it right now let's make that not the case they they would they would be in favor of that yeah if you said that right now like they would instantly

freak out probably which is exactly what you want yeah you want them to freak out dance to your your tune freak out in the way you want yeah exactly good control manipulate them or you're coming out of this thing with a retention bonus you know one way or another yeah unfamiliar unfamiliarity with the part of the code base i mean yeah you gotta learn sometime so i think it's I think it's fair to express this as a risk and try to reduce it by involving more people. I also, I got off onto tech debt and in my head, I was thinking a lot about refactoring and kind of changes that, and especially the therapeutic stylistic refactoring. But yeah, thank you for bringing me back to the question. It's broken. I wouldn't even call that tech debt. I would say

i'm fixing our product you know how it's broken like yeah i'm i'm making us more money by reducing the amount of people that hate our guts yeah exactly so maybe there's a way you can reframe it from tech debt to bugs uh yeah bug fixes or performance enhancements or finishing features or something yeah in fact that that's a really good point you know as engineers we often will describe the root cause instead of describing the important business symptom. And in this case, the business symptom is the product isn't working. Yes, we all know it's because we took shortcuts when we shipped the first version, but your business doesn't really care about that. What they care about is getting the product online and working for customers. So why wouldn't the

whole team be focused on this? Why is it just you? Why is the rest of the team moving on to build new features while you are the only one keeping the actual features that are producing revenue online yeah that's a way to frame it if there's i've actually worked with someone who felt this way and i think they were right to some extent where they they felt like they were unduly bearing the burden of fixing stuff and one of the things we did was establish a rotation on the team yeah we've done so that it was it was like so-and-so's week to be on point for fixing stuff that popped up and that everyone was willing to do it no one was unwilling to do it it's just that this person was very responsive and and pretty quick at fixing it so they would just

jump on every grenade before anyone else could respond and then instead we we appointed a designated grenade muffler grenade flopper this week it's your job to throw your body on the grenade before it explodes yep exactly my turn that was really helpful for a lot of things it helped this team member feel better i think it helped all the other team members too because they felt like things were more equitable and they were they were doing their part a little bit more and they all got thrown into more parts of the system and kind of yeah the exposure of of seeing what is happening in places you're not as familiar with yeah because no one actually likes it when there's someone else on the team who does who's the only person who does the hard and

painful stuff yeah yeah well have we answered this question i think so good luck it's a challenging situation short answer yeah this is harmful in ways that go beyond just your own career development it's probably harmful to the team as well and i would try to resolve this and and spread the responsibilities around yeah all right well thank you for listening what can people i did it out of order what is going on well i say thank you for listening last well we are recording we are recording this on friday the 13th yeah that's fair cursed star crossed dave what can people do if they want their own questions answered. Go to softskills.audio

and click the ask a question button. And I just want to say thank you to everyone who's writing in. We need to do kind of a meta analysis of all the questions that come in because right now I'm sensing a theme of burnout. I don't know. I thought I'd just throw that in,

but I read a lot of questions today and it's just like, what do I do about burnout? It's kind of the common question. I'm not going to answer that right now because the show's over, but thank you for writing in. Yeah, thank you for writing in.

And if you have a question or if you would like to tell us how we did on one of our questions, which by the way, some people have been writing in and we love it. We got to start reading these on the show, but if you want to tell us how we did, just use the same form.

Just go to softskills.audio and click ask a question and then disregard the instructions with reckless abandon. And instead of writing a question, write an answer. Go wild. All right. Thank you for listening again.

Two thank yous. Yes. Aren't you lucky? We'll catch you next week. Thank you.