931: Project Init - How to Make Good Choices When Starting a New Coding Project

Scott and Wes dive into the fundamentals of project initialization and planning, from outlining ideas and choosing the right tools to making smart technology decisions. They also chat about leveraging AI and collaboration to shape better projects before rolling up your sleeves and getting to work. Show Notes 00:00 Welcome to Syntax! 02:12 Brought to you by Sentry.io. 04:03 Make a plan. 04:06 Start with an outline and let it evolve. 05:59 Mind-Mapping software vs plain text. 08:49 Utilizing LLMs for alternative perspectives. 09:58 Utilizing humans for alternative perspectives. 11:17 Making technology choices. 13:24 Assessing the project’s actual needs. 13:30 Is this a long-term project? 15:43 Is this project Open Source? 16:09 Are you working in a team? 18:12 Are you prioritizing learning? 19:48 Pick technologies with proven compatibility. 20:17 Implementing AI. 20:44 Steering docs. 26:24 Get to work and break stuff. Hit us up on Socials! Syntax: X Instagram Tiktok LinkedIn Threads Wes: X Instagram Tiktok LinkedIn Threads Scott: X Instagram Tiktok LinkedIn Threads Randy: X Instagram YouTube Threads

Speaker names marked ? are inferred from speaking time and the show’s known hosts — they are not voice-verified.

• 0:00Scott Tolinski?

  Welcome to Syntax. Today, we're talking about starting a new project and making good choices. It's not new year, new me. Yeah, making good choices. It's important. It's not new year, new me just yet, but it's never too late to start making good choices in the year. I am a recent convert to something known by most people as planning. And I'm gonna talk a little bit about planning of projects and how that can make you a better... Yeah, I know, it's actually crazy. I'm the worst planner in the world. And much to the chagrin of my wife, she thinks that my planning skills are abysmal. And I've been

• 0:43Scott Tolinski?

  trying to prove her wrong by actually planning things. And I'm sure that's just some kind of coordinated effort on her part to get me to actually plan. But I'm gonna do it anyways, because I'm like that. My name is Scott Zelinski. I'm a developer from Denver. With me as always is Wes Boss. What's up, Wes?

• 1:00Wes Bos?

  Hey, I'm excited to talk about this. I love starting a new project. And sometimes I do a little bit of planning and whatnot, and then I feel good about it. And sometimes I just frickin' YOLO it. And about, I don't know, a day or two into a project, I'm starting to have regrets. You know, that tattoo, no regrets?

• 1:20Scott Tolinski?

  Oh, I know all about it. Yeah. No regrets, for sure. Because dude, that happens to me more often than not when I just start get going. Especially when you're, like, if it's just like demos or whatever, that's fine. But the moment you bring a database into this world, then you got a deal. It's like, you got a database to take care of. Now you're writing migrations. Now you're changing the names of stuff. Sometimes you're just dumping the whole thing and starting over again. There's all kinds of things here that it can get really frustrating. And I'm here to tell you that I have seen the light for planning and planning projects in various ways to do that in a better way. My name is Scott Zelinski. I already said that.

• 2:03Wes Bos?

  You already said that. Let's get into it.

• 2:12Scott Tolinski?

  Let's talk about Sentry at Sentry.io. This is a great thing to have in your projects. You're starting a new project, slap Sentry in there. You can make sure that you're catching the things that you need to catch. Whether that is slow queries, whether that is errors in your application, whether you just want visibility and you tossing this out to some people and you're starting to give this to alpha users or beta users or real users.

• 2:37Wes Bos?

  Yeah, whether you've vibed coded a bunch of garbage and now you need to fix it all.

• 2:43Scott Tolinski?

  Yeah, you're gonna wanna know without having to be like, oh, what browser are you using? What happened when you clicked this? You got white screen? Uh, I don't know. Well, can you, let's hop on a call. Like, no, you can see all that stuff happen in real time. Uh, maybe not in real time. You can see all that happen in a video, scrub through it, get the errors, connect the logs, do all that stuff, solve your problems, write better code, use AI to do so if you would like. Check it out Sentry.io/center, sign up and get two months for free using coupon code TASTYTREAT. Let's talk about planning, Manapana Canal, Panama. Y'all know about that?

