Managing Deadlines + Stress

Welcome to Syntax. We got an amazing question in our inbox all about how do you deal with the stress of meeting a hard deadline when you're behind on work and tickets are coming in. And we're going to 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 Tinsky. I'm a developer from Denver. With me as always is West Boss. 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 a 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, uh I I got to say I feel like I've run the gamut on fastmoving projects, hard deadlines, things that need to get done. And I feel like I have some good advice here, but also like you know We just did this MAD CSS thing that was a whole team project, right? Our whole MAD CSS tournament. And we said, we're going to do this to coincide with March Madness, which that's a hard deadline uh 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 West, you built a bracket site. Uh we had merch, we had all these needs and stuff like that. Yeah, it sneaks up so quick. It's It's unbelievable. But also, I almost prefer a hard deadline like that because it is so easy to say, "Ah, we'll push it to next week, you know, and then things never get done." And you look at some of these companies like Anthropic and Open AI and whatever just shipping like crazy right now. And you have to think like, man, first those people are probably not getting good sleeps. Um, 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 and whatever to move at the speed that they are. Yeah. You know, it is funny to hear like uh 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 got to 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 is 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 uh got it done in the time that was acquired or allotted for this. So, um, what can happen if you're under a tight deadline? Well, magic can happen as you said, right? You can get stuff done, but you can also have mistakes. You can have costly mistakes, stakes that end up being what they're security holes or something like that because you're just trying to get this thing done. Uh, maybe you end up having, you know, a lovable sized hole where you have all of your customers public chats public. Who knows, 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 they it was announced that their it 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 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. That should not 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, uh, you know, costly mistakes. What do you do? How do you prevent this? Uh, 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 uh 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 going to be helpful." No time to plan and slow down. And it's it's the right call every time. It's just like when they say deep breathing is the best thing for you and you're just like, I don't want to deep breathe. Let me deep breathe. Uh it always works, folks. The stuff that always works is always no fun to do. But yeah, slow down. Uh, I think the biggest thing you can do here is take stock of what actually needs to get or what's actually done currently and what's not. Um, 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 uh what the lay of the land is. Take a step back. Here's what exists. And that could be using something like like linear or some sort of like issue tracking system. Um some conbon 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 I always say out of your head into your system. And as long once it's there, you can you can go, okay, at least at least I see what needs to be done and I can 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 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 um so making making a plan at this point like you said out of your head into your system is the most impactful thing you can do for yourself and I'm an optimistic person by nature. So, it's and Wes, you know this from working with me, I often just think, well, it'll get done, you know. Uh, 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 is uncover questions you might have about the spec or needs. 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 going to work? Um h 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 going to 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 uh 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 this spec or whatever it is or you're you're going over in your head, maybe you're writing your own uh spec 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 um over to the syntax domain name and seems easy enough on the on the Yeah. Yeah. Throw it on a subdomain but it ended up being like it has to be on Cloudflare workers. So but shoot 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 and I don't have access to your Yeah, you don't have my access. 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 got to find them and they got to they got to figure out who has log into that and then they got to update the name servers. Um and then we move that over. Oh, now the the app is failing because um the free plan on Cloudflare only gives you 10 milliseconds per request and and we needed the like 40 milliseconds because we're going just going over it and they were failing. Oh, now we got to 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 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 and comments and then fill in the code into those comments later. So, for me, this is kind of like that where you're like the to-do. Yeah, it's the same way that people write an outline before writing, I suppose. I'm a terrible author, writer. 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 got to 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 uh if your system is good, you can 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 all right, knock out this, knock out this, knock out this, and then you just go down the list until it's all done. And it makes to me personally, it's motivating to to check stuff off, to say, "Okay, I got this done. Rah rah, let's go. I'm 20% done. Let's go." Uh, does the dopamine hit from checking something off? Have you ever added something to your list just to check it off or added an issue just to check it off? All I do that all the time. Feels good. Yeah. Record syntax. I'm adding it to my list right now so I can check it off. 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 and every single feature you'd like to implement. Um but when it comes down to is this worth my time? Um like are is 1% of the users actually going to be using this feature and that's going to push us back? um simply what can be cut. 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 have been been totally cut, right? Like I remember when OpenAI launched their like apps SDK which was like their like MCP thing. It was everyone was 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 LLM company announces their own apps SDA. 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. Um, 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 uh who is it? Miiamoto 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 I think sorry I think there's like there's an upside to that as well as cutting things as well because 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. Um, and I think like I was talking to my wife about this yesterday just about some stuff that she's doing and she's like I just want to like sit down and make a plan and and do all this stuff and then also a lot of she she's not as as I'm not saying this is 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 nothing ever gets shipped. And like I am very much in the more in the middle where 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 a positive and a negative. 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 uh with like over the course of like two years released one song and it was really good. Like really good song. And in that time I probably released like 45 songs. Uh and I would say uh you know three of mine were good. Uh 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 gain skills or whatever. Uh sometimes though, you got to be able to finish stuff, which is one of the reason 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. Uh I think the important things here are to not let your standards slip. Uh 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, etc. 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 box, Claude ships it and then before you know it, you've just like why did I do that? Or even just like why did 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 ah now I have this big burden that I need to maintain and should have done it. Yeah. 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 follys for you because if if you can sidestep some of those systems or whatever and you can let your standard slip, but if you can't get something merged until you end up uh 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 well because like it at some points I think it's fine to to let those things go. Especially cuz 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 uh I I don't want to do X Y and Z because now it's going to take me a hundred years to just even get this thing running in local dev or just like ah like the tests are flaky and they're failing you know and and that's probably more a look on your actual um your tooling as well, your system. Yeah. Uh 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 well. So that way they're not having to bother you. Where's this at? What's going on? Um and it depends on what the deadline is. Is the deadline, you know, 12 hours from now? Is the deadline 2 weeks from now? I think communicating um 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 um 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 commit names, conventional commits or otherwise. That's true. And even for yourself, like updating your to-dos, checking them off, that gives you those small wins make huge momentum. Um, and then you're like, you're unstoppable. Like when we were cranking on the Synhack platform and all the mad CSS stuff, it was just like we just had such a good flow of like Mhm. bam, log the issue. when something happens, log the issue, somebody takes it, somebody fixes it, pushes it, you know, just like sometimes it this some of these things were just so small that it would be like five 10 minutes in between uh pull requests, but like that was such a good flow rather than just like, hm, I'm going to 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 12 hours straight and get just crushing them, getting them done. Yeah. Yeah. And and and then does like that system like can be uh 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 all actually use. You know what I would actually really love, Wes? I would love on 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 backpack. Yeah. Great PR. You killed this. Nice job. Unbelievable. Yeah, that's actually a great idea. You did it. Oh man, I love that. How could we make that? Yeah, it's got to be hardware. You got to build something that's hardware like 3D printed that pats you on the back and it like has like web hooks. All test pass. Yeah, we got to make that maybe for Unbelievable hack week. Unbelievable. week. That is a half week project. Yeah. Can I do this? Back pattern. Yes. Oh, yeah. The hype man. Yeah. You're so good at this. Oh, that's great. Claude could never do that. Um, yes. Okay. I could just keep going forever on these. Yeah. Sometimes you have to ask for help. Uh 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 uh in these two hands to uh 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 we had I'll keep referencing stuff at Ford because this seemed like something that happened there a lot, but somebody was let go from our team and there was three developers. Uh 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 one 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 uh the next guy was presenting the next day and then me. Um and uh the next guy and I uh his name is Jeff. He and I were just like, uh, because if if it would have been either of us going first, we probably would have gotten can too because I think the expectations weren't made clear what they were actually looking for. And so, uh, 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 uh sometimes you got to ask for help. It's just straight up. Sometimes asking for help can slow you down. If you have to onboard somebody, they got to get you know set up with whatever the database is or keys or whatever. Like are you going to one of those system questioning everything? You know, why are we not doing it this way? Uh please. In some cases, I guess 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 debate like validation libraries. It depends on the timeline too, right? If that timeline is 24 hours or something, that's different than like a month. Uh but even then, yes, we're we're not here to debate. Hey, can I get a handle on that? A hand on this whatever. Uh 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 going to 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? Uh 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 it a little bit, whatever. do these following things. Oh, which of these things do you want to 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 uh some people will have a really hard time with because I know there are some work environments where of course the management is not supportive or there is no um care of what what are you what are you talking about here? Prevention of crunch time. Uh 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 uh 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 some of my kids, they have homework and they just leave it to the last day before and they're all stressed out about getting it's like, well, you 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 4 in the morning before it was due at 8 just stressing out about it. It's like just move your entire life 12 hours ahead and you might be a little bit better off. Yeah, I think so. This is there's two parts of this, right? There's as a manager, how do you make sure that people uh do that? But then there's also as the person who's under crunch time. Is it something that you can improve your process on? Start earlier, plan better, and have a clearer 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 uh let's say in January they declare that the project is going to be finished in March. Okay. And that design will be finished uh by the end of January and then development can take from February to the end of March. Right? Well, design ended up going through several more revisions and next thing you know, you don't even get to start development until March and now you 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 uh 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." Okay? Or uh 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 can 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 uh 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 uh by clearly communicate what you need. Here's what I need. Uh, and can you help me with that? I think as this maybe is a good thing with all this AI stuff right now where the dev is moving a little bit more up the chain into the planning stages and of the project. Um, and and maybe the design is happening in in parallel. Um, and that that moves things along a bit quicker because 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 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. Uh 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 going to listen to you anyways. But I think it's important to be very clear with what you need. Uh 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 done 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, man, that's just not that's not going to 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 going to be really tight. I'm going to crunch it. Here's my progress. Here's what's going to happen. It's going to 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 is next in the line to be able to be prepared for that kind type of of of situation. But again, communicating early and often is is the best practice here. course correction as the um 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 and you see we're not going to make this, you know, you should have figured that out way sooner. Yes. Yes. All that all of the above there. Um, 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. Like I'm just going to get it. It's going to be fine. It's going to be fine. Oh crap, it's not going to be fine. Like that that could be a major situation. So yeah, just having a good handle on all that stuff is very important. Um, I don't have anything else here. Wes, do you have anything that we didn't get to? Nope. Uh, thank you so much. I just looked it up. The person who submitted this question was anonymous, so please um submit your question. Syntax.fm/potluck. Thank you to Sentry. Check them out. centry.io/sintax. Use the coupon code tasty treat. That gets you two months free. Think that's all we got. Peace. Peace.