889: Planning A Build

Scott and Wes talk about the planning process for a major redesign of the Syntax.fm website. They share their thoughts on organizing tasks, choosing tech, handling styling, and the debates that come with deciding what to keep and what to change. Show Notes 00:00 Welcome to Syntax! 01:36 Brought to you by Sentry.io. 02:48 Why we need version 3.0 of Syntax.fm. Level Up Tutorials, Travis Neilson. 04:41 Project planning and organization. 05:53 The codebase. 09:50 The CSS changes. Episode 770: Design Systems With Brad Frost. 12:27 Tooling. 15:54 Development process. 16:38 Mobile and responsiveness. 18:37 Saving VS Code extension into the repo. 19:56 Using a dev container. 20:53 AI agent rules. 21:35 Code styles. 23:42 Canadian podcast. 24:33 Content storage. 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 going to be talking about what you should be thinking about when planning or starting a new build or a new project. The Syntax team is going to be developing the third version of the Syntax site really soon. It was designed by a good friend of mine, designer Travis Nielsen, and we have the site design. We're ready to go. So just yesterday, we sat down and came up with a big old list and a whole bunch of things about what we need to accomplish, like who's going to do what, how we're going to organize things, decisions we're going to make about this codebase, and we're going to be talking all about that in this episode. My name is Scott Tolinski. I'm a developer

• 0:42Scott Tolinski?

  from Denver, Colorado. With me as always is Wes Boss. What's up, Wes?

• 0:46Wes Bos?

  Yeah, it's kind of interesting one because when you have either a new build or you have a major rewrite or redesign, there's some like decisions that need to be made, right? And especially for like me, you and CJ, there's a lot, we use a lot of different tech. We try absolutely everything. So it's kind of important to sort of sit down and say, all right, what are we going to use? What are we, what are we sticking with? What are we changing? Sort of asking those questions of like, how do we tackle this? Otherwise, we're going to be mashing all kinds of different approaches and styles and whatnot together, and it doesn't, doesn't become a good thing. So I think this is a pretty common thing

• 1:31Wes Bos?

  that hits teams that need to do a redesign. So I thought it'd be a cool episode.

• 1:35Scott Tolinski?

  Yeah, totally. And one of those decisions we made, obviously Wes, is to use Sentry because, one, we already have it in the codebase, so we're not going to get rid of it now. But two, last time when we launched the V2 version of Syntax, Sentry was like pretty instrumental in making sure that after we launched, that this thing was actually as good as it felt on our machines because we got fast internet, we got big pipes, and because of that, everything seems super good on our own local machines. But you don't know how other people are experiencing the website, experiencing When they click on something, what happens? How slow is it? How fast is it? All that stuff. And with Sentry, you can determine not only if your website's actually up.

• 2:18Scott Tolinski?

  Maybe we wrote some code that crashed it and it went down or it's having a hard time for some people. But we can also even get how fast it is for the users, which pages are slow, which database queries are bad, where the errors are, all of these things that are instrumental in making sure that you ship something good. So if you want to ship something good, like we're about to, we're about to ship something good. I don't know if you sentry.io forward slash syntax, use the coupon code TASTYTREAT, all lowercase, all one word, and get two months of Sentry for free. So Wes, let's talk about when we, we got this design, we've been working on this design project. And in the past, the first syntax site, you just went off and Yolo'd it in like 24 hours.

• 3:02Wes Bos?

  Yeah.

• 3:02Scott Tolinski?

  The, the second syntax site, I put together a very structural design. It was very, here's the structure. It had no, no seasoning, no, no flavor. And then you came in and were like tossing spices on and whatever. And it ended up looking the way it looks now because of the design flair you've added. With this third design, you know, it's kind of a shift in, in the way that syntax has grown. And it needed to have some new features and some new things that the current website, which is for all intents and purposes, a podcasts website. We needed some, some big rethinking of it. So that's why we went with Travis.