• 3:16Wes Bos?

  I know about the Panama Canal. I don't know what Manapana, Cana, what is that a saying?

• 3:22Scott Tolinski?

  Yeah, I think that was like, uh, I believe that was, was it President, uh, oh, man. I didn't know this until just Googling this. Apparently it is a palindrome, which I guess so it is.

• 3:35Wes Bos?

  Theodore Roosevelt.

• 3:36Scott Tolinski?

  Yeah, Theodore Roosevelt came up with this as like a, or I don't know if he came up with it, but he was, um, he's the one who, uh, popularized it as a way to sell the Panama Canal for people, like a nice little, you know, charge. At least that's what I believe. I could be making up history here. Either way, it's, it's a saying related to Panama Canal, but I'm just learning. I'm so blown away by this being a palindrome that I, I lost all train of thought. So, uh, let's talk about a plan. The best way to make a plan is to really just start with an outline. Uh, start with some descriptions. What is this thing you're building? Maybe even like a couple of high level, big paragraphs to say, hey, this thing I'm building is X and it's going to do this.

• 4:19Scott Tolinski?

  One thing that I found was that like, especially when you're building an app, this process of like, taking it from this vague idea, okay, I'm gonna build an app that shows an emoji when I'm smiling on camera. That's like, uh, that's, that's like a big idea. But then when you start to say, okay, well, this app will have user accounts. Users can see their past reactions. They, you know, then you start to think about what types of other interactions or the way it's going to be laid out. Just some high level stuff about this. You can just do it like kind of a bulleted point like outline. I think that works really well in terms of just getting some of your ideas on paper.

• 5:03Scott Tolinski?

  But as you work through this, you can start really high level and start to really distill things down into much more of like a pseudo code style of doing things because ultimately when we have a project, you're going to need most likely data structures. You're going to need most likely routing structures. You're going to need some like kind of logic or routes or access and roles and those types of things. So you can take this from these high level picture ideas and then break it down into what are the views this application will have? And I like to do this in kind of like a simplified pseudo code where I'll do like forward slash and build the routing structure.

• 5:48Scott Tolinski?

  It's nice to do this because it's just text in a text file. It's not actually routes. It's so much easier to change the routing structure when it's just text.

• 5:57Wes Bos?

  When it's just text.

• 5:58Scott Tolinski?

  Yeah.

• 5:59Wes Bos?

  Yeah, I'm a big fan of that as well. I tend to use mind mapping software as things get a little bit more complex. So mind mapping software is this idea where you have like a node and you can break that off into multiple nodes. And you can break that off into more nodes. And I find that to be a little bit nicer than just straight up text because text is very linear. And, and programming is not linear, right? There's things need to talk to each other and they need to, to split off. And if you can just throw a, and I also find just the way that my brain works, being able to spitball ideas and, and, and look at where it's at. I find that the visual map of a, a mind map is much more helpful.

• 6:41Wes Bos?

  And then also when it comes time to actually implementing it, I, I can get this like, oh, what do I work on next? You know, you're kind of scattered, but when there's a very clear like, all right, here's the database. Here's the authentication. Here's the access control. You can kind of just look at that one piece and, and chip away at that.

• 6:59Scott Tolinski?

  Yeah, you know, it's interesting for me. I prefer the linear nature of this because the moment it gets too much into like, really on this page, here's everything I can do, everywhere I can go, then I guess at that point I am getting a little too deep into it. But again, I do, I do like the aesthetic and visual of that. I feel like kind of been working off of this, and I'll post it here in the show notes. We can have it in the show notes. It's really simplified, kind of just like markdown approach to coming up with routes. What is the route? What can a user do? What can they see? When something is like just very basic kind of pseudo logic for different routes, you know, where they

