Soft Skills Engineering - Episode 464: Rehiring an overpaid boomerang and AI has taken over my teammate's brain

Episode Date: June 9, 2025

In this episode, Dave and Jamison answer these questions: Mr A. N. Onymous says, Hi Dave and Jamison, Long time listened, second time caller! I wrote a little while back with a common new-manager question about how to handle one of my reports who was at the lower end performance wise, but at the top end on the pay scale. I’d been trying to manage it by getting raises for the rest of the team in order to balance things out a bit (and make the rest of the team happy). I did consider Limogeage but having them on the team was better than a vacancy. Fast forward a year or so, and the problem resolved itself when this team member left - or so I thought. We’ve had a few months gap before opening recruitment again, and it turns out this team member wasn’t happy at their new role and has applied to come back. Given they negotiated well with us the first time I’m guessing they’ve had a healthy pay bump at their new role. What should I do? On the one hand I know their performance, they do deliver well and I’m happy working with them and managing them. Would it be rude to offer them to come back at their previous salary (assuming they’re the “best” person when we interview)? Will they be offended if we don’t offer them the role? We haven’t had interviews yet - so help me Dave and Jamison, you’re my only hope! AI has taken over my team mate’s brain. HELP! I work for a ~10ish or so team building a B2B finances related app for several platforms (mobile, web, backend, etc). On the Web team, there’s only two of us. I’ve been on this team for around 4 years now, and during this times I’ve had several coworkers (the previous ones have either left the company voluntarily or involuntarily, moved to other teams, or completely left the field). I’m 100% convinced it’s not because of me, so let’s take that out of the question right away :-). All of this to say is that I tend to be the person that knows the most about our (quite large) codebase. We work on a ten-year-old React application with some technical debt, but overall I think it’s pretty good. My coworker comes from Android development. While he’s a great developer and has AMAZING soft skills (probably a listener of this podcast!, or maybe not because he has not quit yet?) he’s a little bit lacking on the general “Web Stuff (TM)” knowledge and many of the specifics details of our codebase. A bigger problem is that he seems to have totally given up on learning web skills or understanding our codebase and is instead just tab-tab-tab-ing autocompleted AI crap all over the codebase. His code works as expected, but when reviewing his PRs I feel like a slave of the AI. I’m not reviewing another human’s work, but just what some AI model is doing. While it works, it’s terrible code for another human to maintain. For example, there’s lots of “inline” crap that we already have utility functions or libraries for, regexes everywhere, custom CSS all over the place instead of using our design system, abuse of the CSS cascade instead of using our CSS-inJS solution, large files with lots of code repeating existing logic that’s already somewhere else, and code comments every 2 lines or so which provide no value, but that’s what AI does to explain things. I’m not against AI (I also have explicitly to say this to prevent it killing me in the future). I use it for explaining things to me, writing utility functions, suggesting improvements, or as a google search replacement that saves a lot of time. But leaving AI to do your work mindlessly while you sip orange juice and watch how it codes is wrong. We’re not there yet. These PRs work and are difficult to reject because management wants to ship fast. However, they are harming the codebase. We’ll get to the point where only AI will be able to touch it due to the amount of repetition, duplication and overall non-human friendly code. How do I tell this person “Please stop doing this and instead learn things properly, and use AI as a tool and stop you being the tool of the AI” without hurting any feelings, and without being seen as the AI grinch? Thanks for your help! Love the podcast, and why scroll keeps jumping up when writing on this form? Seems like AI is boycotting me.

it takes more than replacing a magic number in your code with a constant called magic number to be a great software engineer this is episode 464 of the soft skills engineering podcast where i'm your host james and 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 making your code just that much more readable you got to make the magic explicit yeah this is episode magic number we'll replace that you're welcome yeah see now we've generalized the podcast i actually have a funny story about magic numbers that goes way back and it's a little self-deprecating shall i tell it it sounds perfect so like 20 years ago someone was so i was doing

c++ and of course you know c++ is all about the macros where you can define constants and use them your code like that's that's a big thing and i say like i know i have not written c++ for money ever oh really okay well i i didn't know i was better than you until this moment isn't that kind of a superiority thing like anyway yes so someone was telling me the story they were making fun of a developer someone else wasn't me i promise and they were saying how they had a policy on their team that they would not do any hard-coded literal numbers in their code they all needed to be defined you know in constants and then in the code you would just have named constants instead of literal numbers like in the actual bodies of functions and stuff i'm like okay and so apparently

so they were making fun of this developer because the developer said oh yeah i i replaced the number one with a constant one yeah pound define one equals one and i at the time so this is how dumb i was 20 years ago at the time i remember thinking like yeah it makes sense and now when i think back on that i'm like oh yeah that is really that that is like completely missing the point it's kind of like piano numbers i don't even know how you pronounce that but isn't there a thing in like math slash functional programming where you can define the natural numbers sort of like recursively and then you you don't type the numbers you you type the string that refers i i'm butchering this but sort of reminds me of this they were just enlightened yeah they're doing Haskell before it