• 3:43Wes Bos?

  Architecture, meaning that like we have many different kinds of content, right? We want to be able to do text content. We have video content, audio content. And when you have so much stuff, how you experience it is a whole nother level of design. It's, it's past just making it look good. It's how does somebody experience this? And Travis did an awesome job. And now we're sitting here looking at these designs and we're like, all right, well, how do we now take our site, which we'll talk about what the tech stack is right in a second? How do we now move that into this design without it being? Too much of a cludge and also too much of a like major, major shift where it will never get finished, you know?

• 4:26Scott Tolinski?

  Yeah, totally. And so, yeah, we, we went outside help. We had all these meetings. We tweaked it. We did all this stuff. We worked with, I worked with Travis before on the Level Up redesign. So levelup.video, I knew he'd do a great job. And so because of that, after this project is done, we're, we've got the design comps. We're sitting down and I think to me, the first thing that needs to be discussed is like project management organization, even before you get into the code. How are we keeping track of tasks and issues and those types of things? And so we ended up deciding on using the project features, the Kanban boards and GitHub specifically. We're developers, all three of us working on it. We're on GitHub.

• 5:10Scott Tolinski?

  We don't have any project managers or people who are non-developers going to be keeping track of tasks in this build.

• 5:17Wes Bos?

  The day I use Jira to, to build a website is, is the day I'm, I'm done web development. So I was happy that like, we're not, I don't, I don't want to spend a whole bunch of time just like managing the, the management of this type of thing. I want to be able to grab an issue, take a look at what's on, tear something off that's small enough, put the pull request in, move on to the next thing.

• 5:40Scott Tolinski?

  Yeah, totally. Yeah. So because of that, that GitHub features feel really nice to use for that. We can keep track of everything there. So that's what we decided on. Again, it makes a lot of sense for, for us. Next, we wanted to talk about like the code base itself. The current site is built in SvelteKit. It's a big old site. There's a lot of stuff there. So what do we do? Do we keep that code base? Do we start over? Do we put it in a, put it in a folder and then bring in what we want? We decided that ultimately we didn't want to lose our routing structure. We didn't want to lose our Git history on files. And so because of that, we're going to keep like pretty much most of the same code base,

• 6:23Scott Tolinski?

  but we're gonna, we're gonna start filleting and deboning the CSS out of that thing. We're essentially just ripping out the CSS and going to be keeping a large part of the general structure, a lot of queries, the, the routing structure, those types of things.

• 6:39Wes Bos?

  It's always hard with a codebase like that because you don't know, like, should I just totally start from scratch and start to port things in? Or do I take what I have and start tweaking it? And we kind of decided sort of in the middle, which is just, it's going to be probably like 70% of like a style redesign and a 30% of new features that need to be added. But most of the existing features are not changing that much. So it makes sense in our case to simply rip out all of the CSS, but keep a lot of the functionality. Like you said, we're all the routing. We have lots of like transcript work that happens.

• 7:24Wes Bos?

  And keeping all of that is pretty important. Because yeah, like you say, we don't want to lose all of our Git history, especially with some of like the weird stuff. It's like, why is it done this way? We literally have a file called why do I need this dot MJS in the thing? And it's some weird hack to get Vercel to work with a Wasm. And if we were to like simply put in there, you wouldn't be able to go back and see, okay, what was, what were the commits that led up to this hilarious file?

• 7:57Scott Tolinski?

  Yeah, which is so funny. So we ultimately just, we want it to be a smooth experience. It's going to be tough taking such a big codebase and getting it to be a totally new site. But I think there's enough there.

• 8:08Wes Bos?

  Totally.

• 8:09Scott Tolinski?

  Yeah.

