Welcome to Syntax. We got an amazing question in our inbox all about how did you deal with the stress of meeting a hard deadline when you're behind on work and tickets are coming in? And we're gonna be taking this entire episode to answer that question, talk about the stress of work, dealing with this stress, and making sure that this doesn't happen again. My name is Scott Tolinski. I'm a developer from Denver. With me, as always, is Wes Bos. What's up, Wes?

Yes. This is a great question. Thank you to whoever submitted it. If you have other questions for us that you want us to answer, go to syntax.fm/potluck, and we'll answer on an upcoming episode. Usually, we put them all on a single show, but I thought that this one would make a nice tidy, quick little episode about deadlines and stress and and whatever. So I think everybody feels that. You know? I just wish I had a bit more time, or I just wish I could get more done in the time that I do have.

Yeah. You know what? It's very funny that, like, this feels like something we could have talked about four or five times on this show, and we've never done an episode on this specific topic despite it being something that I feel like all of us have dealt with in our professional careers. I used to actually work at a lot of agencies, so I know, you know, there's all kinds of different entryways and pathways in this industry. And for me, I worked at three different sizes of agencies from a small time agency where, I was one of two devs to a little bit larger where I was one of five devs and then a massive agency where I was one of I don't even know how many devs because it was, like, a 2,000 person agency. So Yeah.

I I gotta say, I feel like I've run the gamut on fast moving projects, hard deadlines, things that need to get Deno. And I feel like I have some good advice Vercel. But, also, like, you know, we just did this mad CSS thing, and that was a a whole team project. Right? Our whole mad CSS tournament.

And Wes Sanity, we're gonna do this to coincide with March Madness, which that's a hard deadline, to say, okay. Let's do a March Madness. And you would not believe how fast everything snuck up on you, whether that is building an entire competitive coding platform or, Wes, you built a bracket site.

We had merch. We had all these meetings and stuff like that. Yeah. It There's Sneaks up a lot of deadlines. So quick. It's it's unbelievable.

But, also, I almost prefer a hard deadline like that because it is so easy to say, we'll push it to next week. You know? And then things never get done. And and you look at some of these companies like Anthropic and OpenAI and whatever just shipping like crazy right now, And you have to think like, man.

First, those people are probably not getting good sleeps.

And it is probably nuts, and they, for sure, are working weekends and all that stuff. But, also, I'm sure they have lots of good tips or whatever to to move at the speed that they are.

Yeah. You know, it is funny to hear, like, stories from the gaming industry about game developers, like, really big, like, brutal schedules, especially towards the end of of game things. And and you gotta feel like so much of that could be solved with better process and better planning and organization. But what do I know? I've never built a video game before. I'm sure it's very hard, and there's a lot of work involved. But you do hear about that. And I know that there are some folks that that is their kind of entire existence in this industry JS constantly getting pushed by deadlines. I feel like I've had a job that was like that before as well. There's also other jobs that had hard deadlines, and the team respected each other. And everybody did their their share fair fair share share fair and, got it done in the time that was acquired or allotted for this. So, what can happen if you're under a tight deadline? Well, magic can happen JS you said. Right? You can get stuff done, but you can also have mistakes.

You can have costly mistakes, stakes that end up being whether security holes or something like that because you're just trying to get this thing done.

Maybe you end up having, you know, a lovable sized hole where

you have all of your customers' public chats public. Who Node? Right? But Is that how it happened? I didn't even catch up on that. Lovable had all their chats public?

Lovable you know, it the lovable thing was really frustrating because they basically were when the it was announced that their there was, like, customer chats and information were public.

And somebody was like, I I told them about this several months ago, and they didn't do anything. And then they were basically came out and said, we did not suffer a data breach. Our documentation of what is public is unclear. Basically saying, like, we didn't tell you that your chats would be public, like, clearly enough. So, therefore, we're not at fault for them being public, which oh, yeah. I was just, slimy.

Yeah. It looks like their JSON API was was public, and you're able to find the different messages from people? Man.

Yeah. I should Node. They had to come out with a second statement. We're sorry. Our initial statement didn't properly address our mistake. Okay. Yeah. Well, you know what you're doing.

