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

Welcome to Syntax. Today, we're talking about starting a new project and making good choices.

It's not new year, new me. Choices. 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 What? 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 of the chagrin of my wife, she thinks that my planning skills are abysmal, and I've been 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 a I'm a I'm like that. My name is Scott Tolinski. I'm a developer from Denver. With me, as always, is Wes Bos. What's up, Wes? Hey. I'm excited to talk about this. I

love starting a new project, and sometimes I do a little bit of planning and and whatnot, and then I feel good about it. And sometimes I about, I don't know, a day or two into a project, I'm starting to have ragrats. You Node, that tattoo, no ragrats.

Oh, I know all of that. Of those.

Yeah. No. And then no no regrets, for sure. Because, dude, that happens to me more often than not when I just start get going. And especially when you're like, if it's just the demos or whatever, that's fine. But the moment you bring a database into this world, then you Scott 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. Node the 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 Tolinski. I already said that. You already said that. Let's get into it.

Let's talk about Sanity @century.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 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're tossing this out to some people, and

you're you're starting to give this to alpha users or beta users or real real users. Yeah. Whether you pipe coated a bunch of garbage, and now you need to to fix it all.

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? I don't know. Well, can you can let's hop on a call. Like, no. You can see all that stuff happen in real time. 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. Century.i0/syntax.

Sign up to get two months for free using the coupon code Sanity treat. Let's talk about planning, Manapana Canal, Panama. Y'all know about that? I know about the the Panama Canal. I don't know what Manapana

can

what what is that a saying? Yeah. I think that Wes, like, I believe that was was that president, oh, man. I didn't know this until just googling this. Apparently, it is a palindrome, which I guess so. It is. Theodore Roosevelt. Yeah. Theodore Roosevelt came up with this as like a or I don't know if he came up with it, but he was, he's the one who, 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 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 I'm lost all train of thought. So, let's talk about a plan. The best way to make a plan is to really just start with an outline.

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. 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 a 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 Node? 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 in, 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. 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 gonna need, most likely data structures.

You're gonna Node, most likely, routing structures. You're gonna need some, like, kind of logic or routes or 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, pseudocode Node I'll do, like, forward slash and build the routing structure.

Yeah.

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 in a text file. Yeah. Yeah. 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.

Yeah. So mind mapping software is this idea where you have, like, a node, and you can break that off into multiple Node, 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 ESLint all 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. And then also Wes it comes time to actually implementing it, I I can get this, like, what do I work on next? You know? You're kind of scattered. But when there's a very clear, like, alright. Here's the database. Here's the authentication. Here's the access control. You can kinda just look at that one piece and and chip away at that.

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 I've, like, kind of been working off of this, and I'll I'll post it here in the, show notes so 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 can go, what they can do, those types of things.

But also I also kinda 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 I found it to be just generally useful to even establish some kind of your own general pseudocode for defining, you know, data structures, whether you just say, alright. What are we gonna need for this thing? It's gonna need a name. It's gonna be a string. We're gonna need a URL. It's gonna 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 Node.

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 JS 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, 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, cloud code, any of this stuff. I'm talking about just paste it into chat GPT 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 minutes, and 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 I have to account for it not being there. So it can really add some robustness

to your data plans, and and it can get you going back and forth. It's the same thing when you, like, just talk something through with a a coworker as well. Right? There's there's things that you may not have thought about, or there are approaches that you are thinking, which is totally the wrong way to go about it. And hashing that out earlier is is better. Like, I I talked a couple episodes ago how I was just like I Wes, I don't know, like, a couple hours in on coding something, and I realized this is not this is not the best approach. After talking to somebody, they're like Totally. Yeah. You could fix that, but, like like, why are you even doing it this way at first? And I kinda wish I had hashed that out much earlier before I actually cut my teeth in the code.

Yeah. Totally. Hashing this stuff out in your brain can really, really help. But, also, you know, pasting it into an Pnpm, they might give you a bunch of stuff that you don't need. But I wanna 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, alright. This is what they gave me. This is what I'll use. You think critically and say, alright. Is this something I want? Whatever. So you've got your high level plan.

Let's talk about picking tech.

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 wanna pick and not considering if it's even good for the project I'm building?

Yeah. Man, the 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 wanna save something. Yes. Right. And then I was like, I don't wanna do a whole schema and spin up the database and whatnot. And and SQLite has has made that a Scott easier for me, but still, it's it's a bit of a bit of a pain. But I don't know. That's that's usually that's usually, like, the the hang up for me. I'll tell you where I've gotten some,

smoothness here JS, in general, if you've written out the kind of ideas for the data structures you have and you have that pseudocode going Yeah. I have found AI being very good at that to just dump it into an ORM language.

Sometimes it 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 Vercel.

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, the changes for when you're first starting a project. And that, to me, that flow is just like, alright. I'm gonna get this going. I got my connection string. I made it with tables plus or whatever. I'm gonna click, push up, and then I have my database. 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 extra users and data you care about, that's when you dip into the migrations.

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 gotta 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 gonna be working on it, you wanna make money on it, you want it to exist for a long time. If it's a long term project, you're gonna make solid established choices, like pick stuff that is not going anywhere.

You Node? 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. So, like, let's say you're building an application that will never that needs, like, a 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. Yeah. In most cases, choose tech that will solve your problems, not the other way around.

Yes.

Yeah. I'm I'm maybe guilty of this just because I wanna try stuff out. Yeah. You know? But, I guess it's also good to to to just grab new tech just for the sake of trying it. But, I think that's a different email type of project.