• 8:10Wes Bos?

  One thing that's important to say here when you're asking this is, is simply just ask open-ended questions that maybe are kind of stupid. So like, like one thing I asked is like, do we want to stay with Svelte? And the answer to me is absolutely yes. But I think it's worth asking those questions. Even like, we're big on Markdown, right? The whole website is built in Markdown. And we'll talk about that in a second. But I was like, do we, do we want to scrap Markdown? Because there's some pains in that type of thing. So it's worth asking those open-ended questions where you don't necessarily think you have an answer. Because we had some good conversations come out of those.

• 8:50Scott Tolinski?

  Yeah, a lot of, a lot of good conversations. And honestly, I think meetings like this are so important. And the more people are a part of your team, right? Obviously, that impacts how any of these things are going to happen. But you do really need to know who are the decision makers.

• 9:08Scott Tolinski?

  In this case, it's the three of us, right? We're not a big team. If you're a big team, chances are those decision makers are going to be a much smaller group. And maybe that smaller group can take feedback from a larger group. But for us, we just don't have that, that big kind of dynamic where we have to make sure that everybody's happy. So it was fairly easy for us to be like, do we want to do this? Yes, no, do we want to do that? Yes, no, whatever. But it's important to have these conversations and really lay it out. Like you mentioned before, if we just started working on it, there would be all kinds of things. I mean, we, we got into naming, how we're going to be naming things, even like CSS variable names, those types of things. And I guess maybe, do we want to take a minute to talk about the CSS itself?

• 9:53Scott Tolinski?

  We're going to be ripping it, ripping it all out, one, right? But we decided that, two, we're going to be writing most everything scoped to the component with a nice base of a global CSS, utilizing just, you know, really good base CSS, based off of CSS variables specifically. And because of that, we needed to come up with variable naming patterns. We needed to come up with ways to make tooling work. So there's VS Code autocomplete for variables. There's style lint to make sure that nobody's adding a color to the repo that doesn't exist as a variable, Wes.

• 10:29Scott Tolinski?

  And just like keeping everything in the same naming convention, the same style. Everybody knows what's there and it's all going to be documented.

• 10:37Wes Bos?

  I, I think also part of that conversation was let's, let's have patterns and let's do things that are like conventions. But like, let's not go overboard to a point where it's exhausting to add something. The reason why there's hex codes in the codebase for me is because it was too much of a pain in the ass to figure out what the thing was. And sometimes you build so much of a framework. I'm not saying we did this, but sometimes frameworks are such a...

• 11:07Wes Bos?

  Like a hurdle that it's annoying to actually build something. So we had this conversation around a lot of things of like, are we going to build a whole system around something? Or is that kind of unnecessary for it? And we sort of landed on like, let's just have variables for the colors that we're going to use. Don't use the color straight up. And or let's, let's start with these paddings. And if we find that we need something, then we'll have to just start to, we'll have a discussion about, hey, can we add a weird padding? Even like on the syntax website is I found that the like border colors, there was not one that was faint enough for me. Right. And I went and added one that was like, kind of in between,

• 11:51Wes Bos?

  in between those values, rather than somebody just putting on opacity or just throwing in something that looks good for you. It's the like whole structure versus flexibility is just a constant battle. And we had Brad Frost on talked about design systems as well, where you want control, but you also want structure so that things don't like rot over time.

• 12:16Scott Tolinski?

  Yeah, no, I mean, I think that's really it because that is how rot happens. Right. And luckily there are tools out there like we mentioned, like style lint that can help you stay on track with those types of things. So I guess, speaking of that, let's talk about tooling. You know, tooling was a big part of this because with any JavaScript project, you have all them config files and all that stuff. We wanted to get off of ESLint. So we're going to be trying biome for this, which now has apparently pretty good experimental support for Svelte, which it didn't last time I checked on it. So we haven't tried it yet, but I'm hopeful that it's going to work.

