Soft Skills Engineering - Episode 458: Infinite tech debt hack and figuring out what is going on

Episode Date: April 28, 2025

In this episode, Dave and Jamison answer these questions: Nearly every time certain developers on the team want to address technical debt, they end up just adding more technical debt. Of course, after one round of addressing technical debt, the developers in question believe that yet another round of redesigning and refactoring is in order. This stresses me out for many reasons, as you can imagine, and has led to my productivity dropping to an abysmal rate. I spend a large chunk my time resolving merge conflicts and re-orienting myself in an ever-changing codebase. Do you have any suggestions for me? Hi! I’m a software engineer at a big tech company, and I’m starting to feel siloed in my IC role. I’m getting my work done, but I’m often lost when it comes to the bigger picture. I can’t keep up with what our internal customer teams are doing, what they need, or even what my own team’s priorities are. I’m feeling siloed, and it’s starting to worry me. I know that just being a good IC isn’t enough to advance my career here. To get promoted, I need to understand the impact of my work, be aligned with the team and customer goals, and show that I can contribute to the overall success of the company. But how can I do it? How do I stay informed about customer needs and team priorities and position myself for career growth without getting completely overwhelmed? Thank you for your precious advice!

it takes more than wondering about disney plus's database schema while watching frozen to be a great engineer this is episode 458 of the soft skills engineering podcast where i am your host jameson dance i'm your host dave smith soft skills engineering is a weekly advice show about all the non-technical things that go into the technical field of software development like trying to type in a sequel injection in on your tv remote right in the search bar of the disney plus search bar vebo or whatever yeah whatever app you're using close quote dash dash turn off ads semicolon type that into your smart tv turns out there's a stored procedure in mysql yeah well do you want to thank our patrons i do here we go this is the list this

is the list of the people who type things into their patreon profile name field that makes me laugh every single week here we go they are croissant connoisseur i only learned to code so i could look cool in public but now i get excited about cleaning up legacy code please send help noah labhart my dad jokes cron job is almost done i just need to completely rewrite it in this hot new programming language a really expensive tube nice alexander kuznetsov nick molyneux attribute error none type object has no attribute to string javier gonzalez chewy ted timbrel i like a dude cha-cha whoosh with a crying face emoji become a senior engineer.com is a newsletter you should read doing my part to make dave's heart swell but he should probably get that

checked yes dan from drone deploy chase w norton never is not just a crater on mars flamingo emoji i like chicken i like liver miamix miamix please deliver trash panda get status kyle boss can't cdodds that guy over there nevar is not just a planet in the vulcan system jenny kim the stochastic parrot helicone.ai best observability tool for ai red panda is best panda how much wood could a much woe wood could a woodchuck could jonathan kings and i beautiful functional user documentation i'm your host stephen colbert williamangel.net i'm now rehiring personal data salespeople because the ai productivity bump was a fad entry level six years xp ragnar brayden canes john grant britney ellick come to the slash new conference in newcastle australia may 28th and 29th mate

just kidding the mate part i added that if it looks like a duck swims like a duck and quacks like a duck then it's probably a soft skills engineering listener and lastly ouch my 401k there you have it you had a good run 401k nice knowing you yep wish i could have spent you it sure was nice sending chunks of money into this thing and watching it go up and knowing someday it'll be useful and then not having it be useful just wait for your 59th and a half birthday yeah i think you should use the time value of money to argue why you should just not save for retirement and spend spend spend because it'll make you so much happier now to have that cool impractical motorcycle than if you're 60 and you have an order of magnitude more dollars yeah what

What you need is a TV that's just a few inches bigger in the diagonal. That will do it. That will finally make you happy. Yep. All right. I'm going to read our first question from a listener named Nico, who says, Nearly every time certain developers on the team want to address technical debt, they just end up adding more technical debt.

