Who The HELL Needs Documentation?! (*YOU* might...)

Transcript is auto-generated and may contain errors.

all right it is Wednesday morning the drive to work um yeah apparently with the rain and stuff what's going on oh said my seat belt wasn't buckled up it's indeed on um with the rain it's saying it's going to be like an hour to get to work now the other day which I lost the recording for on Monday I actually had it say that there was no slowdowns nothing and it was going to be like 32 minutes and I got to work a little bit faster than that which was awesome so this says an hour I think we can do better um as long as the fast Lane's open we're set uh yeah I have a couple topics uh I'm going to get through over the next couple drives because I lost two entire sessions I will redo those not on this but I will

probably start redoing them on the drive home just unfortunate uh I don't know exactly what happened but I think that there's a button on the top of my camera which is on the bottom currently as it's mounted upside down um and it's beside the power button and it switches between modes and I don't know what the modes do but I think one of the modes tells the camera to not have any audio because I had my morning video I did three videos that day morning one leaving CrossFit was great and then the two which I saved because they're longer drives the two of them were just completely silent and when I was looking at the camera and the settings it was trying to see if I messed up the audio at all like the I don't know like if the device wasn't sending audio um

because I have a receiver obviously because this thing and uh it was just like oh audio something is not like available in this mode I'm like I don't what mode like isn't how many modes are there so anyway I was pressing some buttons on the camera and I realized that once I pressed it a couple of times it switched and I could actually see the audio input back on the camera um because I was not having the levels show up on the camera itself the levels were showing up only on the receiver so it was truly a camera setting but anyway we're good for now just sucks because it's like I don't know an hour and a half of content that I one of them the first one I was like I felt really good about everything I covered I was like that was a

good a good Vlog a good juicy Vlog and now it's gone forever uh but this one that I want to talk about is uh from my Discord server so if you aren't aware I do have a uh private Discord Community if you sign up for my Weekly Newsletter which is just at weekly. Dev leader.com uh completely included in that um and that's where I mentioned in the previous video like I have a top mate profile for uh you know for people want to book calls and stuff but the Discord Community is like I set that up so that I could have in one place like a spot to answer questions for people so that's my my preferred way uh if you're if you're if you enjoy the information I put out whether it's from this social media platform so my primary YouTube channel and you're

like hey like this stuff's helpful I'd like to ask more questions um it's easier for me to answer there because it's all in one spot so the question was around documentation and uh specifically um it's funny I don't think I've ever heard this term before but uh we've talked like you hear about like Green Field projects or something that's brand new but uh the term that was used was Brownfield projects so I'm assuming it's just the opposite of Greenfield projects I just don't think I've ever heard anyone use that term so I'm assuming that means existing uh you know Legacy or just stuff that's not new you're building on top of it so the the question was really around like how how does one or how should one maybe how do I approach documentation uh when picking up work for a brown field project versus

is a green field project so I wanted to start by saying that I'm pretty I'm pretty mixed on on documentation and the reason I'm mixed on it is because I think theoretically there is a ton of value and documentation a ton um however I think in as long as I've been in the industry which is how long is it now almost 15 years 12 as a manager yeah but just yeah just under 15 years um I have never seen documentation that's done well that didn't take an extreme amount of effort to keep it that way so I want you to think about that for a sec because what I'm trying to say is like I do think that good documentation is incredibly valuable but if you're a software engineer you know everything has a trade-off so I think you need to think how much effort

needs to go into the documentation for it to be useful and then beyond that like what's the tradeoff for it right so if you had zero documentation at all zero it would mean that onboarding someone new to anything would probably feel like a pretty heavy lift but like and everyone's situation is going to be different right so don't like don't jump at this but like if you're not onboarding people ever or extremely rarely maybe who cares maybe uh the effort to maintain it would be so great anyway that you might as well pay it once a year pay that that price of having uh someone on board once a year and it takes you oh you know a couple days or a week uh on and off to go explain something to someone whereas maintaining the documentation um would have been a lot more effort

throughout the year just as an example right um so these are things you need to think about and of course if you're a company or a team that has uh more people on boarding or um it's not even onboarding it's going back to work on stuff too like having documentation can of be helpful because people can go read search what they figure out what's going on and then and then make progress instead of just like taking someone else's time or not even being able to do that and just guessing and hoping that they can go figure things out I should plug my phone in um so again I'm just going to repeat it I think that documentation is incredibly valuable I do think that good documentation is very costly so um I was thinking about this maybe a couple months ago and I was thinking

