Soft Skills Engineering - Episode 512: Can non-engineers really contribute code with AI and not sharing

Episode Date: May 11, 2026

In this episode, Dave and Jamison answer these questions: Should I declare my struggle with this AI world we live in here? Nah. I mean, I’d like the hype to die down, a lot, but we keep getting new tools and I get to experiment, so here we are. My real struggle, and this podcast is implicated in it, is around non-technical people contributing to production systems. Why are we so obsessed with this idea? COBOL tried it. Low-code and no-code tried it. BDD and Gherkin aspire to it. Yet time and again the field demonstrates that you need people who know their stuff. To “democratize” software engineering implies that all people have the desire and ability to become software engineers. That premise is false. You democratize access to education or financial systems, the stock market say. You don’t democratize skill. Skills are earned. We would never, I hope, democratize bridge engineering or piloting an aircraft. Software engineers are just as critical as either. When our software breaks, money goes missing, electrical grids fail, information stops flowing. What I do think is great: now more than ever, as long as tokens stay cheap, people have more ability to build useful tools for themselves. But here is how I think about it. We have done tremendous work on literacy, and most people can read, but not everyone is an author. The same applies to code. anon e mouse asks, Should I share my tools? I keep building small local software tools to better test and debug the application I’m working on. The problem is that whenever I go “above and beyond” the assigned and expected work and try and responsible check it into version control and share it with the rest of the team, it gets bogged down in code reviews because it doesn’t meet the team lead’s vision because it wasn’t part of the vision! Once I go through that process though, it’s mostly appreciated, but the team lead is under a lot of business pressure and often mentions that we need to focus. Maybe I’m not focused enough, but many of these little tools are things that making verification and delivery much smoother! Like local testing utilities to verify and sample api endpoints that otherwise could only be called after prod deployments due to a lack of test data. Our partners like when we’re able to show the output before deployment, and the rest of the team usually struggles with that. I feel a pressure to hide my tools, but then I feel sloppy for having a bunch of useful tools outside of version control. These are things like formatting output, running experiments, testing data for variations. Am I unfocused or just bad at articulating the value of these tools?

it takes more than eight bits to be a great software engineer this is episode 512 the ninth bit of the soft skills engineering podcast i'm your host jameson dance i'm your host dave smith soft skills engineering is a weekly advice show for all of the non-technical things that go into the technical field of software development, like trying to explain binary in English words. I guess that's not technical. Actually, no, no, no, that is technical. The non-technical bit is the judgment to know I should not be explaining what binary is right now. Can you believe it took us 10 years to go above 8-bits? I think we're moving faster than the computer industry did early on.

that's exactly what i was just wondering did we break out of eight bits faster than the computer industry i think they'll catch up to us though i think it's going to take us a while to get to like 64 bits of podcast episodes it might take a little while yeah i don't know how many like millions of trillions of years it will take us but it's a lot yeah but we're committed yeah we i've just like and and if the questions keep coming we have content we don't have 64 bits of questions but we have enough to keep going for a while yeah we do and they continue to grow faster than we answer them so my doctor told me that as long as the questions keep coming in i will stay alive oh good doctor or wizard i can't remember which one

is that a witch doctor a combo doctor and wizard that's right that's exactly what that is oh thank you if you have stuck with us this long and welcome if you are just joining because you figured 512 that's a good number to start listening yeah that's where i start i wait i usually wait till podcasts get to the ninth bit yeah filters out the wheat from the chat that eight bit garbage dave do you want to thank our patrons yes i do uh big shout out to those that are contributing at a level where we say their entire patreon name their profile name every week i'm already laughing and i haven't even started reading them actually i did read the first two

words of the first one oh my gosh oh every week people find new ways to make me just absolutely laugh that's why the doctor said it will make me live forever is because i keep reading these patreon names and you know what do they say about laughter and medicine or something an apple a day is the best medicine with laughter something like that yeah i think that's how it goes okay don't laugh while you eat the apples and then it will be good medicine yes okay the big thanks to a dinosaur full of energy tried to use a computer and telephone to understand gravity while an orchestra played softly during okay oh gosh another one of these i want four t2 okay oh i wish you knew how this stuff was spelled ai made me a top code producer company went