Of course, after one round of addressing technical debt, the developers in question believe in yet another round of redesigning and refactoring. This stresses me out for many reasons, as you can imagine, and has led to my productivity dropping to an abysmal rate. i spend a large chunk of my time resolving merge conflicts and reorienting myself in an ever-changing code base do you have any suggestions for me oh the tech debt spawn yeah this is a whole new layer on the problem of convincing the business that it's worth investing in technical debt is you have to convince them that you are correct in your assessment that this thing is

actually bad and causing you problems and is worth the time invested to make it better and then you have to hope that the thing you do to change it actually makes it better. It's like if you paid off your credit card and it turns out that you paid them negative dollars somehow, but you didn't get the money, but now your credit card bill is larger. Like, wait, you can mess up paying this debt off. You can pay it off in a way that makes it larger. That's right. Technical debt. And you still don't have the money. The only kind of debt you can pay down and it goes up. Yeah. Dave Ramsey doesn't know what to do about that one yeah exactly when you pay technical debt it's more like dungeons and dragons when you roll a die and it's like every time you pay it you're actually

rolling and there's really a chance you might just get hurt yeah there's also this effect where you don't know if paying down the technical debt is actually paying it down for like six months yeah when you're less familiar with the code and more developers have had a chance to read it And then you go, okay, this was good or bad. You have the sword of technical debt slaying, which is a D20 minus 15. That's how much technical debt you remove. D20 minus 15. Is that like a three out of four chance that you're going negative?

You're going to have even more technical debt? Yep. But maybe. Maybe one in four chance you get better. Yeah. And then I guess, I guess you got to add in your like experience modifier to the, okay. This metaphor has been stretched. It's been stretched to the D20.

I got to say when I, when I am contemplating approving technical debt projects, the ones that are really appealing to me are when a developer says we can delete this service or we can delete a database or we can delete thousands of lines of code because we found a different way to do it. then i'm like okay that's the kind of debt that usually when you pay it it goes down yeah but when they're like we just want to rearrange this code but not really change it not change the way that it's that it works from as viewed from the outside i'm like i don't know we feel like we messed up with our last abstraction because there are all these cases that don't fit into it but

good news we have a new grand unified abstraction that will bring in these these new use cases and then cover every use case and never need changing and we're going to keep the old abstraction just but you know for backward compatibility we're going to layer yeah we will layer on a new abstraction that will cover the old one and these new things while still exposing the old abstraction because there's people that are directly using it we can't can't just delete it and they won't migrate to the new one yet yeah large chunks of my time resolving merge conflicts that one yep that's a very concrete thing you can bring up and say hey this is costing me time i know you have ideas of the benefit of this but this is a very explicit visible cost of the time that i

lose to merge conflict resolution for things that do not make the business any more money and i think that's a legitimate concern and a thing you should if you're if you're proposing technical debt changes and have a bunch of ideas on how to fix it like not messing up people who are doing work is uh certainly one of the things you should think about for sure and when when you say merge conflicts i just know this these are giant refactor projects and when they say tech debt what they really mean is refactor yeah yeah i think it's worth bringing up to to the team and saying hey how do we not break work in progress when we're doing this yeah maybe you have to wait maybe you have to have a synchronization point maybe like don't tackle it if you know somebody's

working on a thing maybe you have to go back to subversion and you just have the lock on those files and so they cannot do any refactoring microsoft visual source safe yeah this this file is checked out by me yep and git was a mistake it's too easy it's too easy to let people change things yeah i'm reading this from the perspective of someone who's not a leader on this team just an influencer or a peer when you said influencer i imagine oh doing the flossing dance from fortnight on your internal tiktok that of course your company had to recreate which this team built we need ways for employees to engage with each other around our company values and brand it's like somebody doing the gritty at stand-up while everyone else groans

we'll have to send self selfie camera like little tripod mounts for your phones yeah uh to every employee so they can record these things in full frame yeah what up gang here at the daily stand-up oh boy i don't even know what i was going to say but if something about trying to influence this team you find yourself in a frustrating position because you can clearly see this problem but you're not in the approval process for saying yes we're going to work on this or no and i gotta tell you when i look at this team i think okay where is the product manager who are notorious for denying tech debt jobs like this. I don't know. Do you have a product manager on this team? Yeah. Usually you are trying to battle against the structural