like like I work at Microsoft fulltime I do content creation on the side I create courses on the side I have brand ghosts that I'm building to help with my content creation and a couple of other small things like I do um I I don't know if you'd call like fractional CTO work for um for some software that's being built so like I I got a bunch of stuff going on now if I didn't have to if I didn't need my full-time job and don't interpret this the wrong way like I like working at Microsoft I like what I do but if I didn't need my full-time job and I could just go bu because I love building software if I could just go build anything I wanted to I think a really interesting project would be um and I don't know how this would

pan out but something that's like a uh like group of AI agents that actually build documentation for you and constantly maintain it I think that might be something that would be super cool if they could work off context of like um whether you use jira or something else right like whatever you're using for tracking work if it could use git commits if it could use your source code uh maybe I don't know if you have to go as far as chat messages and emails whatever but if the agents could use all of this information and then just spend the time going to draft the all of the documentation and then constantly oops I spat on myself I got too excited uh constantly update it so that because this is what people have to do right now again you might hear this and go well that

sounds scary like AI agents like they can't do a good job yeah I don't know like I'm just saying like I think this would be a really cool thing to go build because over time like basically AI agents are only going to get better they're not going to be getting worse it's just that's just a fact the it's they either stay the same or they get better it says 25 minutes of traffic added oh great okay so that's I think a super cool idea and like if I had time to go build that I would go build it and then I think what's really cool about that is like if you have that running on the side you can dog food it so like again if I'm just building stuff for me I don't I don't really need documentation like I don't care I don't

care enough about documentation that I'm going to go maintain it uh at work it's a different story I think there's different trade-offs but if I could build something like that with AI agents I think that would be super cool uh um to have it running and I could tweak it and then I could just allow it to go build documentation for the stuff that I'm creating and just like not even think about it I just have like what feels I like wikis they're just such a pain in the ass to maintain such a pain they're always at a date links are broken stuff's in different spots but if you had AI agents constantly just refining where this stuff was like I I think personally that like that could be something that works really well if you were to use that in like an actual workplace

uh you could supplement it with actual people right so the AI agents could be constantly trying to make things better and if you periodically had someone reviewing it and like uh injecting actual more beneficial content let's say maybe they they didn't do a good job explaining things on one page like you have a person go sit down and do it now there's more examples from the AI to model from like just stuff like that I think would be a a super awesome feedback loop but in my opinion that addresses this constant need for trying to keep things up to date because I think that's the biggest problem with documentation is keeping it up to date which is why for onboarding documentation I always recommend to people like uh to teams if you're if you are act like actively bringing people on if that's like not

unheard of for your team uh you know versus like hey you're like a solo Dev and you don't have to worry about this kind of thing your team it has the potential to grow or change people having onboarding documentation is super helpful and then you basically just have the last person to onboard updated as they're going because stuff's going to be at a date it's going to be broken onboarding is not something that happens that frequently for most places I guess um so have the last person go update it right like hey this Link's broken cool oh this process doesn't isn't applicable anymore cool go update It Go change things you get to be the maintainer and then everyone gets to kind of share that as their onboarding and you can do this with other documentation as well right like if you're if you have

documentation you your team likes the idea because they find it beneficial but it's always feeling like it's out of date if everyone takes a bit of the the pain they pay the tax to go uh update it then then it's spread right you kind of share the love that way share the love not the it's it's not a tax everyone loves documentation okay so back to the original questions though for Brownfield projects or something that already exists you're about to go build a feature what does documentation look like and I think the idea was around like uh maybe like a design dock or something so currently the the teams that I I manage uh at Microsoft like our our larger team so like my manager oversees a much larger team than me and then I have a portion of this and then so I manage

like a team of people but that team of people is split across four separate like product/service areas Just For What It's Worth so it kind of it's like four mini teams if we can put it that way four very small teams and in our larger team so under my manager he's very um he and I'm trying to pick the right word because I want to say like insists or expects and I don't want that to sound negative because I think it's good uh like he's insistent and promotes there we go like promote is a good word he promotes like a design dock culture which I think is very helpful um for the stuff that's getting built and I think the biggest benefit for design docs how we're using them is just that you're communicating ideas and it's like forcing function to communicate and to have