was cool yeah I guess uh but I sometimes think back on that because I remember that that guy was telling me the story and he was he thought it was so funny that this developer had done this and I'm just sitting there like I don't get it now I look back and I'm like he must have thought oh crap another one this guy's also an idiot the the number one spelled out in english will proliferate through a code i know right oh so bad i feel like there's got to be some code base out there that uses some kind of macro wizardry to use roman numerals instead of decimal numbers oh my goodness you could surely that exists you could totally pull that off

yeah right like it's very like since roman numerals are all letters like it works in every language well i know what i'm doing yeah after this podcast you could even make a linting rule that says like if you ever see an arabic numeral in your code it's like nope fails the rule you can only use roman numerals use the wrong use the wrong number system syntax yeah all right that's not what this show is about do you want to thank our patrons yeah sure here we go this is a this is a list of things we read every week thanks to some of the most honestly some of the most creative people on earth way more creative than i was 20 years ago not understanding c++ macro jokes who have contributed a level where we shout their name out every week and i just love

how many of you have taken this challenge to stretch what the patreon name field will let you put in and i just gosh i would love it if someone who works at patreon one day was like you know we've been looking at some analytics and some really weird names out there anyway here we go they are jacob shandling the human in the loop please help the steganography in this name is adversarial to ai croissant connoisseur christy the world's okayest programmer noah labhart unsalted french fries are safe to eat just cut a quarter inch around the crust when do you check the names you keep missing how funny i am uh alexander kuznetsov nick molyneux attribute error none type object has no attribute fetch

dad joke javier gonzalez chewy ted timbrell jd vance fans refrigeration doing my part to make dave's heart swell but he should probably get that checked dan from drone deploy chase w norton never is not just a creator on mars i like chicken i like liver miyamix miyamix please deliver trash panda python summit.ch that's python-summit.ch 16th of october a swiss python conference a swiss conference does that mean it has a lot of holes in it kyle boss can't see the the guy over there that guy over there jenny kim the stochastic parrot simply the word no followed by a period jonathan kings and i beautiful functional user documentation angelical cath or williamangel.net really regrets using ai to leak your specific personal data

even though the vibes were great shut up and take my money brayden canes john grant britney ellick come to the slash new conference in newcastle australia may 28th and 29th oh that was yesterday we're recording this on may 30th finally the conference came i wondered if they would update the patreon dave will you please read our third question that is our final name thank you so much patreon patreon supporters oh we love you thank you for contributing if you would like to join this crew where we say whatever you type into the patreon name field all you got to do is go over to softskills.audio and click the support us on Patreon button, and then sign up for whatever dollar amount it says you have to do to do that. The amount of money just keeps going up

exponentially until people stop doing it. I'm just kidding. That'd be awesome though. And if you contribute any dollar amount, even if it's less than that amount, you can get access to our Slack community, which we apologize for being so late. We've now automated this system. So next month, you actually will get your Slack invites on time instead of just whenever I get around to it. So that is happening. So awesome. Yeah. There you go. Would you say AI took your job? yeah well it was more like what's the opposite of intelligence artificial dumbness yeah that's a simple bash script took your job yes exactly yeah i have a story from a listener that i want

to share all right should i do that i was hoping you would okay they say i want to share my story which is related to the second part of episode 459 i'm an old senior developer and i was a huge jerk i used to overreact to any minor problem yelling at people sending harsh emails and these kinds of things that jerks do sometimes i was also a jerk outside of work and one of those times a friend of mine luckily i was not a jerk with everyone told me stop being a jerk you are not at work then i realized how jerk i was like jerk as an adjective uh until that moment i simply thought i was defending myself from quote aggressions after that i decided that i didn't want to be angry all of the time and i started to change it was hard at the beginning involved a lot

of think twice breathe it's not so important and so on over time i became a nicer person and job relations started to be pleasant unless i find another jerk and i'm really proud of my change is that the kind of thing where like two lions run across each other in the wild and they're like lock eyes and then battle yeah you're fine alone and you see another one no one has ever approached me to tell me i was a jerk in the past but if this happened i would be glad to share my thoughts so i don't think this could be a deal breaker for the person who shared the original story finally a message jerks of the world there is hope stop being an idiot and enjoy the life people around you and especially yourself will appreciate your change wow this is an amazing

story just incredible and they didn't say it but i think it's implied and and we owe it all to listening to your show yes of course no this is great i i hope to have a story like this someday i used to be and now i'm not type of thing i feel like this is what everybody wants everybody wants to change and become better yeah but you're like already so awesome i mean for you it'd be terrible it'd be like i used to be a really great person and now i'm a jerk oh just think how much better i could be though oh maybe maybe it's hard to improve on that though i you know i gotta say how many times in your life have you heard someone tell the story

that it all it took was one carefully crafted or maybe even accidentally crafted phrase like in this case stop being a jerk you're not at work and suddenly it was like boom lights on life-changing moment i've heard this story so many times and i've often wondered like how do you engineer those those there's got to be a long sequence of events before that where people told them similar things that just didn't click right or like something had to prime them for that moment because i i don't know maybe maybe it was just they said the right thing in the right time but i feel like some of it has to be the prep as well i think you're probably right it's like a whole confluence of things happen to prepare their mind for the moment and it could