impediments to getting these things approved. Maybe the manager is not technical or the person with the approval is not technical or convinced by the smooth words. But it sounds like the people working on it are really pumped and and and feel like it's going great you know yeah it worked so well last time let's do it again yeah and and it sounds like they enjoy doing this thing so on your team with the developers you are pushing against some tricky forces but the default answer for from a business for can we do this thing that doesn't make us any money is no right so are you suggesting you you need to like summon the eye of sauron of like hey we're doing a bunch of stuff that doesn't make us money that you know how developers always say words you don't understand

that sound really important it's it's it's got this tangible negative thing and not making us money yeah this uh monoid endofunctor rewrite is actually not good yeah you mentioned jameson that you've got these high energy developers who are really interested in doing this and you could help them channel that energy to something productive i mean maybe these are the kind of people that only like to work on tech debt okay so be it let's find a way for them to delete a legacy system and transition its use cases off to a modern replacement you know something like that or let's find ways for them to reduce your hosting cost bill by reworking things or deleting unnecessary stuff like let's have them do something tangibly beneficial to the team or business rather

than just kind of rearranging the letters in your code base so that you have to resolve merge conflicts and remember where a file is because it's changed location yeah i don't remember the information about how big this company is that the person works at i'm assuming it's a fairly large company even if it's a small company code bases have layers and for every refactor there's some place where you can't quite finish it off and and code bases develop inconsistencies over time and and there's often efforts to kind of standardize and make everything work the same way and maybe that's some of what these refactors are doing but your your question mentions how do i orient myself in an ever-changing code base and that to me feels like these are these are new

patterns that are being added that don't apply in other places yeah and i think that's a valid concern to bring up of hey consistency is worth something i am often the argument the arguer for inconsistency at my current job so i'm being slightly hypocritical but you can kind of argue against doing this saying hey i i know you think this way is better but it's now going to be harder to understand because we will have two ways of doing it yeah and the global cost to the code base of adding more inconsistency is real and maybe not a thing you consider it is real and think about a developer who's not familiar with the full event history of the full timeline of all the changes that have been made over the years they come in and they're pattern matching off of

some old legacy code that they don't know is old in legacy and they build a feature that way and then during code review you go you have to go oh sorry you're gonna have to rewrite this because you chose to pattern match off of an old file that no longer has the modern patterns that we want to build with yeah that's a real cost you know that significantly increases the time to delivery on a feature yeah i'll take a counter point here jameson which is that it's possible that the question asker is actually a curmudgeon and i don't know if that's the case here but it's possible that some of these tech debt things are actually net positive things they're good they make the developers more effective they are less error prone they are higher performance i don't

know what they are but there might actually be compelling reasons for some of these things and you are that team member who's like well i just don't like it that you change things you moved my cheese yeah how would you how would you know if you are that person i mean are there are there changes you feel like have been useful or improvements that you see that could help is it any change is bad then yeah that's a pretty yeah pretty strong signal that you need to accept some change is potentially good i mean there's a lot of merge conflicts that you end up having to deal with that's one thing but sometimes merge conflicts happen because you just haven't stayed up to date it's like well i haven't merged from the mainline branch in like four weeks

and now i have a bunch of merge conflicts and it's like yeah that does tend to happen if you don't stay up to speed yeah i don't know i guess there's a bunch of different workflows but a four week old branch sounds like a nightmare to me yeah it sounds like another problem maybe this is an experienced engineer who's been here a while. And so they just really know their way around too. I could see that being frustrating. They got a bunch of muscle memory. Yeah. And often newer engineers to the code base come in. And of course, when you see code that you did not write, what do you do? You say, Hey, this is all wrong and garbage and must be rewritten to be correct, which just so happens to end up aligning with how I would write it. Right. And if you have