other people's input that's it um beyond that like is it is like is it beneficial to have the system documented yeah I think so um now like all things documentation related whatever that design is right now by the time that thing is built the design is going to be out of date and it's because you're guaranteed along the way to find things that don't exactly fit the design it's just it's just a reality of software development um as you get better and more experienced do you minimize those things sure but like you can't control all of the unknowns that's what unknown means right so um someone rev their their engine at me and their debadged like Acura something cool bro um so yeah like I think and I would recommend like uh something like this it doesn't have to be a super formal process you

don't have to make it more work than the actual like than it needs to be but I think having thoughts written down and having other people look at them give their perspective and then having that as something that's like um like archived or available because if if you inevitably have people in the future going hey like why did we make that decision like why did we pick that database Tech why did we pick that algorithm like why did we optimize for um you know uh uh for bandwidth but like uh we were going to like chew up like five times as much memory doing this like why did we decide that having something like a design dock for a Brownfield project where you're building features on top of it I think can be can be very helpful for that kind of thing now again you

have to think about this in your team so you have these design Docs like what are you doing with them after um do you have to go build out further documentation for the feature area the product or the service that results from this who's going to maintain that what does that look like I I just think that anytime you're creating documentation you need to think about the lifetime of it so maybe just as an example maybe you do you have a design dog culture on your team but maybe your team views design dogs is just a way to make sure everyone's aligned when starting the project maybe maybe team agrees on that and you're like we don't care after like we talked about this cool we know things are going to change great like thanks for the design doc thanks for disc thanks for the

discussion basically now as we move forward like we don't care about that anymore because we acknowledge it's going to be different and evolve okay so that documentation and that example has a very short lifetime now your team might say but we do um you know we have a Wiki that we maintain whatever you know whatever tooling or system you have we have this thing that we want to maintain and we do think that information needs to be put into that and that's the part we're going to maintain but the design dock that was just something for conversation to get people aligned before doing the work so you can in my opinion you can think about these things in different ways different tools different lifetimes of them different purposes um and there's no right answer right like you might do this on one team and switch

teams and that same approach would just be terrible so I think it's good to be thinking about these things and not um not dogmatic about them for example not like every every time you're about to touch code you must have a design Dock and every time you have a design dock you need to maintain it for the lifetime of uh eternity and then also have a Wiki page and also make sure that you email out the updates to the Wiki page just like maybe that works really really well on some project and then on the next project that's the biggest load of crap ever so I think it's important to think about your options and what those options provide you like what benefit and what costs they have because the more documentation you have the more tax there is to pay to keep it up

to date unless you write code and never change it ever which um good for you because I think you figured out something that no one else has so that's on uh maybe that's covering both brown and green field but maybe I want to dive into this a little bit more to separate the the brand new Greenfield stuff versus Brownfield because my answer there was so far like kind of a shared perspective this might be the longest drive that I've done on the the Vlog so far it still says 40 minutes I feel like I've been in here for 40 minutes it's because I'm talking about documentation all you guys asking about documentation um so when it comes to Greenfield stuff like I spent a lot of my career doing and I'm trying to think about this maybe for the first time in this context just

by the way like probably if if this is your first time watching one of these like buckle up but um if you've watched a few of them before you know that I'm uh sometimes thinking about the thoughts in this order for like the first time which is uh maybe why you enjoy this kind of thing um so like I spent a lot of my career doing like prototype work U prior to Microsoft like even my internships uh a lot of it was Prototype work like I had one internship the role was literally like software archit intern and at that company architect the title was used for uh basically like prototyping and proof of concept work like trying to help shape the direction that we want to go with certain things that was a super cool internship because of that so and then at the forensic

company magnet forensics uh like I was there for 8 years and all of those eight years was basically prototyping uh a lot of the the bases for the new products that they were building so I literally did like no documentation on any of that stuff um and that might sound like startling I guess but I think it wasn't uh I don't think it would have helped and I shouldn't say no documentation I think let me let me rephrase that when there were situations where we were evaluating a technology Choice One versus another I think we would like Su like we would we would research and then report our findings so just to make up an example uh like no this is this is a real a real example I just can't remember all the details like we had to do um what do you call

it uh when you do like image to text um OCR yeah OCR is the acronym object is it object character recognition I probably have optical character recognition I probably have that wrong I apologize but OCR I believe is the acronym and we were evaluating different uh available OCR libraries so we compared like uh free ones we compared paid ones and then we just ran them through a bunch of different experiments and tried to see like based on our use cases how fast are they how accurate are they like how much do they cost so so that was an example of prototyping for a feature that uh required some research and then it didn't have like a I don't know like a formal design dock like we were so um kind of like do the do the minimum amount of work to convey the purpose so