Okay. So bad practices, you know, costly mistakes. What do you do? How do you prevent this? I think the hardest and most beneficial thing you could possibly do in a scenario where you are stressed to the gills about a deadline is to slow down and take a step back, which I hate that. I hate that advice. I hate that when, I'm, like, stressed out about stuff, and and Courtney's like, did you do your to do list and break it? I was like, no. I'm just trying to get it done, but I know that's gonna be helpful. To do list. Yeah. No time to plan and to slow down. And it's it's the right call every time. It's just like Wes they say deep breathing is the best thing for you, and you're just like, I don't wanna deep breathe. Let me deep breathe.

It always works, folks. The stuff that always works is always no fun to do. But, yeah, slow down.

I think the biggest thing you can do here is take stock of what actually needs to get or or what's actually done currently and what's not.

Anytime I end up having a deadline, that's one of the first things I do is I, like, go through where are we at today, like, where what exists, and just get a real good handle on exactly,

what the lay of the land is. Take a step back. Here's what it JS. And that could be using something like like linear or some sort of, like, issue tracking system, some Kanban board. It could be simply just like like writing it down in a Notion document that says, this is what we've done. This is what we need to get done. And, like, for me, when I'm stressed out, just simply just writing it down, putting them in like, I use a to do system.

Yeah. And I just love out of your I would say out of your head into your system. And as long once it's there, you can you can go, oh, okay. At least at least I see what needs to be done, and I could start tackling or breaking them down or just, like, taking a step back and looking at what all those pieces are.

Yeah. That's such a big thing to get it out of your head because part of, like, what is attributing or contributing to the stress of it all is this, like, looming cloud of unknowns.

Like Yeah. What do I like, oh, I have this big thing that's hanging over me. What do I have to do here? Actually, like, I get maybe the big picture. I get the assignment. I get the end result. But individually, files, sections, designs, like, what do I have to do? So making making a plan at this point, like you said, out of your head, into your system JS the most impactful thing you can do for yourself.

And I'm an optimistic person by nature, so it's a and, Wes, you know this from working with me. I often just think, well, it'll get done. You know? And Yeah.

And you can't you have to be very realistic about all of the little pieces that need to get done. You have one thing that says here JS uncover questions you might have about the spec or Node. And this is a big one for me as well because when you get talking about it, when you start trying to write things down, that's when the questions start popping up. Like, oh, how are we going to do x, y, and z? How are how is this feature gonna work? How do these things relate to each other? How is the integration working? Who who is going to be deploying this thing? You know? Like, there's all these, like, little pieces that you may not have considered, but when you start putting them into a system, then you start to surface them.

Yeah. Or yeah. Even that planning. I remember when I worked at Ford, we needed to get legal approval before installing anything. And I remember we were, like, up late on a weekend trying to knock out a project, and it was like, oh, we need this library, but we can't get legal's approval for it. And everything's due on Monday, but we didn't plan well enough. So we don't have legal's approval, and we can't have this done by Monday.

So we're just gonna have to rewrite the library basically ourselves or hack something together in time because we didn't plan well enough to know that that was something that we would need. And if you were to sit down ahead of time and be like, here's the plan. We're doing this, this, this, this, this, you might say, okay.

Here's the library needs that we have. Let's get legal approval or even, like, API access. Like, can you imagine if you're you're again, especially, like, if you're working on the weekend or something to knock these things out, and you don't have access to the one thing that you need to solve a problem. I know that's happened to a lot of folks, because those are the types of things that you identify when you're getting into it. But if you're planning out and you're reading the spec or whatever it is or you're you're going over in your head, maybe you're writing your own, pnpm or you're you're getting through everything and what the needs are, you uncover those little edges that you might not have thought about when you're just looking at the big picture of it all. Yeah.

The worst is when, like, you're like, oh, I can't do that because there's something else in front of it. Like, one example for us was we wanted to move the syntax CSS platform Mhmm. Over to the syntax domain name.

And Seems easier on the on the Yeah. Yeah. You know? Throw it on a subdomain, but it ended up being, like, it has to be on CloudFlare workers. So but Scott.

We have the syntax CloudFlare account doesn't actually have the syntax domain name in because that was still on my account. So okay. Now we need to Node access to your Yeah. You don't want my Yes. So okay. Let's move the syntax domain name from my account to the the syntax CloudFlare account. Oh, now we need to change the name servers.

Somebody else has access to the domain name at Century. Right? So we gotta find them, and they gotta they gotta figure out who has logged in to that, and then they gotta update the name servers.

And then we move that over.