bankrupt error your will angel name variant must contain at least one uppercase letter one number and one special character no one knows my real name is seth angel angel i thought this was a funny name but you didn't laugh now i feel self-conscious will angel if you can hear me please save us i want to put no carrier in my tombstone on my tombstone but if i live long enough no one will get the joke my actual name on linkedin is yammy debugging in the dark canny the mobile development ordinary first of his name name his up first ordinary development mobile the canny dark the in debugging yanny oh you did not spell that right someone put in parentheses sp question mark nope he didn't get it jacob chandling

or as my mother used to say the missing semicolon will angel please report to hr over your recent transformation into crab help nick molyneux embedded engineers treat assembly the same way typescript engineers treat javascript javier gonzalez chewy meow mix angel drone deploy salted fries oh that's a throwback what happened to salted french unsalted french fries are morally objectionable i think they compromised their morals yeah they were gotten to by big french or big salt big salt big salt got to them that's who it was wait no i guess it'd be big unsalt they maybe they were big salt they got brought down low

by some plucky rebels oh that's what it is yes it's the big sodium the big low sodium yep okay where do i leave off oh my goodness ted timbrel chewy ted timbrel chewy ted timbrel chewy ted timbrel chewy ted timbrel chewy ted timbrel a single open paren dan from drone deploy never is not just a creator on marcel lingo emoji i like chicken i like liver meow mix meow mix please deliver swiss python summit on the 22nd the 23rd of october 2026 kyle boss can't see duds slowing down jenny kim the sarcastic parrot will angel move to oh no it's back the longest city name on earth okay here we go i was able to say this at one point lanfair will gwin gillo goguric

we're drobe will and silly go go go go go go go all right irish and jonathan kings and i beautiful functional user documentation if i were angel i wouldn't crab now on your phone at vote dot william angel dot net dave's serial killer name dave smiles adding inside jokes to your agents.md in your personal repo is still technically a team building exercise brayden jones john grant britney ellick will will angel go to slash new cough may 27th or 28th oh my gosh will he will will angel and finally close parentheses followed by a single literal closing paren oh my goodness you did it again team wow it's amazing i normally have to pay for this kind of entertainment and you paid us to entertain us it doesn't work

economically but it works in my heart yeah this is the power of friendship which transcends economics it's time for me to bring back my old favorite stupid name joke which is imagine there was a guy named Big Mac and his nickname was Big Mac and then he would be named Big Big Mac Mac and I see Will Will Angel and I think what if Will Angel's nickname was Will Angel and then it'd be Will Will Angel Angel oh it's pretty good Big Big Mac Mac I don't quite get it like Big and then quotes Big Mac and then his last name's Mac oh kind of like how you put your nickname between your first name and your last name yeah like David Dave Smith Big Dave or Dave okay i got you smith or like you know i got you i got you dave the destroyer smith wait am i

supposed to leak your last name oh whoops no i say it every time oh yeah that's right and so do you you got me for a moment i was like wait no i was like oh what have you done we've my pseudonym we've kept our identity secret for 10 years my last name is smith it took nine bits my unique identifier okay we better get to a question yeah we should it we've spent all the bits now let's do the questions yeah i will read it i think this is from an anonymous listener who says should i declare my struggle with this ai world we live in here nah i mean i'd like the hype to die down a

lot but we keep getting new tools and i get to experiment so here we are my real struggle in this podcast is implicated in it, is around non-technical people contributing to production systems. Why are we so obsessed with this idea? COBOL tried it. Low-code and no-code tried it. BDD and Gherkin aspire to it. Yet time and time again, the field demonstrates that you need people who know their stuff. To democratize software engineering implies that all people have the desire and ability to become software engineers. That premise is false. You democratize access to education or financial systems. The stock markets say you don't democratize skill. Skill is earned. We would never, I hope, democratize bridge engineering or piloting in aircraft.

Software engineers are just as critical as either. When our software breaks, money goes missing, electrical grids fail, information stops flowing. What I do think is great, now more than ever, as long as tokens stay cheap, people have more ability to build useful tools for themselves. But here is how I think about it. We have done tremendous work on literacy, and most people can read, but not everyone is an author. The same applies to code. you know i picked this question and it wasn't until you just finished reading it that i realized there's no question in this yeah the question is how dare you