like when that work was being put together and we were looking at it it was like you don't need like a formal presentation you don't need a formal report it was like we agreed on what the test cases were that we were interested in we evaluated the results then we said okay we're going to go with this and then we didn't go like add to a Wiki we just had like a jira ticket where we made sure that stuff was so I guess a lot of the time stuff got put into jira um but it was more like kind of a brain dump like especially if we were doing research uh I would I would even tell the engineers on my team for the the mobile digital forensics product CU a lot that stuff was like no one else had done it so it's like

you're you're truly pionering things and they're going to get stuck of course because it's new and it would just be like okay you're stuck you know find a pivot like we can take a break from that just write down like what you learned so it was not like formal documentation formal proposals but it was just like notes like what things did you look at because if you're going to come back to this in the future you want to pick up where you left off and now the interesting thing about that is like the tax for that was actually very low because it wasn't documentation that you needed to maintain it was just a snapshot of things that you had learned up to that point and then you pivot off the work no one else is working on it during that time and if they were

they would just add their findings into the jira ticket and it was just serving as like a you know again like a brain dump of like the things you're trying out so I guess what I'm trying to say is like I spent a long time doing prototype work and we never really had like official documentation but we did have notes on like when we were trying things out or exploring just to make sure that if we had to come back to it we had some idea what the heck was going on so that's my my perspective on that kind of stuff but um it changes right like I want to I want to give you another example so um there is a product that magnet forensics has called uh magnet uh I think this is called cyber um so magnet forensic cyber like I built

after hours I built the original cyber tool that they have like a solo Dev project um I worked on that built that on the side and that was again a prototype uh the the CTO was very confident this is something that they wanted to do like as a business but it was like we don't have capacity like there based on how the engineering teams are structured like we just don't have capacity for more things and I said well I'm hungry like I'm I'll go work on this so I worked on it after hours and built it and once they had once they were like okay like this works we want to move forward with it again I didn't do formal documentation um this could have been something that was formally documented but instead there was like a there was almost like a one-time handoff to

a team so they ended up carving out uh individuals from uh primarily one team in particular and said you folks are going to be focused on this we have a basis for it um fortunately like I had you know because I was there for a long time I had built a lot of the code base that they were already working in so I knew I knew like how Stuff looked there I knew a lot of the new world order that we were trying to look at for coding patterns and stuff so I actually had feedback that because I was like oh I bet you they're going to rewrite all of it when I hand it over and I had feedback and they were like no we didn't have to like fortunately like it actually a lot of it dropped in place now at this point

point in time it's been a few years they might have Rewritten literally everything I wrote that's fine but there was this transition phase where it was like let me hand it over like you can walk through the code I'll explain what it does so I didn't spend the time writing the documentation I spent the time explaining to people that are going going to own it going forward and evolve it I spent the time explaining to them here's how it works here's why it's written this way so it was like a one-time tax and it happened to work very effectively in this case someone's honking who's honking I'm in the F I'm in the air quotes fast lane so you can't be honking at me only because like they can't get in here I mean technically they can physically just cross this this double solid line

but they're not allowed to so so and like that's an example of like we didn't opt for documentation yes it was a Greenfield project and it it happened to work out very well um I feel like if there wasn't an opportunity for a transition period or something like that then yeah that thing would have need to be heavily documented because how else would like I would not expect that team of people to go inherit this code with no explanation and no documentation and just be SU successful um but yeah I think you know just one example from my experience where not having documentation was totally fine because we had this other mechanism um now beyond that like I don't I don't think I don't know if that team started documenting some of that work um as they started to build things out I don't think

they did but um that could be something right uh I just thought about another thing uh totally random but um kind of thinking about work and and uh and writing notes down so not again not like a formal design dock but like writing notes down when you're going through stuff um we actually leveraged notes a lot for like patent exploration so that was another driver for um for having some kind of documentation again not necessarily the documentation that you keep maintaining so that people can on board or or use something that's new to them not that kind of thing but like we made decisions or we learned about something we built something and like writing down what that is and maybe how it's novel and why it's novel uh like that could lead to to patent uh patent ideas so like that was another thing