have been any number of phrases it wasn't like this is a magic sequence of words that unlocked an otherwise totally locked up vault but if it was that would also be cool yeah this is a great story thank you thank you for sharing it really is awesome it is awesome though to imagine because so many times i craft my way of being especially in the soft skills arena around a core tenet that people will not change you know and that people can only choose to change themselves and i can't change them which is actually like 99.9 of the time is actually correct i think like you're just you're not going to change someone in this situation and yet here we go like here's a story of like a 180 it's awesome i have people in my life who are older that i respect very much

that continue to change and learn new things and develop new skills and i just admire that so much because i feel like it's not the norm the norm is you sort of become more calcified the older you get so yeah it's true hopefully i can do that it's true hopefully i'm the rad 99 year old great great great grandpa like skydiving for the first time or something yep all right do you want to read our first question yep let's do it okay this comes from mr a n onimus that's the name i i doubt it yeah i mean i want to believe you okay it goes hi david jameson long time listener second time caller oh wow hey that's that's cool i wrote a little while back with a common new manager question about how to handle one of my reports who was at the lower end performance wise but at

the top end of the pay scale that is a just side note i'm going to insert this that is like a really dangerous place to be for job for job continuity all right continuing yeah i've been trying to manage it by getting raises for the rest of the team in order to balance things out a bit and make the rest of the team happy i did consider limo jage which limo jage this is a this is a deep reference i have totally forgotten this word but we used this word i think james and you introduced me to this word i think no i think a listener did oh there you go and we looked it up and tried to write in and said they oh yeah we call it send them to limoges oh that's right it was a french like colony or something yeah where it's like a it's almost like a banishment to where

you can be no longer uh you can no longer make do harm yeah limoges i did consider limoges but having them on the team was better than a vacancy fast forward a year or so and the problem resolved itself when his team member when this team member left or so i thought we've had a few months gap before opening recruitment again and it turns out this team member wasn't happy at their new role and has applied to come back given that they negotiated well with us the first time i'm guessing they'd have a healthy pay bump at their new role what should i do on the one hand i know their performance they do deliver well and i'm happy working with them and managing them would it be rude to offer them to come back at their previous salary assuming their best person assuming

they're the best person when we interview will they be offended if we don't offer them the role we haven't had interviews yet so help me dave and jameson you're my only hope little star little star wars reference for those that didn't catch that yeah the 1977 classic reference 50 almost 50 years ago is that when it's from oh my god yeah that one is some reason i thought it was from the 80s well most of them are but the first one is 77 wild that was like 20 years ago it's been so long so wild i know it's 1998 right now as i recall i think so yeah so yeah i've got oh i've got big ideas for this web thing

i'm gonna sell books on the internet soon you'll be able to look at pictures on it oh can you imagine yeah if you're very patient you can look at pictures yeah oh boy so i i gotta ask you i got a little lost in this question there was a little piece of conflicting information let me know if i'm misinterpreting this but we had a low performer high paid low performer who left on their own accord and then is now applying to come back but in the second half of the question the question asker says they were a good performer did i misinterpret that they do deliver well who's at the lower end performance wise but at the top end of the pay scale yeah it does feel like a conflict maybe it was a title

thing right there maybe their performance didn't match their title but you can i mean they just they they do get work done it just isn't at the the level of impact you'd expect from their title or salary what what i get from this is that they're not uh they're they're not dramatically awful they they maybe they get along decent with the team and they're kind of a known quantity but just not yeah not not a top performer paid like a top performer and there's something comforting about familiarity it does feel like the question asker is being a little easy on them that's what i was thinking for the question i was thinking maybe absence makes the heart grow fonder where it's like they haven't dealt with the low performance stuff in a few months and it's like

oh yeah i remember that person fondly now yeah i don't remember the the five stand-ups in a row saying i'm still working on this project that'll be done today yeah wait is that all it takes to be a low performer because if so uh i i maybe am one of the lowest performers it'll be done today i swear five days ago you haven't learned how to say it'll be done in five days and then when you actually do finish it today it feels like you're winning no it's a key skill no optimism abounds even after 20 years of yep being proven wrong no i'm i'm more no i'm so much better now i'm even more optimistic it's like it's like my increased ability to deliver has just enhanced my appetite to make unrealistic expectations i just over promise more so that the the lateness

remains constant i'm going a lot faster i'm always just as late as i was awesome given they negotiated well so i don't think there's a way it feels like you want a couple things from this one of the things you want is like i want this person to like me still yeah that which is a bad hiring exactly criteria that's um that's a really unfortunate part of being in management and having to actually make what do they call oh yeah decisions yeah you will not be liked all the time sorry yeah can they negotiate it well would it be rude assuming they're the best person when we interview you yeah like assuming they get through the interview process again which is probably a safe assumption what if we don't offer them the job then okay i mean i don't know you don't just