• 7:44Scott Tolinski?

  can go, what they can do, those types of things. But also, I also kind of take an approach of like having a very simplified means of establishing data structures. So data is one of those things that as you work through this, you start to think of like, okay, what am I actually going to need in my database to accomplish this? And some people might just start with a schema, but I've always, I found it to be just generally useful to even establish some kind of your own general pseudo code for defining, you know, data structures, whether you just say, all right, what are we going to need for this thing? It's going to need a name. It's going to be a string. We're going to need

• 8:26Scott Tolinski?

  a URL. It's going to be a string, right? So real basic stuff that's not even just like code. It's, it's like, here's, here's the data structures, because you can have your routes, generally, you can have your data structures, you can have your sort of pseudo logic here, and you can have a high level of what this application does, who can do what? What is the logic? What is the access for these types of things? And if you build out this text-based version of this all, there's something really awesome that happens in modern web development here is that, man, LLMs are actually pretty good at this. So if I give it the context of what I'm trying to build, I give it the context of,

• 9:08Scott Tolinski?

  these are the views I have in mind, and this is the data structure I have in mind. And this is some of the general logic I have in mind. You can paste that into any LLM. And I'm not talking about using even like a IDE based cursor, Claude code, any of this stuff. I'm talking about just paste it into ChatGPT and say like, what am I missing here? Have I thought about everything? Because when I did this in my most recent iteration, it gave me some really interesting things that I hadn't thought of, like, well, perhaps you'll want this type of visibility toggle. And I'm thinking, I don't need that. And then you think about it for a couple of minutes, you're like, actually, it'd be nice to have now in the database so that I don't have to add it later if I actually want it and then have to account for it not being there.

• 9:53Scott Tolinski?

  So it can really add some robustness to your data plans and it can get you going back and forth.

• 9:59Wes Bos?

  It's the same thing when you like just talk something through with a coworker as well. Right? There's, there's things that you may not have thought about, or there are approaches that you were thinking, which is totally the wrong way to go about it. And hashing that out earlier is, is better. Like I talked a couple of episodes ago, how I was just like, I was, I don't know, like a couple of hours in on coding something and I realized this is not, this is not the best approach after talking to somebody that are like, yeah, you could fix that. But like, like, why are you even doing this way at first? And I kind of wish I had hashed that out much earlier before I actually cut my teeth in the code.

• 10:38Scott Tolinski?

  Yeah, totally. Hashing this stuff out in your brain can really, really help. But also, you know, pasting it into an LLM, they might give you a bunch of stuff that you don't need. But I want to be clear, this is not like vibe coding here. This is like, you are crafting this thing and then you are using AI to solidify it, to make sure you're not forgetting things, to, you know, it might not be perfect at the end of the day, but to really lock in. And what I don't suggest is just copying it straight from the AI saying, all right, this is what they gave me, this is what I'll use. You think critically and say, all right, is this something I want, whatever? So you've got your high level plan. Let's talk about picking tech.

• 11:19Scott Tolinski?

  What tech choices can you make that are actually a good choice for this project? I am so guilty of just picking the shit that I want to pick and not considering if it's even good for the project I'm building.

• 11:34Wes Bos?

  Yeah, man, the thing that always gets me with the tech is a database. I always want something that is as fast as possible because usually when I'm building something, I get to a point where I'm thinking, now's the point where I want to save something.

• 11:50Scott Tolinski?

  Yes.

• 11:51Wes Bos?

  And then I was like, I don't want to do a whole schema and spin up the database and whatnot. And SQLite has made that a lot easier for me, but still, it's a bit of a bit of a pain. But I don't know, that's usually that's usually like the hang up for me.

• 12:09Scott Tolinski?

  I'll tell you where I've gotten some smoothness here is in general, if you've written out the kind of ideas for the data structures you have and you have that pseudo code going, I have found AI being very good at that to just dump it into an ORM language. Sometimes it doesn't have the most modern Drizzle syntax or whatever, but you can get that pseudo code into database schemas in two seconds flat, confirm that it works. And then if you already have a good flow with Drizzle setup, man, all you need is a dang Postgres or whatever URL. And then, you know, one thing that Drizzle added was the like push command, which means you don't have to generate migrations, you just push