so we would go comb through all of that information and see like hey is this something that we could look at that's patentable patentable it's a weird word to say um so that that might be another motivator for why now depending on where you work how big the company is and stuff like patents are expensive to do and doesn't just mean that you're protected because you have to defend your patent so I'm not trying to tell you like hey like go do all this so you can file patents like um unless you got lots of money it's probably not going to be a great time so I'm trying to think if there's other examples about like in general like today at Microsoft if we had a project on one of the teams I manag and someone was going to build a new thing so they

have a green field project I would absolutely say that thing is getting uh documented and and there's a bet like I think a good reason for that like there's a lot more teams involved a lot more people involved and a lot more scale involved I think at the forensics company the scale was much smaller uh the number of teams was much fewer so like the benefit that you would get is less not zero it's just less because you don't need to communicate these ideas to so many people um it's a small number of people and it doesn't necessarily need to be Perpetual it can be a one time thing but at like Microsoft if we started building out a new service to replace something or to to supplement Like It's a Brand New Concept we're doing odds are that's going to interact with other teams

so having some type of formal documentation go into that I think would be very beneficial um not to mention all the stuff I mentioned sorry not to exclude all the stuff I mentioned uh early on about just like having the ability to to communicate back and forth on ideas and getting feedback from people because I think that's critical so yeah I guess I want to see if I can summarize a couple of meta points here um I mean one I think it's important to understand the the tradeoff like the pros and cons for documentation because what value is it going to add to your team and how are you going to maintain it right the benefit versus the cost oh man good yawn came out of nowhere that's one part um number two I think is like the lifetime of different types of documentation uh

and lifetime I should also add in like the audience for that documentation like what is the purpose of the documentation and like a a number 2.5 I guess is like considering like what documentation types you actually need right like do you look at a design dock as something that you maintain indefinitely uh or is it just a conversation tool um yeah I think just different ways to look at at what you got um Green Field versus Brownfield again um I think this can be totally uh I I don't I don't think I necessarily look at them differently as what I would say um you might have something green field like I was describing where maybe you want to take some notes from your exploration but like you don't need a formal dog for it uh and maybe the opposite like the example I said for

Microsoft where we might really want that this person's tailgating me but I don't think they understand that they can't uh they can't go through me and even if they could they would have to go through the car in front of me too so feels pretty stupid um no shortage of that around here though sorry I'm quiet because I'm trying to move away from this person tailgating me and you're not going to see them cuz they're going to fly up on the other side and then not be able to move up at all which is super awkward for them Let's Go Nissan Rogue you you go yeah I I think again to summarize the point in the beginning I think that the the theoretical benefit to documentation is there but I I have not yet seen ways to maintain uh documentation that's not costly so great

documentation seems to come at a great cost uh I'm not saying it's impossible to do otherwise I've just not seen it done um which is why I was saying I wonder if leveraging things like AI agents to basically just keep documentation up to date right like so that it's not starting from Z zero uh could be very cool um it might have the same problem where it's not up to date enough right I don't know but could be an interesting thing for someone to explore I think I would like to to build something like that if I had lots of free time but I don't have lots of free time so I probably won't all right we're almost in the clear finally getting through this traffic well almost now I'm about to merge over three more Lanes to get off the highway it's looking pretty

slow right here so we'll see we will see um otherwise I mean I'll fill the last little bit on the on the drive cuz there's about it says about 10 minutes to the office from here um we launched a bunch of stuff on brand ghost so I'm super pumped about that we got our um oneoff and scheduled posting stuff so if you've used tools like buffer or hoot Suite or a million other tools like that uh we can just do oneoff post and stuff for you like that now shows up on the calendar view which is a a refined view of what we had before which I think is a lot lot nicer now um it shows the posting status so we tried this out yesterday was a cool experiment um move over buddy come on you got to let me in someone's got to

let me in it's going to be you pal oh no it's not couldn't do that in the X1 laner car um yeah so it's we we did this test post where so I have a Tik Tok account um and we have Tik Tok coming in brand ghost but it was like one of the things I set up super early so like the Tik Tok account won't work properly to post to Brand ghost uh at this moment so I said okay I'm going to send out a scheduled post to eight platforms and one of those eight is the Tik Tok platform like the account that I have and we also show the post status so it was super cool because I blasted it out and I'm so used to like going to server logs and being like okay like did everything go and I'm like scanning