spent the time to understand why it works the way it does, then that is going to, yeah, you're losing knowledge that you've worked hard to build up and gonna have to redevelop it so i could see the concern around that i just know that i i've been part of teams before where as a team we agreed that there was a better pattern and we had really compelling reasons or at least reasons that seemed compelling to me at the time and and even looking back were compelling but there was one developer i remember who'd be like oh i just can't get this task done because you guys keep moving my cheese like every time i try to commit it's like there's this yeah change that i have to merge or you guys have changed the permissions model so now i can't you know the code i wrote

doesn't work anymore i'm like yeah i get it there sometimes there is a cost let's call it a collateral damage cost to doing something that in the long run is going to be a good thing and yeah it's like yeah it's unfortunate and i wonder if maybe this this uh question asker just happens to be that collateral damage this time or if indeed these are just bad tech debt refactors yeah my And most concrete ideas are, I think it's fair to say, hey, do this in a way that doesn't break my work. Or if it is going to, tell me ahead of time. Let's work it out so I don't just get surprised.

Exactly. I think that covers the ever-changing code-based stuff too. Don't just drop in a brand new abstraction that changes the way a bunch of things work. Tell me. Tell the team so that they know to use it. They can get feedback on it. And it might mean spending more time talking about it and less time doing it, which I think is probably okay. It probably tempers the frantic pace at which this is moving in maybe a direction

you don't love. Hopefully it improves the direction and gives more time to make it a smoother change instead of just abrupt. Yeah. I think if you approach tech debt like a backward compatible API change migration process, A, you're going to be a lot less likely to do it because there's a lot of work that goes into that. Yeah. And B, your team will really appreciate the work that you put in to a inform them oh boy i just did nested a i said a and b and then i did this is roman numeral one exactly roman numeral one inform them yes b uh nested roman numeral one inform them that about the change that's coming and give like give chance for them to give feedback and roman numeral two i can't remember what i was going to say for two but i had to do a second

roman numeral because i've heard that when you're on an outline form and you indent something you have to have a second thing yeah and you do now you do now i do might may or may not be cohesive with the first thing but whatever fair enough all right all right dave do you want to read our next question yeah this comes from an anonymous listener who says hi i'm a software engineer at a big tech company and i'm starting to feel siloed in my individual contributor role i'm getting my work done but i'm often lost when it comes to the bigger picture i can't keep up with what our internal customer teams are doing what they need or even what my own team's priorities are i'm feeling siloed and it's starting to worry me i know that just being a good ic isn't good

enough to advance my career here to get promoted i need to understand the impact of my work be aligned with the team and customer goals and show that i can contribute to the overall success of the company but how can i do it how do i stay informed about customer needs and team priorities and position myself for career growth without getting completely overwhelmed thank you for your precious advice my precious the pressure's on were you saying my precious as in gollum yeah he just came out that was unintentional I think it is for Gollum too

seems like a verbal tick for him yeah this is a good question I think good news because usually people are happy when engineers want to raise their heads up and get more context and contribute more to the vision and direction

I feel like generally leaders managers would prefer if their engineers cared more about this kind of thing and are trying to make them care more about it or bring them that context. So just the fact that you want to do it is useful. I don't think this is a thing you're going to have to like

wade through a ton of red tape to do. I think if you raise your hand and say, hey, I want to talk to our customers more, people will be like, great, awesome. There's probably a point in which you could do it too much and then someone might worry, well, how are you going to have time

to get your work done? But if you're doing none of it right now, I think it should be, you should be swimming downstream to say, hey i would like more context can i talk with our product person or the customers more or be in some meetings or hear more about the direction or whatever was that your experience at a big tech company like were people like excited when you expressed that kind of desire so i was managing a bunch of teams but i think yes i think for the individual contributors yeah if there were like