whoops i guess they say why are we so obsessed with this idea yeah of democratizing software engineering yeah look i actually do believe everyone can be a pilot so i don't know if your premise is all that good just get in the cockpit how hard could it be if you're not like a commercial airliner pilot you do crash a kind of a lot yeah like the people who are pilots that aren't uh flying the big jets seem to fall out of the sky fairly often yeah it's like way worse than driving yeah this is like the one reason i don't have a private pilot's license yeah that and we just need a few more patreon supporters there are two ways dave wants to start at the very expensive private jet level yeah i want to skip all the boring stuff yeah none of this boring

little prop plane thing yeah let's talk about it one of the premises of the question is we are democratizing software engineering and i don't think we are i don't think what i see when people who aren't programmers contribute to prod code base i would not call software engineering i would call it changing code with robots okay all right but up until now we have not made it so that this can just happen i mean even for engineers like you don't just type most people i think who are using robots to write code in work contexts don't just yolo it to prod like there's some human review and oversight and work and planning and it's not just uh you dump your thoughts into an lom and then it it goes to prod that way and all that stuff is software engineering is wrapped up

in all those bits for now yeah until we fully democratize until we democratize the democratization the biggest bottleneck we have around technical output at work right now is verification and quality because that stuff is hard to do with robots we've made some attempts at fancier lint rules we've talked about this a little bit like making the system more self-driving and it's helped but it hasn't solved it yet and what is my point of this ramble the point of the ramble is i don't expect that non-engineers contributing to code will produce the same quality of output as engineers and i don't expect that it will make engineers jobs easier i think it'll make it harder because now they have to like review and babysit code produced by non-engineers in other words like

the filter that used to prevent bad code from getting here actually prevented all code from getting into in front of you yeah and now now it doesn't prevent any code because people tell robots to do the code part yeah yeah but the hypothesis is it's still worth it for the business and i guess we'll see if this pays off or not long term but it's not everyone can do a software engineering things it's everyone can produce code somehow and then you still have to get it to prod and getting it to prod is is the tricky bit getting it verified and maintainable or deciding this is not a thing that is like we this part can be crap yeah there's still some some judgment there yeah there's a whole world of of like stuff that allow that tolerates crap code right yeah and

that world prior to ai generated ai coding tools that world was zero percent served you know like there was just no one who could actually produce anything useful for themselves to use like on their desktop and now you can but that's not really what the question asker is asking about right yeah i think the question asker is saying we should stop expecting non-software engineers to do software engineering just because they have lms they can help them write code and i guess i don't think that they are also sometimes software engineers don't do software engineering like i could write bad code way before lms existed and not understand what it was doing and the implications and and even when i thought it was good code it was sometimes bad it was kind of

weird like pilots when they crash the plane like none of them walk away well sometimes they don't walk away at all but when they do walk away none of them go man that was some great flying yeah yeah and only like years later they're like maybe that wasn't good flying when they review their own black box that's how i am i'm like i wrote code two years ago i look at it today and i'm like this is horrible yeah i can just see the last the last blog post i read like spewing out of my fingers exactly getting really excited about this random pattern that turns out to not fit you're like i am nothing but a recency bias machine yeah but i'm much slower than the ai machines yeah i guess i'm i'm i think i agree with you in some ways that yeah i don't think we're trying to

say software engineering is democratized but there are people pushing for that still and and i don't think the role of expert humans will go away anytime soon in this field yeah i mean it clearly can't go away in some fields like the pilot thing i mean well okay let's just be super clear if the question is about democratization so i'm gonna i'm gonna take a slight detour on that question but computers can fly airplanes better than humans already today yeah and i don't actually know why we have humans in the cockpits of of airplanes anymore other than as like a backup for those super rare cases where the airplane can't get it right and i don't know maybe that's maybe that's the future of software you know the difference between pilots or airplanes

and software at least one of many is the ratios are all weird you know like a a pilot like a commercial aircraft needs two pilots up in the to oversee that thing and uh you kind of have this ratio where it's like you got a few hundred people on the plane and two pilots and that ratio is never really going to go up like you two pilots can never fly a plane for 10 million people you know but on the software side like we create a you create a web application and you could easily have one engineer create a web application that gets used by millions and so you know what what keeps those ratios where they are like in the pilot world just doesn't really apply to the software world yeah why do we have humans is it is it because like autopilot is