• 12:53Scott Tolinski?

  the changes for when you're first starting a project. And that to me, that flow is just like, all right, I'm going to get this going. I got my connection string. I made it with Tables Plus or whatever. I'm going to click, push up, and then I have my database.

• 13:06Wes Bos?

  Yeah, if you don't have any like production stuff yet, or you don't necessarily care about any of the data in that database just yet, you can just do that. And then like later, once you start having actual users and data you care about, that's when you dip into the migrations.

• 13:20Scott Tolinski?

  Yeah, yeah, exactly. And once things are a bit more solidified. So let's talk about picking tech. This is a what type of project? That's the question you got to ask yourself. Is this a long-term project? Is this a project that is going to need robustness? A lot of people working on it, or you're going to be working on it. You want to make money on it. You want it to exist for a long time. If it's a long-term project, you're going to make solid, established choices like pick stuff that is not going anywhere. You know, pick stuff that you can host anywhere. Pick stuff that you know possibly others can work in or that are going to work well with the thing you're trying to build.

• 14:01Scott Tolinski?

  So like, let's say you're building an application that will never, that needs like an online connection all the time. We're going on like a local first flow. Like, yeah, sure, that can be beneficial if you're going for speed, but it doesn't like if it doesn't, the app doesn't need it, it doesn't need it. Like know what the app needs and go from there. Does this thing actually like work best in a CMS type of context? Build on the dang CMS. Like, don't write your own for this. Like know what you're building and why and make choices that fit the long-term goals of this project.

• 14:35Wes Bos?

  Yeah, in most cases, choose tech that will solve your problems, not the other way around.

• 14:41Scott Tolinski?

  Yes.

• 14:42Wes Bos?

  I'm maybe guilty of this just because I want to try stuff out, you know, but I guess it's also good to, to, to just grab new tech just for the sake of trying it. But it's always a delicate balance. I agree. It's more of like a learning project, right? And if it's a little bit of a lower stakes project, I will try to go out of my way to, to try two or three new things, you know? Maybe I'll try some of the new local first stuff that we've been talking about. Maybe I'm going to not use React on something and I'll pick up. Maybe I want to try some of the new Svelte stuff that's out. That's a good, good time to, to learn something.

• 15:23Scott Tolinski?

  Yeah, I'm all about learning things. And so I certainly don't mind picking one or two little new things and any project that I'm trying to either do fast or work on for a long, I don't mind doing that. But like, if the goal of the project isn't straight up just learning, I'm only picking like a few little new things that I know are probably good choices. Is this project going to be open source? If it is, you're going to want to use things that possibly others will know. Now, you want to be picking things that you know really well, if you're the main author on it, but like picking some obscure libraries in addition to something, or even picking a lot of libraries if you're, you're doing like an open source project that other people might be using. So you have to make these choices knowing

• 16:07Scott Tolinski?

  like what the context this thing will exist in. If you're in a team, like, I, I made a, I'm gonna say this right now, a dumb ass choice. When we, we had our syntax site, I wrote a preheating script for it to like seed the database and give it, I wrote it in Rust. Why? I felt like it. I wanted to. And then ended up being a giant pain in the ass because now nobody else can work on it. Nobody else knows Rust or they gotta build it. And it's like, I ended up rewriting it in Node because it's like, why did I make that choice? That was such a selfish, bad choice. So like, really just consider the team, their skills, what's going to be smooth for everyone to work on.

• 16:45Wes Bos?

  Yeah, man, I have that so many times in my house where you, you build something like I, I went out of my way to, to make this whole charging infrastructure for our families, like iPads and whatnot. And, and the kids kept snapping all the, the cords. So I got these like magnetic charging cords and whatnot. And I, it was beautiful, right? We had like six magnetic charging cords. They were all perfectly in, in a line. And all they had to do is slot their iPad in and click, and then put their headphones on the hook and click, and the things were charging. And then like three weeks later, it's a rat's nest. The kids have pulled the thing, the little magnet chargers out of it because