cross-cutting projects or things like that then i guess it was just me i didn't really see it happen with other people that much. You were the only person that ever showed interest in cross-duty? No, no. I'm saying it was usually folks that I worked with saying, hey, I care about this other thing. And then me kind of shuffling them in to get more context about it. Yeah, that makes sense. I think what you're going to say is that is not your experience though. Yeah, I was a little bit adversarial on that because when I worked for a big tech company, I actually found it to be a ton of work to try to do this. It's not like there's one org chart for a one million person organization,

you know, like it just didn't exist. And there's also not a customer team relationship chart where it would trace out all the dependencies and all the dependees. Like if my team served 73 other teams, there was no one place I could go to find that list typically. And it was just a lot of work,

like just figuring, I don't know, maybe it was because I was in a hyper-growing organization, but virtually no one I talked to could give useful information about who did what or what team served whom. And I remember once in a while, I would stumble upon someone who actually knew what they were talking about.

And I'm like, oh man, I am going to latch onto this person. They're going to get so sick of me, all the questions I'm going to have. So it was hard. Like it took effort. Okay. I think I get what you're saying.

You're saying it was not easy to discover this information. Yeah. Like if I, and if I asked my manager, hey, I want to get more involved with what the rest of the teams are doing and have more influence in the organization. My manager would be like, that's awesome.

And I'd be like, how do I do it? And they'd be like, I have no idea. Yeah. Go figure it out. Okay. It would come right back to me. I think I was just talking about, I wasn't thinking about that aspect of it. I was just thinking about kind of like someone saying, no, don't just put your head down

and do your tickets. Yeah, yeah, yeah. People aren't going to say that, but that's a good point that, well, how do you do it is hard. Yeah, you're right. Everyone likes it, right? Everyone likes to have a team member or someone who reports to them have this attitude, but it is hard to accomplish, I think.

so i don't know what our internal customer teams are doing it sounds like you at least know who your internal customer teams are so ask them what they're doing yeah and does that feel weird you know because sometimes you go all right i'm going to set up a meeting with their team lead and just ask them what they're doing and their team lead is going to be like what is the purpose of this meeting i already talked to your team lead you know like what's this for i know i'm just suddenly i have all this naysaying because i just remember so much organizational friction working in a big tech company like this just trying to get people's attention took so much work well if they say that then great go talk to your team lead about what their team does then i know right you're you're

right of course you're right james and like you shouldn't let any hey shouldn't let any of my naysaying slow you down from doing these things because you have to risk being seen as obnoxious or nosy or out of your lane in order to be impactful like these two things just come hand in hand yeah you never you never change what you are doing and make a bigger impact without affecting someone else and if you do it enough then someone else is going to think that effect on them is annoying or bad or whatever but that's fine yeah totally and you just have to be okay with that yeah maybe they'll say no i cannot meet with you all right at least now i know show me your like wiki page or i don't know yeah exactly guaranteed they have a wiki i don't know why but

every tech company every team at every big tech company has one of these things yeah i actually enjoyed perusing them and i enjoyed the wide range of quality yes you can tell some teams really put a bunch of effort into it and some of them are these post-apocalyptic wiki wastelands document from 2020 well not even 20 i don't know 2005 that no one's touched in a long time i remember i'd come across teams where the someone had taken the time to take all the team's pictures and put them on the wiki but they were actually like a visual graphic of the corporate badge of the person in like a grid for each team member and i was like oh wow hats off to you i am copying this yeah i don't know why i like that so much but i did it and then you can tell when someone

had a person on the team who cared a lot and they left like seven years ago and so everything is just yeah nothing is like it looked really good but all the information is seven years old what is this project i've never even heard of it it's because it died six years ago okay last comment on the wikis at the big tech companies but one of the things i really thought was interesting was there was a team and i actually met the the engineering manager for this team at my big tech company that was in charge of the wiki system yeah i can't remember what this team called themselves but they had a real challenge on their hands because one of the most important things when you're searching for content on the internal corporate wiki is up-to-dateness of the