Oh, now the the app is failing because, the free plan on Cloudflare only gives you ten milliseconds per request, and and we needed the, like, forty milliseconds because we're going just going over it, and they were failing. Oh, now we gotta request a credit card. I'll just pay for it myself. You know? It's like all these things just stack in front of it. I was like, man, if I would have done this moving the domain name over two years ago, we would not have been having this problem.

Yeah. So those things just stack in front of each other. I know. After after you're, like, getting through it, I I would be methodical in your planning system. Like, where I I think, personally, you know, I think different people work different ways. But I I like to get really deep with my planning and, like, really outline things because even in, like, code I don't know if you'd like to do this sometimes, Wes, but when you have, like, a really intense coding problem, I'll, like, kind of write out the logic in comments and then fill in the code in those comments later. So for me, this is kind of like that where you're, like, pseudo Node the to do yeah. It's the same way that people write an outline before writing, I suppose. I'm a terrible author. Right? Mhmm. So And now we're just making the bots do the same thing. Turns out, planning

is applicable in every single aspect of life.

Yes. Yeah. I know. It's like people are like, I gotta become a project manager. Brother, you already were. Oh, another thing I I like about with the planning things is that, like, you can have items that are blocked. Like, if your system is good, you could say this item is blocked by this item or this item is needed for this and then this and then this. And then, therefore, you're pretty much just given a straight list of, alright. Knock out this. Knock out this, knock out this, and then you just go down the list until it's all done. And it make to me, personally, it's motivating to to check stuff off, to say, okay. I got this done. Rah, rah, rah. Let's go. I'm 20% done. Let's go.

The dopamine hit from checking something off. Have you ever added something to your list just to check it off or added an an issue just to check it off? Oh, I did that all the time. Feels good. Yep. Record syntax. I'm adding it to my list right now so I can check it

out. I'm quite literally see what you got done. Yep. I think part of this too, you also have figure out what can be cut in here. And that's something I think that's important too because it depends on how hard this deadline is. Right?

Yeah. It's you have all these grand ideas of absolutely everything you'd like to have pnpm every single feature you'd like to implement.

But when it comes down to, is this worth my time? Like, are JS 1% of the users actually gonna be using this feature, and that's gonna push us back? Simply what can be Scott. And I think, like, we talk about all these, like, big AI companies shipping so fast right now. If you really look into a lot of these projects, you're realizing, like, the reason they are shipping so quickly is because it is it's not very polished, and a lot of the, like, features warp have been been totally cut. Right? Like, I remember when OpenAI launched their, like, apps SDK, which Wes, like, their, like, MCP thing. It was everyone's like, oh, wow. They released an SDK, and everybody's talking about it. And I was actually using it, and I was like, this is not very, like, done. You know? They they cut a lot of stuff, and that was simply just so they could announce the thing and say that they're coming out there before some other L. M. Company announces their own apps Wes. They needed to get something out in time because there was a tight deadline, and they figured out what can be cut, which was most of it. And they've since added those features in after the fact, but they needed it to get out in time. Yeah. Whatever happened to, you know, the, who's it? Miyamoto

from Nintendo said that a a bad game is bad forever.

And just basically I know I think it's, like, once we were able to update software after it was released, people just started shipping broken stuff. You know? Fix it in post.

Yeah. Fix it in post. Classic. Fix it in post. So you've made your plan. Node. I think sorry. I think there's, like, there's an upside to that as well as cutting things as well because Yeah. There's so many this is not a problem I have, but there are so many perfectionists out there that will simply just never ship anything. They'll never put their thing out there to the world because they wish that it was it was perfect.

And I think like, I was talking to my wife about this yesterday, just about some stuff that she's doing. And she's just like, I just wanna, like, sit down and make a plan and and do all this stuff.

And then also, a lot of she's she's not as as I'm not saying this JS her, but, like, a lot of people are also perfectionists on the other side of it as well. So you have this huge planning aspect, and you have this huge, like, perfectionist aspect. And then you have the actual doing the work in between, and then it it all just balloons and and nothing ever gets shipped. And, like, I am very much in the more in the middle Wes I I do some planning and I do some perfectionist polish, but my my I I I think the reason why I think I put so much stuff out there is because I I spend a bit more time on the middle, and that's both in a a positive and a negative.

Yeah. Yeah. Same thing. Yeah. Same for me. I I had a buddy. It was actually when I was in the music school, I had a buddy who, would like, over the course of, like, two years, released one song, and it was really good, Really good song. Yeah. And in that time, I probably released, like, 45 songs.

