Soft Skills Engineering - Episode 452: Consulting refactor and extra work, extra scrutiny

Episode Date: March 17, 2025

In this episode, Dave and Jamison answer these questions: I’ve been a developer for about 1.5 years. I work for a large consultancy. we provide services to big clients. I’m working on a front-end codebase that has been through three consulting companies already. Tired of just moving tickets and fixing bugs, I decided to refactor the front end of the entire application we support. Touching the codebase to add features gave me a pit in my stomach. No integration tests, no staging environment, huge functions with tons of parameters, etc. The client provided technical guidelines that were pretty solid, but the code just didn’t follow them at all. In the time left on the contract, I refactored the codebase to fix the biggest problems to align with the client’s technical guidelines. I did all this without my manager/PO/PM asking me to. But now, how do I communicate what I’ve done to the client and my manager? Can I get any recognition for it? A listener named Mike asks, I’ve been in my role for about 1.5 years in a dev team of 7. I really like the job, it has a good culture and I’m learning. Sometimes I channel my desire to learn into improving our projects with small, self directed changes on my own time. I these changes are useful but aren’t high enough priority to make it into planned sprint work. I don’t inundate the team with these requests, it happens maybe 1-2 times a month. We make a point of working in small steps, usually submitting several PRs per day each. I really like this approach, and I also keep my occasional self-directed bits of work small in scale. However, I’ve noticed these PRs receive more scrutiny and more “whataboutism” that our regular on-the-books PRs. For example, for regular sprint tickets there’s an understanding that we’re making progressive improvements or building small pieces of features that exist within the constraints of our systems. We might flag broader improvements to consider, but there’s no expectation to re-boil the ocean every time we want to merge code. When I submit a self initiated piece of work there can be a long back and forth of suggestions that can involve changing other dependent code, changing internal APIs which may have side- effects, and generally a level of defensiveness in the code that we never normally expect. I understand that by submitting off the books PRs I am requiring some work-time from reviewers, but there is more pushback than I’d expect. It feels like because I get the ball rolling on my own time the normal cost-benefit constraints go out the window, and the code purists come out to play. Could I be annoying the team with these submissions? Have you experienced team members doing the same thing? Is there a way I can scratch my own itch by learning against our systems without creating this resistance?

it takes more than resolving deadlocked technical disagreements by picking number three to be a great software engineer this is episode 452 of the soft skills engineering podcast where i am your host jameson dance i'm your host dave smith soft skills engineering is a weekly advice show about all the non-technical things that go into the technical field of software development like arbitrarily deciding to move forward i love it it's like the simpsons movie yep president schwarzenegger yeah option three i was elected to lead not to read that's what you shout as you arbitrarily decide yes that's leadership yeah yeah it's not reading that's true dave do you want to thank our patrons yes i do big shout out to those who contribute at

the just absolutely unhinged level that causes us to read whatever they type in for their patreon profile name they are noah labhart it takes more than a witty name on patreon to be a great engineer do you really love us or are we just means to yacht can it be both alexander kuznetsov chris morton nick molyneux attribute error none type object has no attribute to string javier gonzalez chewy ted timbrel i quit my job it's 2025 oh my god what have i done alexa alexa alexa alexa turn off all the lights become a senior engineer.com is a newsletter you should read unsalted french fries are morally objectionable generating side projects with ai so jameson notices my resume dan from drone deploy chase w norton never is not just

a creator on mars flamingo emoji i like chicken i like liver meow mix meow mix please deliver trash panda get status kyle boss can't see dodds hold on a second i have to sneeze nevar is not just a planet in the vulcan system jenny kim the stochastic parrot helicone.ai best observability tool for ai red panda is best panda java is just discounted c-sharp with worse documentation Jonathan Kings and I beautiful functional user documentation Polish words that are

impossible to pronounce dang it I told myself I would learn to pronounce these this week and I didn't the letter W that's probably wrong okay

William Angel dot net has cookies please accept all cookies we process your data in the United States to opt out go to Oogala Boogala

not my chair not my problem that's what I say Brayden Keynes John Grant Brittany Ellick Joe Grossberg wow I really botched

the pronunciation of that one sorry about that please write in and we'll send you some stickers if this is the best part of your week please spend more time

with your kids oh I feel called out but also appreciated simultaneously by our wonderful listeners yes and we also appreciate you thank you so much