automatically get your job back yeah for sure especially when undoubtedly there's going to be other applicants i mean this person's going to have a big advantage compared to other applicants because they're going to know the company and know the systems and be able to answer questions that are like culturally resonant you know as opposed to an outsider yeah they know the way we do things here yeah exactly like and of course they'll be able to make the case like look my ramp up time is going to be zero compared to all these other applicants and that that's attractive but you know you were already planning on managing this person out or even considering limo josh wait limo josh means you stash them somewhere you don't fire them yeah you essentially get them you

just get them off your team right i thought it was like you put them in a room and give them fake work and you don't fire them you just don't want to do anything and then eventually they quit it's like the ultimate uh it's like the ultimate passive aggressive yeah like i'm not bold enough to fire you yeah or there's like some legal thing of i don't know you you have a contract or something but if you quit on your own because we make you you miserable enough i guess that's that's your own fault anyways sorry distraction yeah so you were already considering essentially making this person not be part of your team in fact in fact you were so willing to get them off the team that you were willing to keep paying them

and just not have them work. So like you really, it's like I need you to remember you really did not like this person on your team. It's super easy for me to make a snap judgment here. And so I will. I'm not going to qualify it anymore. I think you should not hire them.

I mean, if they were the lowest performer, it doesn't say lowest, lower end performance wise, top end of the pay scale. I mean, I guess you have a few options. One option is to say, we will offer you the salary that we feel like you would deserve and it's going to be lower than what you made before and it's up

to them to accept it or not and it will be awkward because you will be revealing a judgment about them and i don't know it might not go great maybe if they're desperate enough they'll accept it but it'll it'll be weird the other option is to just say no we're going in a different direction you don't have to tell them why you don't have to say oh we had these lingering problems about you and we don't want to bring them back you just you can just say no maybe they know people on the team and that's going to be awkward maybe but i i gotta say like in terms of awkward things you have to do in management this is on the very low end of awkwardness like oh we just we chose someone else you know it's like sorry they were just like super well qualified and everything and the numbers

worked out great and it's a better fit you know easy peasy and what are you doing this weekend you want to hang out assuming they're the best person when we interview so i've been hiring briefly over the past little while and it feels like a in some ways a more bifurcated market you can tell there's a lot of people looking i do feel like there are more high quality candidates out there there's a lot more ai slop as well like in in everything but if they were a low performer i find it hard to believe that they would be the best qualified person that you interview yeah that's what i was thinking surely there's somebody somebody you could be excited about instead of just someone that you know about yeah exactly is this kind of like the Monty Hall game

show problem where it's like this person has already showed you what they are and so now you have a chance to take you get you can take a chance with another option hmm and so maybe you should I think it's like the Monty Hall problem and that I don't understand that or the Monty hall problem these two situations have something in common no one understands oh my goodness no i think i think i see what you're saying there's something in there about like there's value in nope i'm gonna shut up because i don't understand it i already admitted that i'll back up it's basically known quantity versus unknown quantity is like take your risk like you at least know what the baseline is for what you're going to get and so if you think

there's a better chance that you're going to get someone better than the known quantity that you have an option for, then you should probably take that risk. But I think the real, the question this person is asking kind of implicitly is how do I, how do I manage this situation? How do I navigate the situation and not offend this person? You know, it's like someone I want to like me and be friends with maybe, and have a long-term like professional relationship with. And I think the answer is you can say like, look, really appreciated you reapplying, would have loved to hire you, But we just had someone else apply that like looks like they're going to be an amazing fit. And it just was it was just a better fit for us.

Really sorry. You know, hope you can find something great. Right. It's like you can you can navigate that. Yeah. The team the team's in a different spot. We have different needs. Yeah, yeah, exactly.

Exactly. Meanwhile, like as as someone who's making an important decision for the team and for this person and and for your own life and for the business, it's really really important that you separate this like obligation to avoid awkwardness or this awkward let's just call it awkward avoidance separate that from the actual decision to be made here and make the best decision i often think like well you want to avoid awkwardness you don't want to hurt people you don't want to cause you don't want to be the jerk for example like you know even if you think being a jerk could actually be the best thing for the business you don't want to you don't have to be that the point i'm trying to make is that it's very easy for the

human factor to become too heavily weighted in the decision making process because the human factor is definitely a factor in all of these decisions and we want to be humane and good and decent people but sometimes we have this over sensitivity to it where it's like i couldn't possibly do do something to say no or reject a person who i know and it's like why not is it really like maybe in some cases that is the right move is to not reject them but a lot of times it just isn't and so maybe this is just my own heart speaking but i i do tend to at least in the past i've historically had kind of an over sensitivity to those factors and i think a lot of a lot of engineers do as well they're not just like these cold-blooded business killers yeah yeah i you

don't want to hire someone because you would feel bad if you didn't hire them yeah i'm gonna hire someone that you feel will be great for the team well have we answered this question i think so good luck i was about to say it's a really tricky situation but i don't think it is i think on the scale of management trickiness this one's pretty straightforward you have some beautiful words you can say that were i was going to say said by jameson but i think it was me who said them no it was you yeah that's why they were beautiful were they beautiful though i don't know i felt something that felt super arrogant great like i'll call them beautiful okay thank you yeah this is why we have editors to take out the stuff that i say that makes me look like a