content you know if you got some wiki page that just really matches all your search terms perfectly but it hasn't been touched in like eight years it's probably not the information you want you know and i just thought man what a challenging job to keep all that it's just a total cruft nightmare was that a custom thing at your company it was a fork of media wiki i think oh okay like heavily customized we just used confluence oh that was probably very expensive i'm sure it was and there was also still a team that had to manage it yeah yeah yeah you were probably like atlassian's biggest customers i guess yeah i'm sure we paid him a ton of money but the search was never good but i i don't know how you would i don't know how you would make it

good at that scale with someone else's software so we actually had three wikis at my at my company and it was like there was like a corporate like company-wide wiki that was hit or miss and then there was like an organization but there were two organization specific wikis totally separate infrastructure or or they were like sub pages in one global one no no like totally separately i remember now that two of them were confluence but they were like different confluence instances and then one of them was the media wiki php thing okay wow oh and our team had two our team had pages on both because like one of the wikis had better integration with the internal metric system so you could like drop images for your dashboards in there but the other one didn't and so it's like

but you still had to have one just because i don't know it was like crazy i know we've talked before about the feeling of running across someone that some some project or some person that that opens your eyes to what a whole giant chunk of many hundreds of people do at the company i feel like that's even easier on a wiki where you're clicking around and then you hear about some oh this this looks very important and i've never even heard of it and it's got all these tracking things someone's stressed out about it yeah i can see the current engineer that's on call his face is right there on the home page i could see the live video feed of types at his keyboard frantically oh man i remember i i really wanted to know how a particular technology worked

at like a famous aws technology and so i went looking for the wiki page and i just could not find it for the life of me and i and i concluded from that that either a this team is like super stealth mode and does not want anyone knowing how it works or b here i go a or b again or b they actually have another wiki that i just don't have access to yeah there probably is some law about how no matter how many wiki instances there are there's one more there's one more than you know about yeah it's uh that's called uh jameson's law of wikis ah thank you you're finally going to get it accept it yes yes and i knew i couldn't call it jameson's law myself because that's one of the other laws someone else has to go yeah there's enough there's a law called dave's law

that says you can't name a law about yourself no there is there is a law that says you can't name it yourself. And it's also not named after the person who created it. I'm pretty sure. Wouldn't that have been the greatest act of irony and hypocrisy? If it was named after them? Oh, yeah. Yeah, totally. Yeah. Anyway, going back to the actual question. What about team priorities? Because we've talked about your customers and kind of who you're

working with, but team priorities is a little bit, that should be easier. Yeah. Like your own team priorities? Maybe it's hard because they change all the time. Yeah. I don't know what my own team's priorities are. This could be hard because your team actually does not have a clear priority or vision and it's sort of just at the whim of the latest whip crack by someone with the letters VP in their title or whatever. Sure. Or it could just be the, you don't know more, which is I think way more common at a big tech company. Yeah. But you should be able to ask your team lead or manager what your priorities are and, and they should be, you might not be paying attention. They should be

talking about what this is a lot and it should be written down somewhere and and sometimes you have to infer priorities based on what you see in sprint planning or stand up but you know what this all of these questions this this is exactly the stuff you should be asking in your one-on-one with your manager and a lot of times people ask us what should i ask in my one-on-one with my manager and i'm like read this question because every question in here like what are my team's priorities what are the organization's priorities what are our customers and what are their goals how can I best contribute to the overall success of the company if I had people ask me this in my one-on-ones

I would be thrilled to explain that to them I would also ask why haven't you been paying attention because I've been talking about this maybe I'm not that clear of a communicator but no but seriously like ask these questions in your one-on-one this is what it's for and you will get these answers and a magical thing will start to happen when you ask questions like

what are our customer team's priorities your manager will start to perceive you differently Your manager will perceive you as someone who is not just turning the crank and doing the work They're assigned punching in and punching out and just doing what they're told They will perceive you as a contributor who can add value to your team And not just have to be told what to do all the time And when you get that perception in your manager's mind It will change everything about your job when your manager sees an opportunity to do something bigger or cooler than what you've been doing