wow that was a great one great round Appreciate you. Dave, I want to tell you about WorkOS, which is sponsoring this episode. They have launched a ton of new, useful stuff that you should know about, which we will tell you about a bit later in the episode. Thank you to WorkOS for sponsoring. Yes.

Go, WorkOS. Do you want to read her? Sorry. I'm just randomly inserting things here today. It's all good. Randomly read our next question. I will. This comes from an anonymous listener who says,

I've been a developer for about 1.5 years. I work for a large consultancy. We provide services to big clients. I'm working on a front-end code base that has been through three consulting companies already. Ugh, that sounds not fun. Okay, tired of just moving tickets and fixing bugs, I decided to refactor the front-end of the entire application. Touching the code base to add features gave me a pit in my stomach. No integration tests, no staging environment, huge functions with tons of parameters, etc. The client provided technical guidelines that were pretty solid, but the code just didn't follow them at all.

In the time left on the contract, I refactored the code base to fix the biggest problems to align with the client's technical guidelines. I did all this without my manager, product owner, product manager asking me to. But now, how do I communicate what I've done to the client and my manager? Can I get any recognition for it? How do I communicate what I've done sounds vaguely guilty. Yeah, that's what I was thinking. what have I done? The next sentence is, how do I get recognition for it? And I was thinking, oh, that's not where I thought this was going. I've never worked at a large consultancy. I have

been a consultant though. I don't think I would have done this without some kind of communication upfront saying, look at this awesome thing I'm going to do. I have done, I mean, I've done small refactors and just kind of the normal cleanup that you do as you're building stuff. But I haven't just said, hey, I'm going to take these hours that you're paying me for and use them to completely overhaul the code base. And I think it's hard to tell them after the fact, because what they might think is, wait, what about all the features that we wanted that we didn't get because of all this time that you took? I guess it depends on the contract. And maybe you did deliver all the things they asked for, and this was just sort of extra that you added on. But if it wasn't,

If delivery of the stuff they explicitly asked for slowed down, then you're probably in trouble for getting credit for this. Right. It's so tricky because there are things that as a developer you know are going to make the work go faster and have fewer bugs in the end. But sometimes it's really hard to explain those things to the person signing the check. And it's even harder when it's a consulting relationship. I think those incentives and that communication is tricky when it's working for the same business and you expect to have this long relationship with the code base and the people signing the checks. But often consulting is like explicitly like cowboy code this thing out as fast as possible. We just want you to crank out these features and ship it and not worry about tomorrow because tomorrow will be another consultant. Right.

Get in, get paid, get out. Yeah. But I think what you do have going for you is these client technical guidelines. And I think the way that you can pitch this is if you have delivered all of the features that they asked for and you're not behind on that, they're not going to say, wait a minute, but what about all this stuff you didn't get to? Then I think you can pitch it as I also kind of went above and beyond to help follow the technical guidelines to make sure that the people who work on this code base in the future

will be better off. So you should see benefits in the future from this. That's kind of like the classic pitch for it. But I think you can say that and explicitly point to the technical guidelines. There is a risk. You've been a developer for a year and a half. I feel like that's still kind of the youthful exuberance phase. And there's a risk that you've been like blog post sniped into like, I don't know, everything.

You read a blog post about reverse Polish notation and just decided like, ah, that's good code. That's what good code means. and you just got really passionate about something that doesn't actually make a huge difference in the code base. So maybe get some eyeballs from other more senior folks to kind of back you up on this, that you're not just like following

your preferred linting style or whatever. But I think you can say, basically, I've bought you future speed. You're welcome. Yeah, like, hey, I went above and beyond and I got the project done on time and in scope and under budget. And while I was in there, I did a bunch of cleanup.

Yep. So as a result, we should see fewer bugs in the deliverable immediately. And long-term, our next feature request will be able to go faster. Yeah. Great. That's a good internal message. Now, should you tell the client, and I think there's a real chance that you tell the client, hey, we delivered everything and we made a bunch of improvements as well. The client might come back and say, I don't want to pay for that part. Yeah. I think that's what your manager gets paid for. You should tell your manager this and leave it to them to decide whether to communicate it to the client. Or should you give your manager the gift of plausible deniability? Wait, what do you mean? Your manager is unaware of this extra work that you did, so they can't