jerk just kidding keep all that in anyway yeah good luck i think this is a fairly straightforward to navigate you need to make the best decision for your team and and there's just a one cautionary tail in here which is if you are the highest paid person on a team that is a scary position to be in because management is going to be reminded about that every time they look at their payroll every time they look at budgets they're going to ask this whether consciously or subconsciously they're going to ask this question is this person really a better performer and worth more money than the whole team is this the right amount it's just going to come up whereas when you're in the middle of the pack you can kind of keep your head down under the radar a little more and i'm not saying

like you should strive for mediocrity i'm just saying if you're going to be a high top a top earner you really need to double down on being a top performer yeah wise words those words were also beautiful oh this is why i do the podcast it's just i show up it's my weekly affirmation from jameson it told you say beautiful words well should i say some words that i hoped will be beautiful you should is it reading the next question yeah but yes that that thing someone else's words yeah let's do it i think the way you read them will be beautiful i'm pretty sure okay and i'm gonna do it this is from an anonymous and rough start this is from an anonymous listener who says ai has taken over my teammates brain help i work for a tennis or so team building b2b

finance related apps for several platforms mobile web back end etc on the web team there is only two of us. I've been on this team for around four years now. And during this time, I've had several coworkers. The previous ones have either left the company voluntarily or involuntarily moved teams or completely left the field. I'm 100% convinced it's not because of me. So let's take that out of the question right away. I tend to be the person that knows the most about our quite large code base. We work on a 10-year-old React application with some technical debt, but overall, I think it's pretty good. My coworker comes from Android development. While he's a great developer and has amazing soft skills probably a listener of the podcast or maybe not

because he has not quit yet he's a little bit lacking on the general web stuff tm knowledge i think that means trademark the trademarked web stuff knowledge and many of the specific details of our code base a bigger problem is that he seems to have totally given up on learning web skills or understanding understanding our code base and is instead just tab tab tabbing auto-completed ai crap all over the code base nice his code works as expected but when reviewing his prs i feel like a slave of the ai i'm not reviewing another human's work but just what some ai model is doing while it works it's terrible code for another human to maintain for example there's lots of inline crap that we already have utility functions or libraries for regex is everywhere custom css all

over the place instead of using our design system abuse of the css cascade instead of using our css in js solution large files with lots of code repeating existing logic that's already somewhere else and code comments every two lines or so which provide no value but that's what ai does to explain things you totally we were talking about this on my team i actually like those comments as a way to say hey i wrote this code oh it's like a very clear yeah it's like a very clear signal like hey this was written by a do it that way you will meaning you can critique it without hurting anyone's feet yeah critique it ruthlessly yeah exactly i'm not against ai i also have to explicitly say this to prevent it from killing me in the future i use it for explaining

things to me writing utility functions suggesting improvements or as a google search replacement that saves a lot of time but leaving ai to do your work mindlessly while you sip orange juice and watch how it codes is wrong we're not there yet these prs work and are difficult to reject because management wants to ship fast yeah however they are harming the code base we'll get to the point where only ai will be able to touch it due to the amount of repetition duplication and overall non-human friendly code how do i tell this person please stop doing this and instead learn things properly and use ai as a tool and stop you being a tool of the ai without hurting any feelings without being seen as the ai grinch thanks for your help love the podcast and why does the scroll

keep jumping up when writing on this form seems like ai is boycotting me apparently we have a ux problem on our question submission oh yes the ai grinch no i think this is the ai ebenezer scrooge maybe i feel like this dynamic has to be playing itself out on teams all over the place oh yeah yeah we're just in a in a topsy-turvy world with new stuff introduced that uh people are still trying to figure out how to do it yeah you know this is oh this is such a this is such a great example of like this story has repeated itself all over the place for the last 20 years of my career just replace ai with whatever the tool was at the time where you kind of go a little bit mindless and use the tool without applying that like judgment to it i feel like ai is

much more effective when you use mindlessly than these other tools though oh yeah for sure you can you can like uml diagram a little bit but it won't work or you can just you just vibe code your way into something that works yeah exactly exactly it which is why it'll be a bigger problem i think yeah are we gonna boy now i'm starting to feel philosophical are we going to essentially ai ourselves into a box that we can't get out of without ai i have so many thoughts here i think i'm on the more optimistic end of the ai for software development spectrum so that's my upfront i don't know admission i guess is this you trying to not get killed by the machines no no i think i think it's super useful and empowers me and makes me produce better

code and better products for users and has accelerated it's it's feels like it's still getting better faster what is my point my point is it does have a lot of weaknesses and it takes skills to use well, and those skills are not necessarily the same as the skills to write code by hand well. And so it's possible that someone can be really good at using AI to accomplish a task, and they're better at that than they are at writing the code by hand. And does it matter, I think, is the philosophical question you're asking. I think there are people who think the code is going to be sort of like assembly of the future, where the AI is sort of the compiler it's kind of the underlying artifact produced but you work in a different medium that's