good for the normal stuff and better than humans at the boring normal stuff and then sometimes you have to like land in the Hudson river and get a movie made about you. And autopilot can't do that bit. The autopilot would be like, ah, I'm going to go crash this plane into an empty building to make sure that we minimize human death. Yeah. Yeah. I don't, I honestly don't know, but I do know that even, um, private pilots have very good, very good autopilot tools. And I've sat next to them in a cockpit before and they've talked me through it and it's like really smooth and really great. And he was like, here, I'll go off autopilot. And I, and I'm like, wow, this is a much worse ride when you when your hands are on the yoke you are so much worse like it's

true i mean he's kind of up and down and and uh kind of side to side and constantly correcting and the computer was just making micro corrections a lot both faster and smaller magnitude it's just a better experience overall but i guarantee you the moment he hit some crazy turbulence the pilot would be like we're turning this autopilot off i got this and probably would do a better job but i don't really know anyway i think the point still stands of the question asker we do not ever really intend to democratize access to the cockpit you know we don't want random people walking in off the street being like well i'll pilot this plane i guess you know full of 300 passengers yeah and you're right like we want an expert up there to oversee this thing or else you're gonna freaking

die you know bridge building you mentioned like civil engineering and bridge building i'm like i don't know like there's not as much demand to democratize bridge building because we just don't build that many bridges as a ratio of like humans to bridges it's like the humans building bridges it's just not that many you know there's not demand like i don't need a bridge tomorrow but i do need like 50 apps to to live my life now they're also very expensive like say we did say you didn't need a license to build a bridge i would then need 700 million dollars somehow concrete and labor great it's the access is democratized software software is just so weird in so many ways and every time we make comparisons like this it just falls apart because the ratios

don't work the cost doesn't work the barriers to entry don't work like it just doesn't transfer and so i don't know i mean but i i will say like for sure one of the things that this question asker said that is like a thousand percent true is that to democratize software engineering applies that all people have the desire to build software and most people just don't want to make the products that they use they don't want to design them they don't want to manufacture them and i'll give you like the best example of this i can give is 3d printing like for years everyone said oh you're never gonna have to go to the store because your 3d printer will make the stuff you need and i'm like that is such a pain in the butt you know like nobody like i love it for hobbyist stuff

but nobody has a 3d printer in their house where they're like oh i need a new i need new silverware you know i'll just 3d print that instead of going to like i need no here's a better one i need plastic wear i'm holding a picnic and i want to have disposable plastic wear like i'll just 3d print the forks and knives no i'm going to go to the store and i'm going to spend three dollars on plastic and i'm going to throw it in the trash when i'm done which is horrible too but it's just different people don't want to make they don't want to design and they don't want to manufacture products for the most part like i would say not at least 90 of the population does not want to do that if you are an engineer working at a place at a company where non-engineers are

contributing to the code base first just your ai use and your fellow software engineers ai use has created more code for you to review already even without non-engineers writing code i sympathize with the changing balance of time spent in review and verification and i can see it being frustrating that a lot less of your time is going to creating stuff yourself like you very rarely just sit down for six hours and think deeply through a problem and type the code out to do it anymore and if you then add okay non-engineers are now contributing code also you have even more code to review that's probably done in funkier ways and then you also add this new problem of okay if we want to make it easy for non-engineers to produce air quotes good code then we have a meta problem of building

the system that encourages it maybe i don't want to work on that i just want to like build the app so i can see why this is frustrating yeah but i think the end goal is what is the end goal i don't know i mean the business wants more stuff done so they can make more money i guess that's that's part of why we're doing it where i work is we think it will make customers lives better and we there are trade-offs with that it's not free yeah it is it's the case now jameson you you and i have both really tried to lean into this concept at our companies to get more people to contribute code to the code base in a sense so i haven't in my company i haven't fully democratized it but i don't know what you would call it if there's a small circle of people who