I 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? Yes. 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 wanna try some of the new Svelte, stuff that's out. That's a good good time to to learn something.

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 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 are probably good choices. Is this project going to be open source? If it is, you're gonna wanna use things, that possibly others will know. Now you wanna 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, like, what the context this thing will exist in. If you're in a team, like, I I made a a I'm gonna say this right now, a dumbass choice.

When we we had our Syntax site, I wrote a preheating script for it to, like, seed the database and give 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 Scott, like, 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 that you're working in. Yeah. 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 Yeah. 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 cord. 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 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 Who did you make it for? Did you make it for you? I made it for me because it's just like it's not I I guess ESLint wasn't the the right amount of usability. And when things like that happen, it like, Wes you see this with GitHub actions as well. Right? People just ignore when a GitHub action will fail because they're just like it I don't know. It's just half the time it fails, and it I can't can't fuss with it and and screw it. You know? Yeah. So it drives me nuts, but, like, if things are not usable enough for the people you make them for, they're not gonna end up using them. They're just gonna go around it.

Yeah. That's so true.

Learning. If you're picking this project specifically to learn, pick a bunch of things that you wanna 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 because 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 BetterAuth. At the same time, I was trying to pick up Live View. And Sanity felt with their new, stuff, but I wasn't actually using that stuff. And I've worked with BetterAuth, 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 I mean, I'm at fault, but I don't know. The only person in the world who has combined those things, and you're you're kinda up a creek figuring it out yourself.

And then guess what? I quit the dinged 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 gonna 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 gonna pick, I'm not saying this is the case, but I'm gonna pick a new library like Live View or whatever, and then I'm gonna pair it with Svelte because I like Svelte, but there's no bindings for it. 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 deepened. Like, pick things that work well together. Yeah. 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 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?

Yeah. It's actually funny because, Curo is one of the reasons Curo, the new editor ID from Amazon.

And I I'm not actually even currently using Curo right now. I'm I'm currently using, Versus Code again. I Cura JS one of the things that, like, really solidified some of this stuff for me. Cura 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 JS 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, 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. 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. Mhmm. So these steering docs can actually lead you to have much better structures so that it knows 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 wanna use it for, then it's going to do much, much less of that. I've even found I don't know if the if you found this in Versus Node. I found that, even including the MCP tools that I want to use, like use contact seven to pull the latest version of the docs and, like, telling it that in the steering docs. I have found that to be effective. I don't know if it is or if it's just, like,

it's gonna use contact seven anyways, but, like, I found it to be effective. Yeah. Yeah. Cursor now has this thing called memories Wes 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 it like, I'm just looking at what my memories were of it's a hilarious thing to call it. But, like, it will it's it's 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. Be like, alright. Let's start the server Node. And I'm already doing that in the in the thing. And the other 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 and striving for a clean and perfect implementation. That wasn't a very good one. And then it's also suggesting another one Node. The user prefers front end specific authentication logic be moved directly to the file where it is used and not to share back end and front end. This is we're gonna be recording this episode now, which is hilarious. Essentially says, don't don't put your back end off in the same file that's loaded into your front end application. No

shit. Oh, yeah. Oh, I should Okay. No bugs, please. Yeah. Yeah. No bugs, please. If I don't, write bugs that, you know Yeah. Release the You gotta tell it that. Several people. You know, that that starting a dev server is something that Kira really loves to do. And I, like, started on Versus Node because they have some, like, new to do structure inside of their chat and Vercel, like, really interesting things that are in the new Versus Node, 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 ten minutes ask me for my dev server or try to start a dev server. That And it does

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

Forgets that it's running it. It 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

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 Yeah.

Often, the AI will will try to run, like, a TSC on my entire code Bos to make sure there's no type errors across the entire project. And it drives me nuts because Same. 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 gonna be able to type check your entire project, like, on key up or something crazy like that. And then it's gonna Node, alright. Well, this one change here, does that ripple through and make any other type errors throughout your entire project?

Yeah. Yeah. No kidding. Alright. That's 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 Node 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 at 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 anymore. I found it to be very abysmal.

But l LLMs are good at at 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 Node to do in that file, the things that why this file exists, etcetera, etcetera. And in 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 things like that and I start actually writing real code, which, you know, I'm doing by hand, I I or, I guess, with the help of an LLM, you you leave to dos in here for you to come back in later. Like, oh, I didn't think about this to do. I gotta think about this when I reapproach this. Or let's say there's a 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 on getting started. But I like having a skeleton, and I'm often working by myself. So for me, these things work really well.

Yeah. 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's not it sounds so stupid. Comments on this guy and be like like, Scott discovers

planning, it's gonna be good.

That is that is so correct. I I honestly, I 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?

Yeah. Which I need to do that for dinner, man. My it drives my wife crazy. She says, what's for dinner? I was like, it's, like, five zero seven. I was like, I'm gonna open the fridge and just kinda look for stuff,

and also tries meat nuts as well. So Yeah. I get I get that anxiety about that because I I I don't cook most of the nights. In fact, I'm, we're lucky if I cook once a week.

Okay. 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. Oh, yeah. I can't I I can't plan that either. You say 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. 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. I need to 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.

Alright. 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 gonna be talking about some AI stuff. It's gonna be a lot of fun, and we'll catch you in the next one. If you enjoyed this show, leave a comment below. Smash that subscribe button. Tell your friends. All those things. We're on YouTube, folks, and these, these video episodes are 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 Scott. Syntax FM on YouTube. As always, we'll catch you in the next one.

Peace.