bring it up in a meeting and it can never be a question from the client of whether they should pay for it. I will tell you what you shouldn't do is you shouldn't say, man, all these consultants that touched this code base before were horrible. They just made the dumbest decisions. They totally screwed this thing up but good news i fixed it because they have heard that so many times the developer who cried wolf it is it is classic to say hey everyone who touched this before me was a moron yeah but good news i unlike everyone else that has ever touched this code base i am not and i did it right and the next person that touched this code base will surely not say hey everyone else who touched this is a moron but i fixed it i did it right and your client will say

you know, the last two consultants said the same thing. Yeah, exactly. Yeah. You kind of lose credibility by saying that. Hmm. Well, have we answered the question? I think so. And the summary in my mind is that, yeah, it would be great to take credit for this, but only take the credit after you can show the results. Like, hey, remember those features we shipped a few weeks ago? Well, that's thanks to a little bit of cleanup work that I did while I was in there. You know, hey, I was already there. You know, I really don't think you should pitch it as I spent a bunch of extra hours but rather i did some cleanup the code's in a lot better shape now notice how there hasn't been bugs and notice how we've been able to deliver features faster well that was thanks

to all that cleanup i did and it is it is a good idea to take credit for that and get recognition and especially internally but but probably not externally i think the client would just be like what do you mean you didn't clean it up like if you you know it's like would you say the opposite like hey this code's a mess but i left it a mess you know probably not right yeah so yeah i think that's what I would do. Jameson, we've been talking about WorkOS a lot, and they have added some very useful stuff to their product. Now, WorkOS is not just for adding SSO to your app. It's so much more. They've launched some cool stuff, and we will tell you about it. WorkOS lets you not reinvent permissioning with their new fine-grained authorization system,

which is based on a Google system white paper thing called Zanzibar. Very fun word to say. I've actually built some fine-grained auth systems myself, and they had a way more boring name. and also i had to maintain all the code myself yes also check out work os's radar feature which can block bad signups from your app so things like bots fraud and impossible travel like someone using a vpn or proxy to trick your signup system they can detect all of that for you and help you avoid fraudulent signups they launched an entitlements feature that integrates with stripes your app can automatically give access to accounts that have paid for new features I've also built one of these myself and it can be a huge pain in the butt so nice to put that

on someone else yes totally to me the coolest feature they launched is a b2b app starter kit for next.js work os will actually help get your next.js app essentially from zero to one super fast they provide authentication billing user management audit logs and a ton more and I gotta say if there's an easier way to start a b2b sass app than work os I can't think of it do not forget the passkey support it's effortless for you to add passkey support and your users will love it check out workos.com and try out all these amazing new features shall i read our next question yes you shall i command it all right my wait my wish your wish your command is my command i think that's how it goes i think that's right a listener named mike asks i've been in my role

for about a year and a half on a dev team of seven. I really like the job. It has a good culture and I'm learning. Sometimes I channel my desire to learn into improving our projects with small self-directed changes on my own time. These changes are useful, but aren't high enough in priority

to make it into planned sprint work. I don't inundate the team with these requests. It happens maybe one to two times a month. We make a point of working in small steps, usually submitting several PRs per day per person. I really like this approach and I also keep my occasional self-directed bits of work small in scale. However, I've noticed these PRs receive more scrutiny and more whataboutism

than our regular on-the-books PRs. For example, for regular sprint tickets, there's an understanding that we're making progressive improvements or building small pieces of features that exist within the constraints of our systems. We might flag broader improvements to consider, but there's no expectation to re-boil the ocean every time we want to merge code. When I'm submitting a self-initiated piece of work, there can be a long back-and-forth of suggestions

that can involve changing other dependent code, changing internal APIs, which may have side effects and generally a level of defensiveness in the code that we would not normally expect. I understand that by submitting off the books PRs, I'm requiring some work time from reviewers, but there is still more pushback than I'd expect. It feels like because I get the ball rolling on my own time,

the normal cost benefit constraints go out the window and the code purists come out to play. Could I be annoying the team with these submissions? Have you experienced team members doing the same thing? Is there a way I can scratch my own itch by learning against our systems without creating this resistance? Hmm. I got distracted looking up whataboutism.

You have a definition? Yeah. Well, I have a Wikipedia page. That's authoritative, right? Yeah. It's whataboutism or whataboutery, which I kind of like. I have not heard that one. I kind of like that one better.