can do something and i want to expand that circle to like their nearest neighbors that's kind of what i did like i want to expand the circle to user experience designer product manager roles you moved from a dictatorship to an oligarchy yeah i'm pretty sure yeah we're the we're the rich plutocrats yeah that's right everything instead of just the one person yeah i didn't want to be an emperor i wanted to be a a plutocrat among group yeah among friends yeah perfect plutocrat oligarch yeah that's exactly what i wanted to do and and i'll tell you i i actually would like to share the results. The results have been that, and I'm just talking specifically in contributing code to our product, our customer facing production product. The results have been

not great. And mostly it's because of problems getting the code deployed. So for example, this week, I had a product manager who just wanted to change a link target. There's literally just a basic hyperlink on a page in our app, linking out to some help documentation, wanted to change the url that it was pointing out and because of some quirks in our deployment process which admittedly could be fixed could be improved but because of some quirks in our deployment process this product manager did successfully make the link change but also deleted a feature from our our web app that had previously existed that had just launched and it was like right on the heels so those of you who are savvy can piece together exactly what our deployment pipeline looks like

now based on what you just heard me say but um don't worry there are pros and cons to it and And actually, I love it, even though we have this risk. But he did. He deleted a feature. And we had just announced the feature was launched, and it was live. And then people were like, wait, I don't see it. And we're like, oh, crap, what happened? So if something that basic, like changing a link target, can result in something that catastrophic,

I don't think we're anywhere near democratizing software engineering for actual product used by more than just the people who developed it. I was just going to say skill issue. Sounds like you guys are bad. No. That's a negative result. were there other changes that were made that were positive and and this just like way overshadowed those or was it pretty much the only outcome was it deleted a feature and we didn't get anything useful out of it i mean we eventually we were able to restore the feature it wasn't like it

wasn't like he like completely just wrecked everything it was a quick fix and it's things we've had happen before so it wasn't like a nightmare scenario but still it was like it should be very very easy to change link text or link a link url right and it's just it's still not i'm sure in some scenarios and some code bases it is but not in ours which makes our code sound horrible that's not actually the case it was just uh now i feel like i have to defend it oh man what have i done have we broke stuff in prod i mean we shipped some things my company is a bit smaller than dave's company i think the circle of people who've actually made changes is still fairly small it's all people technical or technical adjacent and in customer support or design or

whatever and we've shipped a bunch of features things that never would have been prioritized or done without democratizing access some of them customers really love and use oh that's cool like it like i said it hasn't been free presumably we would have had more just kind of core raw engineering work done on the the main track of stuff we picked to do but it feels like a good trade-off for us oh so in other words you you didn't actually democratize every part of the process but like the code writing part people contributed code and then engineers had to review it yeah people submit pull requests and then the engineering team still reviews and merges or gives feedback or takes it over and got it so so it's easier to like prototype new stuff yeah the

democratization has happened at the prototype like proof of concept layer yeah yeah and there's some things that are easy that just yep obvious bug fix small scope yeah yeah thumbs up and some things that gets submitted and we say you have no idea the the fiery flood of lava that this would unleash and of course you we don't expect you to but here's why we cannot do this and some in between and there's a surprising amount of that in software i think a lot of people just don't appreciate the implications of seemingly small changes yeah you know like oh you make that change well that's gonna that actually affects seven other workflows in our product that you did not think about and now they're all broken yeah we some of the stuff that we have shipped

has had some bugs that required some follow-up but none of it has just been broken and i think knock on wood it hasn't broken other stuff too badly that i'm aware of up until now so i think it's been broadly positive it it just is a trade-off of the engineering time a team spends more time than they used to reviewing these code contributions from other people yeah and that's all and what's crazy is our engineers are already spending way more time in code review than they have in the past as a ratio of their overall time span and so when you now expand the circle of plutarchs to contribute more code there's even that that amplifies that problem yep i say problem like only because most people don't like to spend all their time reviewing other people's code

it's hard i mean it's exhausting in a way that creating your own stuff is not yeah i don't know have we answered the question i feel like we keep forgetting what the question even is but That's because there's no question. Yeah. I'm interested to see where it goes. And like all things, they're probably a spectrum. There are places that never, ever do pair programming and places that always do pair programming.