• 12:54Wes Bos?

  Yeah, I moved my personal website over from ESLint to biome, simply because my ESLint config is in ESLint 8 and then 9 was released, but I'm using some plugins with Airbnb and like, it's so exhausting when things and like, sometimes it doesn't work, you know? That's so exhausting. And I was like, I just, let's try something else, you know? And I've been pretty Happy with with biome takes a little bit to sort of tweak things, but biome will be replacing both ES lint and prettier for us. Because it both does formatting and linting and it's it's very fast as well. It's it's not fully featured just yet, but enough where I'm OK deploying it in my own code bases.

• 13:39Scott Tolinski?

  Yeah, yeah, totally. And so biome actually does have like linting for CSS stuff. You might be wondering like why you style it with that?

• 13:48Wes Bos?

  Yeah.

• 13:48Scott Tolinski?

  And when we looked at it, the rules and the amount of rules that exist for biome just weren't weren't there for the types of stuff we needed, like establishing like a reg ex pattern for variable names, making sure that we are using variables for certain values, really sticking to this or that, which style it does a very good job of it's in in my opinion, it's really full featured in that regard. So, you know, it stinks to have to have more than one linter in the project, but like, you know, I guess you got to do it sometimes. Another big thing is we wanted it to be runtime agnostic. So we're trying to stick to both libraries and features that are not tied directly to any one JavaScript runtime.

• 14:31Scott Tolinski?

  That way, you know, if we want to run it on Bun, we can bun it up. We want to run it on Dino, we can Dino to it. So

• 14:40Scott Tolinski?

  I think that was important for us.

• 14:42Wes Bos?

  Yeah, it's I'm very much about like future, especially server JavaScript, right? Future server JavaScript. If there is something that is not a node API, but is something that is a standard like like web streams is an example of one. All of the winter CG APIs, anytime that there is a standard API that works everywhere, ideally, some of these APIs are both browser and server agnostic, which is really cool. So trying to stick to that as much as possible. Some of the APIs like like the file system API simply do not exist in a standard. And in some cases like Cloudflare, the file system does not exist at all.

• 15:24Wes Bos?

  So you can't get totally there, but we're trying to to get as far as we possibly can. And that way we'll be able to run it. Absolutely anywhere that we want it. Like, I would like to try to throw this on CloudFlare workers at some point to see what that looks like.

• 15:41Scott Tolinski?

  Yeah, yeah, I know, likewise. So, yeah, really giving that flexibility. So, again, we've established a structure for our CSS. We've established a structure for our tooling, our overall communication process. And, you know, another big one is development process itself. We've decided to do, you know, completely component-based development in that we're looking at the components themselves specifically, but we're going to be developing them more in isolation than we had in the past. I oftentimes am working by myself and what I do is like, you know, develop component-based flows, but do so usually in the layout. So this time, we're going to be trying to do so more in isolation.

• 16:25Scott Tolinski?

  We're going to be using Storybook, which is not something I've really used a whole lot because it's always felt a little verbose for me.

• 16:32Wes Bos?

  Yeah.

• 16:32Scott Tolinski?

  But I do think it will be worth it.

• 16:34Wes Bos?

  Yeah, I think so as well, being able to develop them in isolation. And one thing we didn't even talk about was like, like mobile or responsiveness. And I think we should probably try to go with container queries by default and then fall back to media queries. What do you think about that?

• 16:52Scott Tolinski?

  Yeah, I love that idea because, again, developing components in isolation, that makes so much more sense to me. And like, container queries to me make overall more sense in terms of like how something responds. So, yes.

• 17:08Wes Bos?

  Yeah. I think so as well. Like, I'm trying to think of a situation where you would want a media query over a component query. And that might be like, you know, like some of the iPads or sometimes when you're on your phone and you turn it like, like sideways like this, you don't have enough vertical room to scroll. A lot of people forget about, they think like, media queries are all just about the width of the actual device. But a lot of times, people forget like, no, if you're, if somebody has their phone in landscape view and they're holding it, you, you don't have a lot of vertical room. And if you're slapping like a sticky header and a sticky,