I like that one better too. It sounds like tomfoolery. Yeah, exactly. So good. Whataboutism is the strategy of responding to an accusation with a counter accusation instead of a defense against the original accusation. That's not how I've heard this term used in argumentation in the past, which leads me to believe that the people I've been arguing with don't know what this means, or at least

don't agree with Wikipedia. Yeah, I thought that this applied pretty well to this situation, and I guess it doesn't according to the Wikipedia definition. Okay, so what did you think it meant? What I thought it meant in this situation is you submit a PR, maybe it moves the line of code around. It doesn't change the line of code. It doesn't change any of the dependencies. But because you touched it, all of a sudden it's like, wait, this line of code that you have touched is wrong and needs to be changed. And you're like, it's not the scope of what I'm working on. Or doesn't follow some convention or something? like yeah like yes i changed the indentation because i surrounded it in an if statement now but i don't want to rewrite all of the code that is related yes because i don't want to

rewrite the whole code base just to make this one change but maybe maybe they mean it more literally and it's like in these back and forth discussions of feedback on the pr and then what about ism got it what aboutery what about they say well i think that's out of scope and then they bring up the insults that you made to their heritage that one time or i don't know interesting so is that the situation you think that's going on here is that there's there are incidental code changes that show up in the diff but aren't actually the substance of what the author is submitting the change for yeah i think that's part of it i mean the situation the author describes is their off-the-books changes

are held to a much different standard than the regular sprint work. Than other things. Yeah, and so there's an understanding in the regular sprint work that this is iterative and this will be improved and tweaked in the future.

And it sounds like everything must be perfect for these kind of off-the-books changes. Yeah, have you experienced this? I'm not sure that I have. I have experienced it. Not the same style of like, well i'm doing kind of side side work work it's still work but but i have experienced this vibe of like i am not going to rewrite this giant abstraction just because i i added a line to it

yeah but this person is asking me to right you're like no yeah i haven't experienced it consistently from the same person though so my in my experience this has usually been someone who's doing a distracted code review. They're not taking the time to dive super deep into it and they see a line and it's green and they just look at the line and say, ah, that line looks wrong. It should actually look like this, but they haven't rocked the change enough to understand, wait, that line has just moved around. It's not like you wrote that line. Yeah. And then I guess the extra element here in this question is because this stuff is submitted outside the normal work process, i wonder if there's a perception that they have more time and they can do more scrutiny whereas

if it's part of a sprint it's like oh look we do one week sprints and we all know we're under the gun and no one wants to be the reviewer that holds up a sprint deliverable and then causes the team to miss their commitment for the week or something like that yeah maybe they're they're super intense about sprints and you have a deadline every week which sounds not fun but exists i have been on the other side of an engineer who would regularly throw in pretty sizable extracurricular changes that were not related to the business-facing work that the team was doing. And I actually told them, please stop. And the reason I told them to stop was explicitly because it took time away from the team to review this stuff. They had to context switch. Sometimes the changes were pretty broad

to like underlying tooling it was it wasn't ever like i added this feature or whatever that the customer asked for it just out of order it was like i'm changing this underlying technical developer system that we use and i i said please do not do that anymore explicitly for this reason that that it was distracting the team and slowing down our normal work interestingly enough i am a hypocrite because sometimes i do that to my team but if i do that i mean sometimes i submit prs like that and distract them. But it's okay, because it's me doing it now. So my point is, could I be annoying the team with these submissions? I think yes. It could be that they are frustrated by trying to get all their sprint stuff done. And also now they have this

extra stuff to review. And they're not clearly communicating that. And that frustration is coming out in really very persnickety PR reviews. You should ask them. You should say, hey, I want to learn. I want to do stuff. I feel like a good way to do that is poke around and make these improvements i do it on my own time outside of work i'm not missing work time but like does this bother you are you concerned with the way i'm doing this i think you could just directly ask that question yeah i think and i think that's probably a very likely explanation for what's happening here maybe even subconsciously people are like hey yeah this is a distraction why can't you get with the program and just be with us on the team and why can't you carve out actual sprint