And I think this is another one of those axes on which you can place your software practices. Only engineers contribute to the code or literally anybody can or anything in between. I'll share my final thought on this, which is to answer a question that is implied in here, which is that, well, really stated out loud, why are we so obsessed with this idea of allowing non-engineers to contribute code to these projects and democratizing the process? And I will say this, I believe the population is starting to become unimpressed with AI output. You know, we're on that hedonic treadmill. And so when someone shows up at my door or in my email inbox or my Slack DMs with like a 17-page PDF file containing what looks like very dense, valuable

information three years ago i would have been like wow incredible work i'm sure you poured over every word in here and you carefully wrote this yeah this is so long you must have thought so much about this and now when someone does that i'm just like next like i don't even want to read it i'm like i bet you haven't even read this yeah yeah there were two options either you were schizophrenic and this is a time cube thing or you thought very deeply about it and now there's a third which is ai you do not value my time yeah you ai slopped me yeah yeah and and people will just pass that to me and they they i gotta say like the faces they wear when they put these documents in front of me are like they're like expecting me to be like wow great work but i'm

like i know what you did to create this i know yeah you know like this is not high quality work we are learning what this says together yeah right now exactly exactly so like do you expect me to be impressed like i'm just not and and it's not because you know i don't know so i i don't personally i don't do that to people but the point i'm trying to make here is that i think collectively we are approaching that level of i'm unimpressed by your high quantity of stuff you produced whether it's a giant pr whether it's a really cool picture or whether it's a long pdf specification or something we're just like i don't care anymore like it's it's gone from wow to oh no like i have to read this thing so i think with that we're also going to see this

this frenzy around democratizing software engineering also subside yeah you could call it gatekeeping but also filtering a gatekeeper is also a filter there's some vouching for quality and yeah interesting times i'm going to tell one story real quick about this and i promise i'll stop talking about this topic but it is kind of interesting and timely i'm going to go out on a limb here and i'm going to implicate let's just say someone very influential in my business not my boss had a very important question about our business which is is our business protected from an ai just cloning our software and then we go bankrupt and this is the question that i think many businesses are asking themselves is what's stopping our customers from building what we

already have themselves and then canceling their subscription with us yeah we're a b2b sass company this is a question we're all asking ourselves and one of these people these very influential important people in my circle of i'll say plutarchs or oligarchs in the sense yeah business influential but not writing code they were like well i'm just gonna tell ai to create a clone of your company of your product and so they did and it put something on a browser screen and it had like buttons and numbers and dials and gauges and reports and stuff on it like you know it looks legit and he shows it to me like look what do you think of this and i'm like yeah how do i freaking respond to this like that is almost less than nothing to me like it means

nothing nothing on the page means anything and you don't know what it means either so it's like did you successfully clone my company no you did not like you created a facade of something that looks sort of like our company plausibly almost like a a forgery of a company but when you when you peel back even one layer what you've created is like a web page with with words yeah you know like you did not create an application you did not create a platform you did not create infrastructure you did not create 10 years of accumulated bug fixes that we've learned through very hard experience interacting with actual real world uh data you know an ai that an ai just doesn't know about so like that's just not that's nothing it means nothing and i think i hope that

more people are having that experience where they produce a lot of stuff a lot of content that actually is nothing and they go oh i guess we don't have to democratize this like yeah or there's more to it than just the raw production yeah exactly okay all right all right so i i'm sorry i had to rant on that but i'm done now i promise i'm gonna think about that story for a while that's very funny to me yeah because that is a question everyone's asking like can can someone just yellow clone it and it sounds like this person said look i did i did it and i'm like you think you did it and i don't want to be the one to tell you you didn't yeah that's like because you're very influential you you produce this

impressive you know that marble statue of david well i just took a picture of it so what is that even what is your stupid statue even worth look what's on my phone it's a pit it's um it's a it's michelangelo's david i have it yeah i have it you've been commoditized we democratized sculpting yeah that's a really good metaphor okay all right all right we're getting long in the long here we're about to wear out our welcome on your in your earphones so let's uh yeah do you want to read our next question yes it comes from a listener named anon e mouse asks should i share my tools i keep building small local software tools to better test and debug the application i'm working on the problem is that whenever i go above and