• 17:50Wes Bos?

  like, media player, we'll probably only have like 40 pixels to actually show the content. So maybe that's one, one time you want a media query, but I don't have a whole lot of other.

• 18:01Scott Tolinski?

  Use cases. Do you?

• 18:04Wes Bos?

  I

• 18:05Scott Tolinski?

  I guess we'll see.

• 18:06Wes Bos?

  But

• 18:06Scott Tolinski?

  The whole time you've been talking, I've been really struggling to think of a time. But you know, it's one of those things that like you sit here right now talking about it and like, is there any chance or blah, blah, blah. And then the moment that you hit that use case, you'll know it. But

• 18:22Wes Bos?

  Yeah.

• 18:22Scott Tolinski?

  Just thinking about it theoretically, I'm like, I don't know. I don't know, man. I feel like container queries, like what is the browser if not a container of itself? You know, the browser itself is a container. So

• 18:33Wes Bos?

  Deep.

• 18:35Wes Bos?

  Wow.

• 18:36Scott Tolinski?

  Yeah.

• 18:37Wes Bos?

  Oh, that's good. Oh, also, one other thing we talked about with tooling is having the VS Code extension saved into the repo itself. I've been doing this a lot lately. When I install a new extension in VS Code, I especially with things like linting, like I had my ESLint and prettier stuff set up, the plugins in VS Code like set up globally. And that was a bad idea because then I would have to disable them for every project where I was not using them. So I find that putting the extensions that are recommended and and active in the VS Code folder is a is a good idea. And then anyone who also clones the repo will have a suggestion.

• 19:22Wes Bos?

  Oh, you should install these sick extensions for this workspace.

• 19:26Scott Tolinski?

  Yeah, yeah, totally. I love that. And I think that is something that I we've done a poor job of in the past. And I say this as somebody, I've primarily been a solo dev on so many projects. So it's like

• 19:38Wes Bos?

  Yeah.

• 19:39Scott Tolinski?

  The moment that it's like, what would be really helpful for everybody to get on boarded smoothly and have the same experience develop? It's just not a like a way that I I have thought too much in my career. And I need to change that with this site build.

• 19:56Wes Bos?

  One other thing we didn't talk about is maybe throwing it in a dev container. I've long not been a Docker or container enjoyer, but CJ is huge on it. So maybe especially you gotta have the database sort of come along with it. Maybe it's a good use case for a VS Code dev container.

• 20:19Scott Tolinski?

  Yeah.

• 20:19Wes Bos?

  I want it to be as easy as possible. I just want to push a button and the thing fricking works. I don't want to have to like have a thousand steps to install it and have the right versions of everything. That's always a big pain.

• 20:32Scott Tolinski?

  It's a big pain. Yeah, I agree. So I thought we'll be talking quite a bit about this build as we go. And then, once it's done, we'll do a deep dive into all of the decisions. In fact, it might be really interesting to look back on this and say, how did that work out for us?

• 20:47Wes Bos?

  Yeah.

• 20:47Scott Tolinski?

  Yeah. Oh, you decided to use this or do that? And it turns out X wasn't good enough or whatever. Another thing I, you know, I think is important in establishing these things in a modern context is like your AI rules files, right? Because if you are like, I don't plan on using an agent to build most of the site or like even really any of the site. But like when you get the autocomplete and those types of things in your editor, it is important to be able to make sure that the AI is on the same page for everybody. Like, for instance, what are your specific code-based rules? If I'm doing state in Svelte, it should be a class. It should look like this. It should be named like this.

• 21:32Scott Tolinski?

  Here are the documenta. Here's the Svelte docs. Here's this or that. Like, get our cursor rules or whatever it may be, your AI rules file in order and everybody agree on the code styles. And then we are then, once again, unified on all that stuff.

• 21:47Wes Bos?

  Did we agree on on code styles as well?