time to do these things if it's so important and now you're taking away from my sprint time to do these reviews. And so subconsciously they're doing anything they can to punt your PR. Yeah. They're just a little grumpier when reviewing it. Yeah. I think you also hit on a good potential solution, which is if you want to learn and you're passionate about improving stuff, I don't know, Google had their 20% time or maybe they didn't. It depends. Maybe it was always a myth. I don't know. But you could advocate for either specific targeted improvements to be made in the sprint or just to say like, hey, I want a teeny bit of capacity also to do some of these improvements to learn. And the point of putting them in the sprint is it prioritizes them against

other things that are typically more business facing. And it's not that they don't have value if they're not business facing, but it's easier to articulate the value of a new feature to the business than the value of like i tweak this underlying abstraction yeah and so you might have to do a little bit more work to to justify it up front yeah makes sense or you could just go all in right they say change this underlying abstraction you say okay no problem and then you go off and yep 10 000 lines later that feels like a doom cycle though it's like you come back and they're like okay thanks now do this other impossible task yeah you must cut down the largest tree in the forest with a heading yeah if you like the team it's got a good culture

i feel like you should be able to ask what's going on fairly openly and discuss it and it might lead to i i think i agree with you dave that it could be subconscious on the part of your teammates that it might not be them directly saying aha out of sprint work i will now put on my my pendant hat my pendant pendant pedantic pendant yeah oh no the pedant pendant pedant is that what it is pedant yeah the pedantic the pendant of pedantry yes that's a great one we need to get some of those so maybe talking about it helps them realize this and then it brings it out in the open yeah that's probably better all around i had a developer on my team last year who said hey i'm i'm really interested in getting more familiar with a specific set of technologies. And I've noticed

we have a big pile of tech debt that we keep not getting to. Can I volunteer to work overtime and for my own benefit and also for extra pay to develop these skills and burn down this tech debt list? And I was like, yeah, that sounds awesome. So we just created a really simple tracking system, little document, you know, created tickets in our normal sprint that this person could work on. And we communicated it with the team, everything was above board, and we got a ton of value out of it. And it was really, really lovely. And everyone is happy with it. Now, if that person had just like blindsided my team with like, hey, I want to move this service from EC2 over to a serverless architecture. And look, I did it. And here's the PR. I think

everyone would be frustrated, including me. Yeah. Because I would have thought, you know, as the leader of the team, it's one of my jobs is resource allocation and time allocation. Like, what are we going to spend time on? And when you take that opportunity away from me by just choosing unilaterally to spend your time on something that I didn't even think about, it's not good. Like everyone's frustrated with that. And so it's like the same actions with a little bit of preamble make for great outcomes as opposed to doing those actions without the preamble and then everyone's mad at you. Well said. You just liked it because I said the word preamble. Always a fun one. I actually have a preamble pendant. Ah, you've got all manner of

pendants yes you might say i have a plethora all right have we answered this question i think so good luck good luck mike it sounds like you are well-meaning and you've got a good team so i think it'll turn out all right yeah and good luck with all the refactoring that's always fun for you someday you'll learn to hate refactoring but today is not that day yeah other people's refactors are are your nightmares refactoring is like when you want there's that thing you want to buy and you really work it up in your mind and then you save your money and you plan and then you buy it

and you realize that wanting the thing felt better than having the thing. You ever had that experience? Yeah, the anticipation is great. Yes. Saying refactoring falls under the hedonic treadmill is real for code quality also, I guess. I promise I'm not going to say this,

spend much more time on this, but it is the case for me that every time I've embarked on a major refactor, I look at the code and I just think, this is going to be so nice when it's all cleaned up and then i do all the cleanup and i'm like i feel the same like it's just yes the code is cleaned up but i just don't get this like amazing sense of accomplishment like ah oh i thought that by changing the code i would change myself

alas unless i just didn't change the code the right way surely this next time i will change myself by changing the code but if you do the refactor together then at least you make friends along the way yeah fair enough and that's the real valuable thing and that does change you making friends you know what else changes you asking questions of the soft skills engineering podcast how can people do this go to soft skills.audio and click the ask a question button where you can fill out our form our form that faithfully serves us and has for many years we thank you one and all who have contributed questions to that lovely form that have gone into our backlog whose depth is proportional to my self-worth so thank you for making it bigger

i really appreciate it i do too i appreciate you increasing dave's self-worth my sense of self-worth is is proportional to dave's sense of self-worth so with a like a 1.3 multiplier on it yeah yeah so i'm even i'm doing even better thank you all thank you for listening we will catch you next week