beyond the assigned and expected work and try and responsibly check it in to version control and share it with the rest of the team it gets bogged down in code reviews because it doesn't meet the team leads vision because it wasn't part of the vision it doesn't mean your vision wasn't part of the vision i didn't expect you to build this so it's not part of the vision okay my vision is more you do what i tell you yeah and this is not part of that oh okay continuing once i go through that process though it's mostly appreciated but the team lead is under a lot of business pressure and often mentions that we need to focus. Yes. Maybe I'm not focused enough, but many of these little tools are things that make

verification and delivery much smoother, like local testing utilities to verify and sample API endpoints that otherwise could only be called after prod deployments due to a lack of test data. Our partners like when we're able to show the output before deployment, and the rest of the team usually struggles with that. I feel a pressure to hide my tools, but then I feel sloppy for having a bunch of useful tools outside of version control. These are things like formatting output, running experiments, testing data for variations. Am I unfocused or just bad at articulating the value of these tools? Great question. Very timely. I had this exact experience with one of my favorite engineers I've ever worked with. It was, I don't know, a year or two ago. And they built some local

tool. The code base had a lot of strong patterns for kind of CLI utility things. And they were still fairly new i think to the company and had a task to do something email related and built some little scripts to do some email verification stuff and a completely different architecture from our existing kind of cli tool stuff and i did this i said no it must use the same patterns and we have ways of doing this already the patterns it was following to be clear all of these were not like prod level things these are all local dev tool things but we just had it had had a way to do it didn't work the same way i said no change it um and then i can't remember if they ever did or not but i felt bad afterwards because i realized that it probably doesn't matter like

the architectural purity of this script you run to validate emails that get generated is not important and this is like throwaway code that if there's a bug in it we will just delete all of the code it's not load-bearing at all so i ended up flip-flopping and just said yolo merge it this is this is great and then a few other things got merged in that were similar in that they were kind of local tools workflow specific didn't rigorously follow our existing patterns and i decided this was fine because if it made life easier for even a couple engineers that was worth the inventory cost of just having this code around in our repo because mostly you didn't look at it yeah like it doesn't get in your way of your day-to-day work yeah yeah it's not like it's not

in the core data plane i guess of application use the metaphorical data plane yeah which you might actually be working on a real data plane but this is a metaphor and not an airplane that's different user traffic is not flowing through anything affected by this code well to me the biggest risk here is that you just have a bunch of accumulated stuff that no one ends up using and it's just yeah it's not like in the way per se but it's like how do we do things around here and i can't tell it's like 100 script files in here yeah so i think you do stuff to curate it at some point and there's also a balance here between imposing your workflow on other people like you really like this pattern of writing a bunch of little tools and using them to verify

your work and i think that's very cool and it makes me feel like i should do more of it yeah but not everybody does that and is the repo the place to put just stuff for you i think that's kind of part of the pushback as well right and i'll tell you the the level of effort it takes to create a tool that works not just for you but for everyone on your team it's got to be like 10x you know i can whip out a little tool that i use no problem but yeah a get getting it all documented getting it to actually work on everyone's machines and then getting it socialized so people even know it exists and when to use it and getting them to adopt their workflows or adapt their workflows to it gotta have help text and yeah

like different failure modes of oh you you start up the app and then you initialize the database so i just i just never do that right the tool doesn't support that now i gotta change it oh yeah it's just so there is lost effort there and i think that's like the one place where a tech lead would be wise to push back and say look i have no problem with you creating tools for yourself because that's fine and it's low cost but if if you're if you want to now distribute them to the rest of the team now i know that it's going to take you a lot more time and it's going to take the team a bunch of time and it might not be good you know like i don't know they might not love it and they might not use it so they might not be like the roi on you investing all this time might

be low and as an example of that actually not an example of that but i have a team member who's been working on a bunch of ai tools and um it's taken months of work even with ai to create these tools because a the landscape keeps shifting out from under him but b it's like there's so much to integrate with and so many ways to learn how to do this or like so many different ways to do things that you know creating a general purpose tooling system like i tried installing the first few versions and it just failed you know and now now he's dealing with bug reports you know from me yeah to fix this tool this so-called like quick tool but he's been doing like a lot of nights and weekends and stuff on it because he's he's just like super obsessed with it and is really