a bit higher level yeah the people disagree heartily with that because there's all kinds of non-deterministic things and your compiler doesn't have like hurt feelings or write poems or something you know doesn't randomly insert a haiku yeah it doesn't tell you no i'm not going to do that actually my compiler tells me that all the time yeah but it's predictable yeah and it's right yeah so i what is my point here i do think the part that makes me feel still still somewhat old-fashioned is i feel like this is all enabled by a deep understanding of the code base and it gets more dangerous the more you do without understanding the code base for sure i mean eventually you build a rube goldberg machine that you yourself are unable to manage anymore but

doesn't matter right like if the ai can do it it will only matter if the ai is not able to like if context windows aren't going to grow enough and be effective then there will be a cap on how far you can take this pattern like in fact that's what i'm seeing here and forgive me i might wax a little bit technical here but what i'm seeing here is that this the ai tools this person is using is is repeating code and functions so thereby introducing entropy into the code base because the ai probably its context when it isn't big enough to understand that it's duplicating things you know it's just like i just can't see that stuff like i didn't even i had the i had no way of knowing that these these utility functions exist or that these css patterns already exist and

are established somewhere else and you're now introducing a new pattern which admittedly is a problem that humans have as well but once you tell them they just can't do it as fast yeah exactly and once you tell them they kind of remember for next time you know and and i guess ai could presumably do that but the amount of context necessary to do this effectively as long as it can grow smaller than the ai's capacity for handling context grows then we'll be fine but if those lines ever cross and you get more context is necessary than what our ai tools can handle we will eventually have a pile of code that neither humans nor ai can work on yeah on my team we like i said we have a spectrum of ai i don't think we have any deep skeptics but kind of ai

maximalists to sort of like hand crafter types where they they they prefer to do it by hand and value doing it themselves and a few things we've adopted as a team are one it doesn't matter if ai writes it you still have to be able to understand it and defend it like we're going to review it the same no matter who wrote it so if an ai wrote it if a human wrote it we're still gonna review it the same way to address the two to address this pattern thing that you mentioned like you said there are ai tools out there for providing extra context and if you if you produce output with ai that doesn't follow the existing patterns then we need to nudge the ai so that in the future it produces output that follows our patterns a bit better which is not always easy

but for a lot of this stuff of like hey we use i don't know shad cc shad ui is that the one i don't know we use this specific ui toolkit framework sure stuff like that is easy to drop somewhere and just include every time you talk to the ai and then it's pretty decent at following those things and then three we also are very lazy about reviewing ai written test code so that's like the one exception of you have to write it you have to be able to understand it all very deeply like you glance through it make sure it works make sure it isn't just hard coding results that only work with the code it wrote but like we'd rather have more test coverage and that is an area where we are kind of experimenting with well what happens if we just let it loose and say okay cool build

up these giant things that would be a pain to maintain by hand no great abstractions lots of duplication like in your test so far in the app yeah yeah like we have like careful factories to set up things in a reusable way it's just like yeah okay just you just hit tab and it copies the data structure and that's for your test that's probably like fine right yep yeah and we'll see maybe we'll hit a point if you're gonna do this anywhere that's the place to do it yeah because the alternative is maybe we just wouldn't have tests exactly it's better than nothing i will take yeah i will take the tests with code that might be different than a human would write i think we also have there's a little bit of like a burden let's call it an economic externality

problem here where the the developer that's writing all this code is taking less thought about the code written than the code reviewer, the other developer, who's like, oh, I got to read all this crap now. So now you got a developer who's producing code

probably faster and more of it, but it's less well factored and doesn't follow patterns, which means during review time, it needs more attention because it's like, wait, what's that? I've never seen that before. And like, oh, that looks like

a reimplementation of a utility function I had. Or, oh, that's a new CSS pattern. Like, I guess I'm going to have to learn that. So you think about like how we're externalizing the effort from one developer to another

i gotta wonder like in the end if you net out the effort expended is this team actually better off is it betterage's law of headlines that says if you have a headline with a question in it the answer is no yeah was that a headline that you're saying no i actually don't i'm actually for me this is a genuine question without an answer that i think you as a team member are going to have to analyze and say yeah like i'm kind of on the receiving end of this crap and i'm i'm carrying a little more weight but as a team it is possible that we are like our flow efficiency is better than our my individual resource efficiency but it could it might not be it might be that it's just worse and you got one co-worker who's literally like according to this question drowning the rest

of the team yeah and they're just sitting back and sipping orange juice and and chilling and and one thing i've learned about these llms is that they're actually not good at code review they're not good at catching bugs they're not good at recommending improvements for all the same reasons that they produce this code that we just talked about these these bad patterns they also are not good at review so it's like but what they are good at cranking out a lot of code that actually for the most part works yep it's time to talk about programming is theory building again my favorite subject in the world a huge part of the work of being a software developer is developing the theory of how the program works and like your mental model separate from the code

yeah your mental model which is different from the code that you produce or the code that exists because your mental model is usually incomplete if you've come into an existing code base. Is this like another example of the map is not the territory? Yes, that is a good point. Yeah, it's related to that. There's this famous paper called Programming is Theory Building that you should go read.

But part of the work of a software development team is to develop the shared theory of how the program works so that you can effectively maintain it. And they give examples of how much easier it is to work on a program if you have this theory. they talked through some handoffs of of this team built this program it had these established patterns and practices that made certain additions easy handed it off to another team the team had the code they didn't have the theory and they were charged with making these modifications that would