They'll think of you and not and not your co-worker Because they only have one slot and you pushed your coworker out of that slot. Right, good job. You crushed the career aspirations of your coworker. But the point is you want to be in that prominent spot. And I'm only saying this because, you know, this person says, I want to be promoted.

I want to be more impactful. I don't want to get siloed. Great. Put yourself out there and tell your manager that you don't want the, well, ask your manager these questions that demonstrate that you're inquisitive and willing to contribute in more ways than just cranking out the next ticket.

It's also easier to influence the priorities of your team if you understand what they currently are. I think every developer on a team has stuff they think they should be doing or the team should be doing. And there are varying levels of connection to existing business priorities and reality. Sometimes there's just a developer who has a pet project that they think is awesome and you think, I'm glad you're excited about it. We're never going to do that.

It just does not matter or will not have an impact on what we care about. It's easier to have an impact and suggest things that are helpful if you understand what you're trying to do. So it's not just sort of, oh, great. Now I can go do the priority more effectively. But you can say, ah, I understand the priority and I have this idea on what will help us achieve it. Or I think we should change it slightly.

And if you don't understand what it is currently, you won't be able to argue coherently for why it should be different. That is so, so true. I can't tell you how often people come to me because right now I'm in charge of our product roadmap for the company. And people often come to me and say like, Dave, I think this should be a top priority. And I'm like, oh, thank you. Can you please tell me how it ranks against these other 35 priorities? And they're like, it's probably like number 32. I'm like, great. Now I actually understand. it's just so easy to be like to say this is important but it's a lot harder to say this is actually 17 it's in position 17 on my important list yeah so that's great just having more context is just so so useful it is and that's how you get it you ask well have we answered this question well i think so we certainly talked about big tech corporate wiki strategies enough yeah oh i had forgotten about those me too nostalgic honestly they were great i thought i'd be

nostalgic for confluence didn't it kind of feel like your team just couldn't exist at one of these companies unless it had one of these pages yeah like it it made your team real yeah it's like a charter yeah it was almost like if you tried to schedule a meeting with someone else and they were like who are you and you didn't have a wiki link to point them to they'd be like you may as well not exist then you thanos snap devolve into dust exactly honestly it was great man i could you could learn so much and i just realized okay last riff on on corporate wikis i realized that one way to scale an organization to a large number of headcount is to write these things down because after a certain size if you have if you are a member of a team that interacts with other teams

at the company there will come a point in time where there are so many other teams that you will do nothing but explain what you who your team is and what you do for 40 hours a week because there's so many inbound inquiries about it and so you just you have no choice but to write things down and i just i really kind of loved that that forcing function that large organizational scale had on us to do efficient things because if you didn't you got insta crushed yeah i hadn't thought about it that way wikis oh we're good we are so cool dave you and i are so cool you should see me at parties when i bust out the wiki topic it's like people just like circle around me say more about how you had three corporate wikis wow hanging off your every word and one of the wikis

used camel case for all of the keywords oh wow oh tell me more about your tagging instructions if you want to be interesting at parties what should you do well don't listen to this show start step one unsubscribe or if you want to get a question answered go to soft skills audio and click the ask a question button where you can submit a question thank you so much to everyone who's done that our question backlog has gotten big enough that when i print them all out on paper it creates this really soft fluffy bedding that i actually put under my mattress like between my mattress and my sheets

and it comforts me at night and i just snuggle up to it it's so wonderful ah that's where i put the patreon money the cash you have to let me know directly my my quality of sleep trends up or down depending on how we're doing yeah do you want jameson's toes to stick out of his hundred dollar bill blanket at night you need to join patreon so jameson's toes don't get cold it's like a quilted benjamin's i throw the blankets off at night because i get too toasty oh he's a hot the room is yep bothers my wife to no end okay well i need the blanket so keep them keep the patreon going we we appreciate you for listening and for asking questions anything you do to contribute

including just your your the bits going into your device makes us feel great thank you all right we will catch you next week