• 21:52Scott Tolinski?

  During our meeting?

• 21:53Wes Bos?

  We, no, we didn't, but we're, we're, well, we're camel case, right? Snake case?

• 21:58Scott Tolinski?

  Snake.

• 21:59Wes Bos?

  No, we're snake case.

• 22:00Scott Tolinski?

  Yeah.

• 22:01Wes Bos?

  Yeah, we, I wrote a whole bunch of the like transcript stuff in camel case. And I wish that I had the linter. It was because the ESLint wasn't working at the time.

• 22:10Scott Tolinski?

  Yeah.

• 22:11Wes Bos?

  I kind of wish. That it was because now it's it's mixed, right? It's not a big deal, but.

• 22:19Scott Tolinski?

  We'll fix it, right?

• 22:21Wes Bos?

  Yeah. Yeah. Oh, yeah. It's it's probably not worth like fixing it until you touch that part of the code base again. But we're going to be going with like, maybe we talk about the code styles, right? So snake case for for all of your variables, like function declarations over like sticking them in a variable. Our CSS variables are simply going to be, what did we decide on? We were saying, should we use like, like color dash blue?

• 22:49Scott Tolinski?

  I think we're gonna do C.

• 22:50Wes Bos?

  Blue.

• 22:51Scott Tolinski?

  C dash.

• 22:52Wes Bos?

  C dash blue.

• 22:53Scott Tolinski?

  Just because for autocomplete, you can then do hyphen hyphen C and get the autocomplete of all of the different color options available. So otherwise you wouldn't be able to have that. We all felt that color was too hefty for that. Or at least that was what we we decided. The word color, I mean, and I think we'll be doing that with, you know, whether it's padding or margin or those types of things as well. You know, you're developing a system and I think that's the most important part is everybody knows where to go to be on the same page in that system. But yeah, coding styles, snake case, classes for state, which if you haven't, you haven't used Svelte 5 very much, Wes. I know you've done a little bit, right? You will like the classes for state bit.

• 23:39Scott Tolinski?

  I'll tell you that right now. It's it's it's very nice.

• 23:42Wes Bos?

  The beautiful. I'll say right now, we're going to be using gray with an E.

• 23:48Wes Bos?

  And I will be writing a linter rule. Any gray with an A will be will fail the build and you will be paged.

• 23:56Scott Tolinski?

  Yeah.

• 23:57Wes Bos?

  If it breaks the build.

• 23:58Scott Tolinski?

  Okay, as long as we can spell color the right way.

• 24:02Wes Bos?

  Yeah, that's one thing I've never had a problem with being Canadian is switching between color with a U and color. Like when you're writing in code, like I can, I'll even switch it in writing a comment, you know? Change the color to gray and I'll have no problem writing with U there. But when I'm writing in code, I'll I'll do that, which is is a skill of mine.

• 24:26Scott Tolinski?

  Yeah, well, you gotta be, I guess that has to be a skill of yours.

• 24:31Wes Bos?

  It's, yeah, one of my few skills.

• 24:35Wes Bos?

  Content. Last thing I think we have here is where will the content go? So right now, we have all of our content in Markdown files. And we have a pretty good like system for that right now. The way that it works is you, when we add a show, we write it in a Markdown file. The build will pick up that it's a new file, or if it's changed, based on the hash of the file, and it will update that and put it into the database. And we did that because we wanted it to be 100% on GitHub, right? But we really need it in the database. And quite honestly, I just redid my website and I have 700 Markdown files as well, or MDX files. And I kind of regret it because it's such a pain in the butt.

• 25:21Wes Bos?

  With, it's getting way too big, right? And I was like, I kind of wish this was just a CMS, you know? So we are going to be switching it from Markdown files into like our own homegrown CMS, maybe, right? Like, we just, we just want to be able to edit a text area and save it to the database.