have been easy for the original team because the affordances were in the code base and they had the theory of how to use those affordances and this other team just struggled mightily to deliver them i think failed i can't remember the exact outcome but took a super long time and i feel like writing the code by hand does produce a more complete theory of it than with AI. That is something I have noticed about myself. If I use AI to help me work on a feature or fix a bug or something, I feel like I still don't get quite the same deep understanding as if I had to write it all myself. Yes, that's so true. I don't know what the answer is here. It feels bad to say, well, you just won't have that or you don't need it. But AI takes that away from you to some degree

is what you're saying yeah because it it's like you get really buff legs by bicycling or you ride a motorcycle and you go faster and your legs aren't buff anymore yes but you get the job done yeah yeah but then also part of your job is like heroically lifting huge weights sometimes i don't know which you can no longer do yeah exactly yeah there's like there there will be times where you do have to have that theory and you won't if you just AI your way to a solution. And I don't have a great solution for this. Are you saying that's like a limiting, it limits your ability eventually in at least in some situations and maybe an aggregate? Yeah. If you have to create a shared abstraction for a broad problem that you have in the code base, I think if you AI your way to

individual features, that will be hard. It'll require a bunch of work because you won't have seen the same problem a bunch of different times and run into the same pain. It'll just, it'll just spit out a bunch more code that does the thing yeah exactly exactly yeah there's sort of like some cross-cutting things that will be harder and i don't yeah i don't i don't feel like i have a good solution for what to do around this long term good thing that's not what the question was yeah yeah exactly i at least have an observation about programming is theory building from this paper this is peter nauer of bacchus nauer form fame yeah yeah yeah cool news is if this came out in 1985 and that was like that was a long time ago it's like 10 years ago or something yeah yeah

multiple years ago yeah it's like multiple years ago super ahead of its time for 10 years ago yeah yeah he saw so far ahead so what do you say what do you say to this co-worker i think the point you made that struck me the most was the externalities here because it feels good to go fast i mean there's a there's always the cowboy coder type where you just get a bunch of stuff done management likes you because you ship stuff and and other people pay the costs and in a way ai can enable more people to be cowboy coders where before they would not have been productive enough to do that but there was always one on every team right it feels like yeah but yeah it feels like and i think that balance is healthy but now there's too many of them cowboy code a lot

faster a lot more and people that wouldn't do that before without ai could do it now it enables more cowboyisms so the so the ratios are all messed up is what you're saying yeah exactly yeah like the team is always a little bit grumpy there's always bugs that slip in because of someone who works like this and you clean up after them but like the rate of the bugs could go way up now yeah so yeah the the externalities if this person knows the code base deeply they care about it they it sounds like they like it they like the existing patterns yep and and it sounds like they do have a theory of the code it probably hurts them to see someone just slap a bunch of for loops in and say good news now we can do this feature yeah we could do it abstractions and like

what about all the existing code and it's it's going to be there's one little piece that sticks out a bunch from how everything else is done and i think it's worth talking about i think so too but also this might be an opportunity for you as the question asker to take a good hard look at why you do what you do because there's certainly like on the on the cowboy coder spectrum where cowboy is on one side of it the other side of that spectrum is the obsessive craftsman who can't ship anything because all they care about is the beauty of the code it's like coding is art not productive business valuable features you know yeah maybe this is a time to ask yourself where am i on that spectrum am i too far into the code as art side and i actually need to lean more

into this stuff and think about maybe the these beautiful abstractions and patterns that they served a purpose in the past and the purpose was to allow humans to work faster because these abstractions allowed you to reuse tools instead of reinventing things all the time well maybe now it's actually faster to reinvent things all the time and maybe it's actually net better i don't know it's kind of a weird thing to say i never thought i would say something like that but when i put purely my business hat on that might actually be true also remembering that all this code has a lifetime a limited lifetime like eventually this will be shut down your company will go out of business you'll be replaced with a different team of engineers who do nothing but

maintain and keep the lights on you know who knows yeah so i don't know and this is a weird thing for me to say because i really expected to come in here saying ai coding like this is so stupid. I'm actually like a huge AI fan, but I do think it's way overhyped. The productivity claims are way overhyped. And this may be actually a good example of that. Yes, one developer can crank out a lot more, but it is cowboy code. And now the rest of the team is left kind of holding the bag. I don't know, man. It's a weird world. We're definitely in a weird transition period. I really like what you said about it's possible to be overly obsessed with craft. And I think it would be useful to say to what degree is this craftsmanship serving the business

because it's very easy if you've been around here four years you've been in the code it was it four years yeah been on this team for four years turned through a bunch of teammates you probably have written a big chunk of the code you probably identify pretty closely with it you've been here the longest it probably matches your preferences because you've had the most impact on it which is like great that's how you would want it to work but it can be hard to see someone do things a different way and not react negatively to it just for the fact that it's different from how you think it should be done and that doesn't mean it's wrong or bad and it's very possible that your patterns are for you and not for the team the the patterns are supposed to