• 17:28Wes Bos?

  they can't find the right one. And it's just absolute nightmare. Kids are going into my bedroom to use our charger because I can't find the right one. And I'm just like,

• 17:37Scott Tolinski?

  Who did you make it for? Did you make it for you?

• 17:40Wes Bos?

  I made it for me because it's just like, it's not, I guess it wasn't the right amount of usability. And when things like that happen, like you see this with GitHub Actions as well, right? People just ignore when a GitHub Action will fail because it's just like, I don't know. It just is half the time it fails and I can't, can't fuss with it and screw it, you know? So drives me nuts, but like if things are not usable enough for the people you make them for, they're not going to end up using them. They're just gonna go around it.

• 18:11Scott Tolinski?

  Yeah, that's so true. Uh, learning, if you're picking this project specifically to learn, pick a bunch of things that you want to learn, but don't pick too many things because there's nothing more of a killer to learning than hitting some kind of road bump that you can't get past in how these new technologies connect to each other. Cause it's like the connection between new things that you've never worked before, that usually you find yourself in trouble. So like, for instance, I was trying to pick up Better Off at the same time I was trying to pick up Live View and Ans felt with their new

• 18:54Scott Tolinski?

  stuff, but I wasn't actually using that stuff. And I've worked with Better Off, but not the way that I had been planning on connecting it to Live View. And I had never worked with Live View at all or with Svelte. So I had to figure out how this works with this and then this works with like that, that bit, once something went wrong, I was like, I don't even know who's at fault here. I mean, I'm at fault, but I don't know.

• 19:20Wes Bos?

  The only person in the world who is combining those things and you're kind of up a creek, figuring it out yourself.

• 19:27Scott Tolinski?

  And then guess what? I quit the dang project. So you know, it's like that, that's ultimately where it stops. And then what happens? You don't learn. So pick enough things that like it's, you're actually learning, you're actually picking things up, you're actually using that time wisely, but don't pick too many things that are too mysterious that you're going to find yourself in a place where you're at a dead end. Also, pick things that work well together. Don't pick a bunch of assorted technologies that you have no idea if they do work well together. Or like, again, like I'm going to pick. I'm not saying this is the case, but I'm gonna pick a new library like LiveView or whatever. And then I'm gonna pair it with Svelte because I like Svelte, but there's no bindings for it.

• 20:08Scott Tolinski?

  So now I'm writing my own bindings. Next thing you know, I gotta be responsible for those bindings and those bindings don't work. And I gotta get deep in like, pick things that work well together. Yeah.

• 20:17Wes Bos?

  Let's talk about AI because one interesting bit about using AI to build these products is, is your planning is so much more important, your documentation for how things work and what you want to do is so much more important than, than actually than I think than it used to be because you need to be able to give the AI something. So what do you got here for the AI part of this?

• 20:45Scott Tolinski?

  Yeah, it's actually funny because Kiro is one of the reasons, Kiro, the new editor ID from Amazon. And I'm not actually even currently using Kiro right now. I'm currently using VS Code again. I, Kiro is one of the things that like really solidified some of this stuff for me. Kiro has a really great way of creating steering documents for your product. And I think this is really super a good idea on things that you're working. Now Kiro generates these for you. So this is generated. Let's see, the project and structure, it can generate several different types of steering documents, whether it is the product itself, you know, the entire application, what the thing is,

• 21:28Scott Tolinski?

  what it is and what's its purpose, the structured document that's going to show the directory structure, like what the files are doing and where to find things. You might think that this is something that the AI can just glean from looking at your project. But sometimes these projects don't contain all of the information that you would want them to contain. You're starting fresh. Like I couldn't even tell you how many times it's like the AI is like, well, let me just create this inside of your source folder, this components folder. And let me dump some random ass components in here instead of like putting them in the structured way that you'd want to have them. So these steering docks can actually lead you to have much better structures so that it knows