interested in it and i'm like great that's fine and it is really cool what it does but i i think you do have to be a little bit more careful than i think some would be intuitively about this because it does have real cost hmm yeah i don't have a better answer than it depends because i've i've been on all sides of this when i first joined my current job there was there was a ton of tooling most of which nobody used and i just went through and deleted all the stuff nobody used but also i've added a bunch of my own tooling and some of it gets used by other people some of it doesn't. And so we kind of just have different tools that some subset are unused than the earlier subset of tools that were unused we had before I joined. I think there is actually a market here

for developer tool management, where developers can quickly create and deploy tools to their team members. And it also keeps track of things like how much usage is this thing even getting? And like, should it be gone? Should this tool be deleted from our repository? That could be kind of cool yeah if bigger orgs will have kind of internal productivity teams and they probably do some kind of measuring around that tell your tech lead hang on no i i think this is important and i actually just need to pivot to building a bunch of analytics for these tools so i can demonstrate their impact yes i can tell the question behind your question is i need more metrics on these tools so i'm going to build that for you yeah give me a couple weeks we'll be able

to do a study maybe do some ab testing and within a couple months we should have enough data to know are these tools used in order to help hit the release that's next week it's like we're a four person team dude and almost every company i've been at i will usually create a git repository that's just my username plus like tools or plus you know utils or something and that's where i just put all my stuff where i develop little things like this and of course i've always done this but i think nowadays you can do it a lot more and developers want to do a lot more and so you know one of the main questions here from the question asker from a non-e mouse is i feel bad having all these tools not in version control and i'm like yeah that you got to get that stuff

into version control because you're going to lose it one day when you move to a new computer or your computer is stolen or upgraded and you realize oh crap i just lost all my favorite tooling so yeah i would put them in version control but i just put them in my own little git repo and then you know let people organically find out about what you're doing and uh if there's demand then go ahead and like do the extra work to get it out there and i think that that does a nice job of marrying the the two problems in the middle that's a great idea i like that idea a lot then if you you you kind of keep continue to show it off and say i think this is cool you should try it etc if people don't pick it up fine their mental space is not cluttered yeah source code

that they have to look at does not have extra stuff that they could get lost in exactly but yeah i like that all right well you have actually solved i said it depends and you had a solution it does not depend um this is the answer just kidding yeah i will say one last thing on this well maybe one thing in a sub thing you were joking about building like a big analytic system for all the tools but it might actually be cool to build some kind of for your team some kind of tool framework to let people plug tools in and register them so that they become discoverable by people and it might even be really cool to register some of these with your ai so the ai I can recommend using them or just know about them and use them on your behalf when it makes

sense. You know, like, Hey, AI, here's our like default prompt preamble for everything. And here's a set of tools you can use to do things like check my commit afterwards against these common database problems or something like that. You know, like you could, you could accumulate those. Then the developers, there's no developer cognitive load because AI is the only thing that consumes it. Number two. And this is something that I've tried to do in the past is try to hook tools into places where the team already is so that they just naturally happen. And this is more about like how to get your stuff adopted

without making the tech lead think that you're burning tons of time on it. Like for example, years ago, 10 years ago plus, you know, we had a lot of Git hooks that were part of our like normal day-to-day work and developers could add Git hooks. And so it's like, if you wanted something, some kind of check to be run,

anytime a developer did something, you could just plug it in there. so you didn't have to like go and get everyone to adopt it you didn't have to go like write a bunch of help docs and go on like a marketing campaign in your team to try to get everyone to to believe in you you know and raise raise like social capital for it yeah basically like if you can find there were ways to do that 10 years ago and there's ways to do it today that i think can get your stuff adopted without causing a bunch of extra pain and effort that your tech lead perceives i love it all right have we answered the question i hope so because we are out of time yep we spent

our token budget if you want to renew your token budget our token budget i don't know what the metaphor is here what could people do if they want their own questions yeah go to soft skills audio and click the ask a question button where you can fill out our form you can type in as many tokens as you want there i don't think google charges us per the token thankfully although one day i'm sure they will yep but thank you so much to everyone who writes in with your questions we really appreciate them keep them coming thank you so much for listening we will catch you next week