make the team effective and productive, not just match your preferences. So I think it is healthy to have people come in and question stuff and shift things around a little bit just to avoid the calcifying effect of like, well, it works exactly how one person wants it to work. And that becomes self-serving where you criticize things for not fitting how it looks when how it looks is the way you wanted it to look and the value of it looking that way is then it looks similar to the other stuff that looks how you want it to look so i guess i am just criticizing you but i i i do think there is value also in saying hey i have to review all this and i'm struggling can you please produce output that matches our patterns better and if your co-worker says sure

what patterns then great now you get to talk to them about the types of patterns you want to exist in the code base. And maybe this actually is an opportunity for you to work together as a team and find ways to make the AI work better, rather than just accepting it as a cowboy code spaghetti factory. You can sit down and be like, let's improve our tools together. It's kind of like Jameson, we've talked a lot about how code review time is not the time to debate linting rules, you know, or debate code formatting. It's like, let's move all of those problems to the computer itself and then from now forevermore all future code reviews won't you won't have to debate how many spaces you should indent your lines right it's like just we'll just

have that discussion once well the same thing may be true with this with these ai tools is maybe your team members are not actually using them effectively take advantage of the context stuff take advantage of the pre-prompts that you can set up to send to all these things that that document which patterns you want them to use not only that i think it's fair to say hey you should know these patterns it doesn't matter if you're producing it with ai or not like you you should follow the existing ones or if you think they're wrong then we should talk about it exactly but doing it the wrong way and then making me clean up after it is painful and stressful to me which it would be i would i would be stressed out by that if i felt like someone was just sprinting ahead making a

mess and i had to go fix it all right but and see that's the other thing so like there's kind of two angles to this question and this will be the last thing i say i promise i know we dear listener we've taken more of your time than you agreed to give us but here we are ai makes us talk a lot just like it produces too much code it also produces too much podcast too many opinions there is this question of are these abstractions actually a net good for your team what are your team's objectives and do they help accomplish that if not and ai can continue to serve you well and make features fast then throw them out like let's take a real pragmatic approach here this is really an opportunity for a lot of teams to have a good look at themselves and say, we've done things one way

for a long time. Is that still the right way in light of new tools available? And you know what? AI is a pretty good opportunity to have that conversation. I'm going to take my turn to say one last thing, which is I have found myself writing documentation for humans that benefits AI with more context and for AI that benefits humans. And so I think one of the problems here is just lack of shared theory and context. And the answer is you probably have to write more stuff down and talk about more stuff. And whether the human is using it or the AI,

it still needs to get out of your head. There's a lot of stuff that is probably implicit in the code base that's obvious to you as a four-year veteran of this code base that is not obvious to anybody else. And if you want it to stay consistent, then the way you do that is make it easy to perceive. And be explicit about it. you know it's not just well you know johnny told me that we're supposed to use this pattern for

concatenating strings yeah you know it's like let's write this stuff down it's almost like a you know back in the day maybe this is going way back but i remember especially in open source projects and even in a commercial setting it was actually pretty common for teams to have very opinionated style guides and i don't mean visual ui style guides i mean coding style guides and some of these teams are famous for publishing them and being like this is how we write code i think probably the first one i heard of was the linux kernel itself and boy they've been very rigorous about about maintaining that style i haven't looked at linux kernel code in a long time but at last time i remember looking at it i was like this is remarkably consistent and hard

to read consistently but remarkably consistently hard to read yeah and maybe it's time to bring that world back in fact one of my team members is exploring the new chat gpt codex or open ai codex tool that just came out and one of the things it recommends is creating these markdown files in your repo yeah one of them is called like agents.md or something it's i mean who knows what these things are going to be called long term so there's an agent.md there's an agents.md there's rules files yeah there's like 15 different standards for how you give it context exactly and and it's like surely a 16th way will unify them all exactly insert xkcd reference yeah but yeah like this is a this is objectively a good idea to have these things obviously they can be taken

too far and you can put too much effort into them but now more than ever is a good time to get explicit about how you want your code to be written all right now i'm really done all right i think we've answered it crazy crazy times i think they're exciting times i agree the most fun i have been i think the most fun i've had in software in quite a while i agree and i gotta say as a cto who i tend not to work on critical path projects on our on our code and i do like little pocs like little zero to one experiments i'm and i just have the greatest time things that used to have such a high activation energy and barrier to entry and high friction now are just like effortless to get started i love it it's so great and i just throw my spaghetti mess over to my team

and i say turn this into a product you're like but our patterns you say silence silence great what should people do if they want their own questions answered if you want your own questions answered go over to like some large language model and ask it because you're not getting anything good out of this mess but if you'd like a a less long-winded with today as being an exception a less long-winded concise and human crafted artisan answer you can go to softskills.audio and click the support no not support you can click the ask a question button where we want to say thank you

to the people who submit those questions every week. There are so many that keep coming in. It's actually amazing. I mean, here we are. We're in our 10th year and I thought for sure this thing would be done after five episodes. Here we are, still going.

Thank you so much for keeping the questions. You're what keep the show alive. Really appreciate you. Thank you so much. We will catch you next week.