And I would say, you know, three of mine were good. Four or five, six of them were good, and the rest were bad. But, like, I think it's just different approaches. I've never been the perfectionist. I've been always a producer and, like, move on to the next one. The next one will be better with will gain skills or whatever.

Sometimes, though, you gotta be able to finish stuff, which is one thing I love this podcast. It forces me to finish something every single week. So next thing here is to get to work. You have your plan.

You have everything you need. You've uncovered any type of blocker or question that could possibly come up.

Now you can get to work, which is the thing that a lot of people just start with. I think the important things here are to not let your standards slip.

I think something that we've all encountered is a situation where we've taken a shortcut, and that shortcut has come back to bite us, and we have to spend time then undoing that shortcut.

I I I feel like there are some shortcuts that are calculated risks that do pay off. Yeah. But there are times when we take these shortcuts, and later you're just like, I should have just done it right the first time. I should have just authored this by hand, etcetera or whatever.

I it's so this is happening a lot more because it's so easy to just boop boop boop type in the Bos. Claude ships it.

And then before you know it, you're just like, why did I do that? Why did Or even just, like, why did I a lot of my open source stuff, I'm like, why did I merge this? You know? At the time, I was like, that's sweet. Yeah. Merge. And then I'm just like, now I have this big burden that I need to maintain and

Yeah. Should have done it. Yep. So have those standards in place. It's even better if your system that you have with your team, whether that's, you know, your linting and tests and whatever, it's even easier if those things are blocking your follies for you.

Because if if you can sidestep some of those systems or whatever and you can let your standards slip, but if you can't get something merged until you end up, fulfilling requirements, no any, no casting, whatever you end up doing, then, yeah, then then it's easy to just let those standards slip. And you can't you can't do that because that code then has to live there forever. Someone's gonna have to clean it up later or who knows?

Yeah. I don't know. I don't know if I I totally agree with that as Wes. Because, like, it at some points, I think it's fine to to let those things go, especially because, like, if you have too much process that's blocking you from actually shipping anything or doing anything, then it just becomes like, you just you have you foster this place where nobody actually moves quickly because you have just, like, too much, like, I I don't wanna do x, y, and z because now it's gonna take me a hundred years to just even get this thing running in local dev or or just like, like, the tests are flaky and they're failing. You know? And and that's probably more, a look on your actual,

your tooling as well. Your system. Yeah. Yes. One one thing again is to update your tools and issues as you go and communicate clearly. It's even better if your people who are monitoring your progress on this can monitor those things as Wes. So that way, they're not having to bother you. Where JS this at? What's going on? And it depends on what the deadline is. Is the deadline, you know, twelve hours from now? Is the deadline two weeks from now? I think communicating, early and often is always going to be better, but communicating clearly. I I really like having even, like, for projects like this, I like making change logs. I know that's not exactly a, rare practice, but I like having change logs that I could just give to a project manager to say, here's here's the updates as they're coming in, and that's Yeah. Commit names, conventional commits, or otherwise.

It's true. And even for yourself, like, updating your to dos, checking them off, that gives you those small wins make huge momentum.

And then you're, like, you're unstoppable. Like, when we were cranking on the Synhax platform and all the mad CSS stuff, It was just like we just had such a good flow of, like Mhmm. Bam. Log the issue. When something happens, log the issue. Somebody takes it. Somebody fixes it, pushes it. You know? Just.

Like, sometimes it's these some of these things were just so small that it would be, like, five, ten minutes in between Yeah. Pull requests. But, like, that was such a good flow rather than just like, I'm gonna work on it today and figure out what's wrong. It's just like, there's 80 things. I'm just doing one every 10 minutes for, like, twelve hours straight and get just crushing them, getting them done.

Yeah. Yeah. And and and then does like, that system, like, can be, it can be GitHub issues. It can be, like we said, like, linear to dos. It can be all kinds of stuff. Just something that you Yarn actually use. You know what I would actually really love, Wes? I would love, in regards to that dopamine hit, I would love something on my computer that just tells me how great of a job I'm doing every time I commit code. A back patter? Yeah. Great PR.

You can kill this. Nice job.

Unbelievable.

Vercel.

That's actually a great idea. You did it.

Oh, man. I would love that. How could we make that?