through uh net Aspire um and being like checking for IDs and stuff and I was doing this and one of the other developers is like well did you look at the he's like did you look at the post status and I was like oh my God like I forgot we have that now and sure enough I could click on my my post in the calendar that had gone out and it was successful on all of the platforms except Tik Tok as expected uh so it was just super cool because what used to happen like when I was triing this feature out from just using the backend functionality CU we've we've been able to do this for a while now like literally topic streams are the same thing we post right we just go across platforms it was just building this us experience for it so

I've been able to do it from the backend server for a while but without having the user interface for it uh it was super error prone because like I'm like handcrafting Json and and Postman and stuff like that and then we'd go post it and well the only way for me to know is to go check all of my social accounts or to go in Aspire and look through the logs and see if any of them failed so um it was it was just a really cool experience to be like I don't have to I don't have to worry about this now so that's super cool um we had this really funny I like talking about the stuff that I screw up because I think it's good learning um we we had this we we do this a lot actually and it's I don't think

it's a bad thing but we like we don't over optimize in the beginning so on the calendar viw for example in order to get the information we were making a bunch of separate queries and that's because we're like we don't even know how this features truly going to shape up so let's use what exists already and then if we need to like we'll make like a faster bulk API we'll do it right but if we don't need it let's not so we had it working on like on a uh like in production right just because we haven't pushed it live at the time but it was working we were like looking at the results and stuff and then there was one evening we were all like on a a slack call and someone was like yeah like kind of weird like server felt like feels

kind of glitchy like we're doing actions and like some of the things feel like they're timing out it's kind of weird and then we went looking through the logs and like I had this panic attack in Hawaii almost it was almost a panic attack of me like in Hawaii couple weeks back we saw like these uh our instances were like making replicas now since then I changed the code so the problematic code can support multiple replicas it's no issue um but I saw the same type of pattern in the logs and that usually happens when the server is either one starting and crashing on repeat or two there's a ton of traffic in the HTTP scale of for Azure kicks in so we were like initially I'm panicking cuz I'm like oh no the server is like basically booting up and crashing um cuz the

logs get very noisy when that happens and I was like oh no oh no like the server is probably down that means we're not posting so it started to panic but we realized it's the HTTP scaling and it's the HTTP scaling because on this calendar view um what's happening is that for every item and we didn't make the bulk API for it so it was making a separate request so HTTP scaling kicks in which means we have we're doing more processing uh than we have to by a long shot when that happens cuz we start running multiple schedulers because it's a monolith anyway um not only were we not doing this bulk API from the front end but the server uh per API call was doing like many SQL queries and when we looked at the at like the the metrics right like the CP

usage across the the board was very low because it's not doing a lot um but when we were looking at the database view we were like 1,200 I don't know why you would use this view it's really dumb there's like a an Azure and we saw this even in AWS so it's not platform specific but we were looking at uh SQL connections and it does like a sum view over time but like I don't know why that really matters I just want to know like maximum concurrent in a period of time right personally um but yeah in the Su view it was like it spiked up to like 1,200 connections and I'm going like how the hell how the hell do we have 1200 database connections like this makes literally no sense um and yeah it was honestly just because we were doing like per

request and we were in the example that we had set up we were doing like like I think it was like 15 requests per per 15 HTTP requests that we would go blast and parallel um then we would go do like uh I think like four or five squl queries and it was just Mayhem because we were like constantly refreshing this page and it was just blasting blasting in the server with all these requests um so the very next day uh actually it was the same evening after I got up this call but finish it the next day where um I just converted that API route to to do a bulk lookup and that means we could do one HTTP request instead of 15 in the example and then it was one SQL query instead of the the four or five so um yeah just

tremendous amount of reduction and there's no we don't even have cashing yet that was one thing in meal coach I jumped into cashing stuff so early that we had all kinds of crazy cashing bugs like we would go to do something and we're like wait like why is that data coming back and then we would go look and you know it would be cashed or we would have a collision in the cache because of uh like it needed to be filtered by user and there was no user concept for a cash like all this dumb stuff because cashing is not easy so we're not caching stuff yet I'm waiting so I'd rather optimize the queries and then later uh focus on running the queries uh less often through cashing I have to readjust this this is a terrible Park job no good nick no good

let me try one more time no one's watching right okay much better much better all right I think that's it folks um I got a couple topics for the drive home I'll try to pick one and we'll go through it I'm going to try to repeat the one that I talked about earlier this week um so see you then