• 22:10Scott Tolinski?

  where to put things, can save you a lot of time. This is if you're working with AI while you're coding. And likewise, same thing, tech choices, what tech choices you're using and why. Now, again, these are generated by AI and they can do a good job of generating these stocks, but they really need your hand to be effective. Because otherwise, AI will lean towards the solution that it finds the most, and therefore it's going to try to shoehorn that into your project. And if you have clearly established guidelines on this is what you want to use, when you want to use it, and what you want to use it for, then it's going to do much, much less of that. I've even found, I don't know if you've found this, in VS Code, I've found that

• 22:53Scott Tolinski?

  even including the MCP tools that I want to use, like use context seven to pull the latest version of the docs and like telling it that in the steering docks, I have found that to be effective. I don't know if it is, or if it's just like, it's going to use context seven anyways, but like I found it to be effective. Yeah.

• 23:10Wes Bos?

  Yeah, Cursor now has this thing called Memories where it will watch your chat for things that you told it, and it will try to remember that, similar to how like you would think of that ahead of time and throw that in a rules file. But now, like I'm just looking at what my memories were of, it's hilarious thing to call it, but like, it will just watch your chat. And it says, "The user prefers that the assistant not start development server automatically as they will run it themselves." That's one annoying thing that kept doing, but like, "All right, let's start the server now." And I'm already doing that in the, in the thing. And then there one says, "The user prefers React code to be organized as proper React project with separate component files and shared code. Avoid using template strings in striving for a clean and

• 23:52Wes Bos?

  perfect implementation." That wasn't a very good one. And then it's also suggesting another one now, "The user prefers front-end specific authentication logic be moved directly to the file where it is used and not to share backend in front of it." This is, we're going to be recording this episode next, which is hilarious. Essentially says, "Don't, don't put your backend off in the same file that's loaded into your frontend application." No shit.

• 24:18Scott Tolinski?

  Oh, yeah. Oh, I should. Huh. Okay. No bugs, please. Yeah.

• 24:22Wes Bos?

  Yeah.

• 24:23Scott Tolinski?

  This user prefers if I don't write bugs that, you know,

• 24:27Wes Bos?

  Yeah.

• 24:28Scott Tolinski?

  Release the IDs of several people. You know what? That that's starting a dev server is something that Kiro really loves to do. And I like started on VS Code because they have some like new to do structure inside of their chat and some like really interesting things that are in the new VS Code stuff. And I was just getting used to it and I was like, oh, I'm I'm so happy that it's not going to constantly like every single 10 minutes ask me for my dev server or try to start a dev server.

• 24:56Wes Bos?

  That

• 24:57Scott Tolinski?

  And it does.

• 24:57Wes Bos?

  Integration needs to be better because like even if I I use, I've been trying to use like the built in terminal to VS Code or Cursor lately and it feels like it it forgets about that. It's running it already sometimes.

• 25:10Scott Tolinski?

  Forgets that it's running it.

• 25:12Wes Bos?

  Yeah.

• 25:12Scott Tolinski?

  It like requires authentication to get to the point where you're you're getting to it can't find it anyways because it's not doesn't have the credentials or whatever. There's so many darn if issues with it. It works in like a very, very small subset of applications that I've found. So annoying.

• 25:28Wes Bos?

  One thing I'm really excited about is for the new TypeScript language server that's written in Go to make its way into to be a default because

• 25:37Scott Tolinski?

  Yeah.

• 25:38Wes Bos?

  Often the AI will will try to run like a TSC on my entire code base to make sure there's no type errors across the entire project and it drives me nuts because

• 25:47Scott Tolinski?

  Same.

• 25:47Wes Bos?

  You can turn on like TypeScript checking for your entire project. It's like a it's an experimental setting in your editor. But like it's it can be very slow, right? Because it's it's running it. But now that we have the new like the 10 times faster TypeScript TSC or the other one that's coming, you're going to be able to type check your entire project like on Keyup or something crazy like that. And then it's going to know, all right, well, it's one change here. Does that ripple through and make any other type errors throughout your entire project?