Yeah. It's gotta be hardware. You gotta build something that's hardware, like, three d printed that pats you on the back, and it's like pass, like, webhooks.

Yeah. All Wes passed.

Yeah.

Yeah. We gotta make that. Maybe four Unbelievable.

Hack week.

Unbelievable.

Week. Add it as a hack week project. Yeah.

I'm gonna do this now. Back pattern.

Yes.

Oh, yeah.

The height man. Yeah. You're so good at this.

Oh, that's great.

Claude could never do that. Yeah. Yes. Okay. I could just keep going forever on these folks.

Unbelievable. Yeah. Sometimes you have to ask for help. I don't know how many projects you've been in, Wes, but I've been in many projects where it's very clear that maybe not many, but I've been in enough projects where it's very clear that, like, there's just not enough manpower, in these two hands to, get this thing done. So I I've had to enlist the help of others. I've had others enlist the help of me. I remember one time Wes had I'll keep referencing stuff at Ford because it seemed like, something that had happened there a lot. But somebody was let go from our team, and there's three developers.

They this was actually very scary. We were in a meeting with Ford executives, and we each had three projects to work on. Each of us had Node. And the guy who went first presented the first day, and they tore his down so badly that he got let go that day. And then, the next guy was presenting the next day and then me.

And, the next guy and I, his name is Jeff, he and I were just like, because if if it would have been either of us going first, we probably would have gotten canned too because I think the expectations weren't made clear what they were actually looking for.

And so, Jeff and I spent all all night cranking this thing out, just all night, and and got it done and killed it. And, likewise, he helped me, and we we just made sure we we executed.

And we kept that job for a while. But, like, sometimes you gotta ask for help. It's just straight up. Sometimes ESLint for help can slow you down. If you have to onboard somebody, they gotta get, you know, set up with whatever the database is or keys or whatever.

Like, are you gonna Or if it's one of those nerd systems Wes everything. You know? Why are we not doing it this way? Please. Alright. In Node cases, I Wes, that's that's fine. Like, it's good to talk through choices, but

many other cases, just like, please, we're trying to get this done. We're not here to, like, debate, like, validation libraries. It depends on the timeline too. Right? If that timeline is twenty four hours or something, that's different than, like, a month.

But even then, yes, we're we're not here to debate. Hey. Can I get a handle on the a hand on this? Whatever.

I think a big thing is, like, knowing when that's going to help you and when that's going to hurt you is something that only you can know the dynamics of your team, everybody else's workload, what you have to do, what you need to accomplish. But I think the the clearest thing is asking for help in a way that it clearly communicates what you need. I think clear communication is a big topic here, but it's like, hey. I'm not gonna get this thing done. I really need help.

Is there any hours you can help to knock out the following features? If I assign you these GitHub issues, can you do them? To me, that is so much more powerful than, hey. Can you get a hand can you hand on this thing and just help me code it? Like, assign them issues, project manage a little bit, whatever.

Do these following things. Oh, which of these things do you wanna do? Which of these things can you do quickly, easily, whatever? And then let them get to work and accomplish that stuff. Let's talk about prevention because this is one that I think, some people will have a really hard time with because I know there Yarn some work environments where, of course, the management is not supportive or there is no

care Prevention of what? What are you what are you talking about here?

Prevention of crunch time.

Because a lot of the stuff with deadlines is almost always like, the stress around it isn't from having a deadline or from having something get done. It's feeling like you don't have enough time to get the thing done or you don't have enough,

capability to get the thing done in time. Right? Yeah. Quite honestly, this is sometimes just like a a person problem. You know? Like, I Yeah. Some of my kids, they have homework, and they just leave it to the last day before, and they're all stressed out about it. And it's like, we had a whole week. Like, whenever I did projects in school, I always tried to have it done one day before it was it was actually due. So you have that one buffer day in case anything goes wrong. And then I have all these friends that were, like, up at, like, four in the morning before it was due at eight just stressing out about it. It's like, just move your entire life twelve hours ahead, and you might be a little bit better off.

Yeah. I think so this JS there's two parts to this. Right? There's, as a manager, how do you make sure that people, do that? But then there's also JS the person who's under crunch time, Is it something that you can improve your process on, start earlier, plan better, and have a clear idea of what needs to get done? So that way, you're not scrambling at the last minute. That's number one. But let's say I've been in enough situations where, especially in the agency world, the design the developer is the last person at the end of the train. So, let's say in January, they declare that the project is going to be finished in March.