• 25:42Scott Tolinski?

  Well, I think the hard part is that, like, we are establishing a lot of sources of truth for data. So we have the Markdown files, which is syncing to a database. We have our podcast provider, we have YouTube, we have all these areas to update and whatever. So we were like, well, let's just eliminate one of the big ones there. And let's just eliminate that component of it, where the Markdown thing, having to rebuild the site to add something to it. And we already built an admin section. I mean, it's not like a full-featured CMS admin, but it is almost there. And so the amount of work it will take to get there isn't that bad. We already have a lot of the admin pages, the listing views and stuff like that.

• 26:24Scott Tolinski?

  It's just like building those forms and building that flow of making that an easy experience. So I think that part will be really nice to be able to manage the site in that way. I mean, that's how I always did LevelUp tutorials. So I'm very used, I built my own admin section there and it was, you know, very full-featured. So yeah, I'm a fan of that.

• 26:44Wes Bos?

  I also think like a bit more UI for editing the episodes. Like, right now, when we publish an episode, we use like a Unix timestamp for the published. And in order to get that, you have to like go to the Epoch website and like copy paste it. That probably should just be a date input, you know?

• 27:05Scott Tolinski?

  Yeah, yeah, yes.

• 27:07Wes Bos?

  So.

• 27:08Scott Tolinski?

  I mean, that's what we did. That's what we did in the Syntax Production Assistant app that CJ and I built.

• 27:12Wes Bos?

  Yeah.

• 27:12Scott Tolinski?

  So just, yeah.

• 27:14Wes Bos?

  Just bring it right into the, right into the UI will be really nice. It has the downside of, of people not being able to edit the notes, um, which is a bit of a bummer, but.

• 27:26Scott Tolinski?

  Yeah, third parties. If, if we wanted to bring somebody on who wants to be able to help us out there, there's always a possibility of opening up like limited role access stuff to modify certain things.

• 27:37Wes Bos?

  Or like, like just a, if someone wants to run the website, we can, we can give like a seed database as well with

• 27:43Scott Tolinski?

  Yes.

• 27:44Wes Bos?

  a whole bunch of content in it, which we already have as well, but it'd be nice to. I even talked to the, the folks at Planet Scale as well. I was like, what, would it be cool if someone forked the Syntax Repo? And we just gave them a copy of the Syntax Database?

• 28:01Scott Tolinski?

  Oh, yeah.

• 28:01Wes Bos?

  Without the like sensitive parts, like the, the, pretty much just the users, right?

• 28:06Scott Tolinski?

  Yeah.

• 28:07Wes Bos?

  That would be really cool.

• 28:08Scott Tolinski?

  Yeah.

• 28:09Wes Bos?

  I think that's all we have here. Anything else to add?

• 28:13Scott Tolinski?

  No, I think the most important thing is that anything that you don't get communicated in these meetings and processes for your teams, those things will end up probably rotting at some point because people are just going to make their own decisions. So if it feels really, it feels intense to have to go through everything line, but how are we doing, see, how are we? You know, if it feels intense to do it, just know that like, having that establishment, uh, in place before you even put pen to paper at all, will give you a better outcome in the end 100% of the time, especially with more people that are working on it. If somebody has to make a decision on their own on how to do something, then that means like,

• 28:58Scott Tolinski?

  you're going to have five different ways that it's, if, if not more than that. So. These types of meetings are really super important. If you're out there and you have these types of meetings with your team, big team, small team, whatever, how does this stuff typically go for you? Is there one person at the top saying, we are using Pascal case on everything? Uh, or? Or like, is it more collaborative? And how does that look? We want to hear from you and what your teams are like, because obviously, we're a little three-person team. A lot of us are used to working in a solo capacity. So let's, uh, let's, let's hear how some, some teams work on this stuff.

• 29:32Wes Bos?

  Sweet. All right. Catch you later. Peace.

• 29:36Scott Tolinski?

  Peace.