• 26:21Scott Tolinski?

  Yeah, yeah, no kidding. All right. That's all some tips I have here. Last part is get to darn work. Get to work. You're gonna find things that your planning could not have planned for. That just, that's just how it is. One thing that I've found to be good again is like using AI to transpose some of your pseudo code into real code. It depends on what it is. It works especially well for like pseudo database structures and ORMs, right? Because that's like a really easy transition for that to make. It's really just like modifying syntax. I find it less to be good with UI stuff, mostly because I'm very particular about my UI code. I'm very particular about my CSS. I like almost never want AI writing CSS

• 27:01Scott Tolinski?

  anymore. I found it to be very abysmal. But LLMs are good at converting things that would could be done through a really fancy transform. So use that where possible. Another thing I do is I take the skeleton of the routing structure and things like that. And before I write any code, I just build out that entire structure exactly how I planned it out. You build out the structure, you create the route files, and inside of those route files, I paste in my pseudo logic that I had thought of. I paste in the things that I need to do in that file, the things that why this file exists, etc., etc. And that way, when I come to it later, I see exactly what I'm supposed to be accomplishing in this file. And you're gonna come up with things along the way. That's not the point. Even as I go through

• 27:46Scott Tolinski?

  things like that and I start actually writing real code, which, you know, I'm doing by hand, I, or I guess with the help of an LLM, you leave to-dos in here for you to come back and later like, oh, I didn't think about this to do. I gotta think about this when I re-approach this. Or let's say there's a function you can't implement right now. Just drop it, write the function and drop a to-do in that function. I'm talking about just getting going on a project or things like that. Now, obviously, if you're the type of person who's working in a big team with a lot of people, this is going to be an established project, you can come up with this workflow and getting started. But I like having a skeleton and I'm often working by myself. So for me, these things work really well.

• 28:26Wes Bos?

  Yeah.

• 28:27Scott Tolinski?

  And I'm also, I gotta say, I'm new to planning. So if you think any of this sounds like a bad idea, it sounds so stupid.

• 28:33Wes Bos?

  The comments on this guy be like, like Scott discovers planning. It's gonna be good.

• 28:39Scott Tolinski?

  That is, yeah, that is so correct. I honestly, this weekend, I was planning these things and I was doing all these planning. I'm like, oh, actually pretty good. This is pretty cool, you know?

• 28:50Wes Bos?

  Yeah, I need to do that for dinner. Man, it drives my wife crazy. She's like, what's for dinner? I was like, it's like 5:07. I was like, I'm gonna open the fridge and just kinda look for stuff. And also drives me nuts as well, so.

• 29:03Scott Tolinski?

  Yeah, I get, I get bad anxiety about that because I, I don't cook most of the nights. In fact, um, we're lucky if I cook once a week.

• 29:11Wes Bos?

  Okay.

• 29:12Scott Tolinski?

  But anytime Courtney's like, oh, you're cooking tonight. I'm like, oh, what am I making? And I have enough things that I can make, but I like, I just, everything goes blank at that moment.

• 29:23Wes Bos?

  Oh, yeah. I can't, I, I can't plan that either. Same with the grocery shopping. Like I, I can't have a list either. It drives me nuts. I just need to bounce around and pick up stuff that looks good.

• 29:34Scott Tolinski?

  You know what? I, we used to live a block away from Whole Foods, like a block. And it was so nice because you'd be like, what am I making today? I don't know, maybe go walk to Whole Foods and pick out some stuff. And it's like moving away from that Whole Foods was all of a sudden like, oh, man, now I gotta like actually know what I'm making. And if I forget something, I gotta get in the car. Yeah. All right. So we are knee deep in hack week over here, which is why we're talking about projects. We will catch you in the next episode. We're going to be talking about some AI stuff. It's going to be a lot of fun and we'll catch you in the next one. If you enjoyed this show, leave a comment below.

• 30:16Scott Tolinski?

  Smash that subscribe button, tell your friends, all those things. We're on YouTube, folks, and these, uh, these video episodes are really nice and fun on YouTube. So if you're only an audio listener, give us a try on, on video on Spotify too. So if you're a Spotify fan, also do video over there. Check us out, Syntax FM on YouTube. As always, we'll catch you in the next one. Peace.