Okay? And that design will be finished, by the January, and then development can take from February to the March. Right? Well, design Node up going through several more revisions, and next thing you know, you don't even get to start development until March. And now you've got, like, half the time you were supposed to have to build the thing. So sometimes that process is unfair to the developer, especially if that is the last process in the in the chain here. So I think it is important to clearly communicate what you need with management in a way that isn't, like, angry or gonna put people in a defensive position.

But it's important to be honest and clear with your communication, especially if you're able to have those types of conversations, which, honestly, I feel like that is something that you should be able to establish.

I don't know. Developers are hard with this sometimes with communication. But, you could say things like, hey. I'd really prefer in the future if we had solid deadlines for x so that way I'm not getting crunched at the end. K? Or, to be cognizant of that. Right? Or a a better process in integration or collaboration would help me work faster with smoother results. Can we can we talk about, like, what that is? Right? Can we improve our process in these ways so the next time I'm not getting hit? Or, hey. If it's really bad, the last 10 projects have really ended in kind of chaos for me.

Is there any way we could work together to prevent that from happening? I mean, we all have the same you know, whether it's management or you, you all have the same goals, to get this done smoothly. And if it's not smooth, like, that's usually a fault of management, but you can help them with that, by clearly communicating what you need. Here's what I need, and can you help me with that? I think as

this maybe is a good thing with all this AI stuff right now Wes the dev is moving a little bit more up the chain into the planning stages in of the project, and and maybe the design is happening in in parallel.

And that that moves things along a a bit quicker because it it previously used to be, like, you have a project manager, and they figure out what they want, and then you just waterfall it all the way down. And then at the end of the day, the poor developer gets crunched. Right? And, like, I feel like the developer is is involved much earlier on these days, and in fact, may even be the person that's figuring it out at the in the first place.

Yeah. Yeah. And along with that, I think you can also set yourself up for success a little bit more to have time saving tricks here and there, like starter kits or or various, like, you know, decisions that you make that are automatic that, like, can lead to better results if you're you're moving faster. Granted, these are all things that vary greatly from team to team, work job to job. So, like, this is not blanket advice for everybody. But I think the number one piece of advice in in this regard is that communicate clearly what you need, because people just don't know. You can assume that people know what you need or don't need or think about or whatever, or you could assume that your boss isn't gonna listen to you anyways. But I think it's important to be very clear with what you need.

There's also the a situation of pure failure.

So you have a deadline.

That deadline is very obviously going to come and go, and there is 0% chance you're going to hit it. Right? I I think there's times when you can crunch it and you can get it Deno.

And and there's not I don't can't think of any instances in my career specifically where I haven't been able to deliver, but I know that things get delayed all the time.

So there are those situations where it's just straight up not possible.

Yeah.

So what can you do? Communicate earlier is better. Right? If it's the day it's due and you're saying it's not done, then this is Node. That's not gonna work for anybody. But if you can let people know a week ahead of time, a month ahead of time, two months, whatever, like, this is gonna be really tight. I'm going to crunch it. Here's my progress. Here's what's gonna happen.

It's gonna be tight. Then they can at least start preparing themselves mentally to make those decisions, but also preparing, you know, the client or the team or whoever JS next in the line to be able to be prepared for that kind type of of situation. But, again, communicating early and often is is the best practice here. Course correction

JS the, we like to say in the biz. You know? Just it's not like a total failure, but it's just, like, you're just constantly being correcting to figure out how you can hit the deadline. And it shouldn't happen where you're so far in at it.

We're not gonna make this. You know? You should have figured that out way sooner.

Yes. Yes.

All that all of the above there. And then, hopefully, again, if you if you have done the planning ahead of time, it should be a lot more obvious to you when it's not going to be possible. Because sometimes people don't realize it until it's too late. Mhmm. Like, I'm just gonna get it. It's gonna be fine. It's gonna be fine. Oh, crap. It's not gonna be fine. Like, that that could be a a major situation. So, yeah, just having a good handle on all that stuff is very important. I don't have anything else here, Wes. Do you have anything that we didn't get to? Nope.

Thank you so much. I just looked it up. The person who submitted this question was anonymous, so please, submit your Wes, syntax dot f m forward slash potluck. Thank you to Century. Check them out. Century.io/syntax.

Use coupon code Sanity treat, and that gets you two months free. If that's all we got, peace.