Bike Shedding — Developer Opinions Explained

to Syntax, the podcast with the most controversial opinions ever.

Today, we have a show on bike shedding. We did a couple years ago, we did a tiny little hasty on bike shedding things like tabs versus spaces.

But today, we're gonna do a entire show on opinions that developers have and rid Why we're sorta sorta gonna explain, like, why people have these opinions and and then go into what our opinions are, which this might be the biggest rid Scott and I disagree episode ever because, usually, we're on the same page, but these are, these are some some spicy,

spicy meatballs here. Yep. We got some

Spicy kielbasa coming up. Yeah. We are sponsored by 3 awesome companies today. First1 is Prismic, headless CMS. Second1 is LogRocket, JavaScript rid Obsession replay, and third one is Mux APIs for streaming your video into your platform. Talk about all of them prior to the episode.

My name is Wes Bos, and with me as always is mister Scott Talinski. How are you doing today, Scott? Hey. I'm doing good. I,

I have a new hedge trimmer coming. I don't know how exciting that is to you, but Very. I have a new new bag. You know, I have that whole crappy Black and Decker one. Like, ready. It's basically a kid's toy. The hedgehog. That's what we have. I don't know if it's or is that what it's called? Because I don't know if that's that's what I have because mine is basically like a children's toy. You know, like, The the the bad brand of, like, Black and Decker, like, entry level yard products that stopped working after a year. Although, I've had it for, like, 5 years, so I'm I'm finally Getting an ego one to match the rest of my battery setup, and, yeah, I'm just I'm watching it on the UPS out for delivery map right now, and I'm just, like, watching They come along. I'm like, well, I'm gonna trim so many hedges today. UPS has a delivery map, like like a Uber Eats? Sometimes.

Oh, that's so sweet. I don't know One in which the parameters are that that give me this map, but sometimes I get an email that says follow along, and I click and make I wish that we had that. That's awesome.

Yeah. So I'm doing pretty good, man. I got a hedge trimmer coming. How could you not be good? That's pretty sweet. I we ripped out all of our hedges

A couple years ago and put in little retaining walls. We don't have any hedges, but I often watch, like,

hedge trimmer Yeah. Videos. The gratify. Rid Yeah. Satisfying.

Yeah. And, like, you can like, people make these, like, little, like, pieces of wood that they put on them. What do you call that? Like a a guide or something? Yeah. There's a word for that where you have, like, a guide that you reuse over and over again.

Oh, man. That's gonna bug me forever. I can't find the word, but there's a special word for I I think I found it. Hold on.

A jig.

A jig.

Oh. Oh, I couldn't Oh. I've only ever heard that term in term of use of, like, a pocket hole cutter, rid In Out Pocket. Oh, yeah. Like, a jig is just like something that you make so that you can consistently

shape and size something over and over again.

Rid We should make a a jig dot CSS.

That would Yes. That would be good. I like that. Yeah. It's a pretty, pretty short word too. Easy to easy to search. Yes. Alright. Well, let's jump in now. Let's just go back and forth, and what I think we'll do here is explain for some of them, we we'll have to playing, like, the differences between the 2 and why people might think either side, and then we'll also dive into what our own opinions are if we even have them. We should also say this is bike shedding, and bike shedding means that you spend so much talking about what what color the bike shed should be instead of actually building it. So a lot of these things don't matter at the end of the day, but they are things that us developers love to obsess over and talk about

Making our lives better. Yeah. For the most part, if you disagree with us, don't hate tweet us. We we we everybody's got different opinions. That's the whole point of this. Don't get into arguments about this stuff. I put out a tweet to ask what everybody's

bike shedding things were. What what were the I said, what are the anthills you'll die on? And I said, don't start fights and replies. You are a nerd. And sure enough, fights were started immediately.

And there's still, like, 5 or 6 people being like, well, actually. Yes. Absolutely. Okay. So the first one, event parameters. So you have an event that's fired off in JavaScript, rid. And, typically, whether you're preventing default or capturing some information about what that event is or or just basically understanding rid The context in which that event took place, and many times, we have the event that's passed into the function that's called from that event. Right? Yeah. And what do we do? How do we name that event? Sometimes people use e, e v t, e v, or event.

Now,

Wes Bos, what do you do for this? I either use e or event. And I asked this on Twitter, and it seems that, I don't know. 60, 70% of the people use e, and then a majority of the rest use event. Very few people use EVT or EV. I was just copy pasting some code from Mozilla docs, and it had EVT on it. I was like, come on. Yeah. Come on. You Yeah. Took 1 or the they're not sorta halfway through.

I'm fine with either either version of them. What about you? I'm 100%

with you. E or event? It's EVT or EV stuff. I just did a search in my code base, and we only use e in my code base. I would have guessed that I half and half did it, event and e, just because of, you know, my inability to To stay, you know, totally standardized on things, but turns out we just use e entirely on their code base, and I don't know how many problems with that. I usually don't like single

character variables. I don't either. Unless it's I for, like, accounting increment variable. But I think E is is totally fine because, like, I think it's a standard enough thing, and then it's nice and small. But the argument on the other side is that, like, re You are not a minifier, and you can type out the entire thing. So it is very clear

that it it is an event. Yeah. And I think, Specifically in React land, most of the time you're you're looking at the events. It's like event dot prevent default just on a form element or a click or something. You know? It's like, In that case, I'm just gonna take the the easiest route and just do e, so I have I have no problems. Alright. Next one is going to be rid CSS variables, whether this is custom properties and or Sass variables, anything like that, oftentimes, you'll see people using accent primary, whatever, red. Or you'll see them described as a color, red, blue, green, black, whatever.

The arguments for using primary is that You're describing what the color does, or I always refer to it as, like, the color's intentions rather than the color itself. Yeah. This is a little bit better for theming and things like that. However, Some people say, well, this is the this is the site's blue, so let's just call it the blue. Wes, what do you do? I think I what I do and what I should be doing It's 2 different things. So I primarily use

red or green or yellow variables, with the exception of doing light and dark. Sometimes I'll I'll just set, like, black to be dark and then white to be light, and then and then I can adjust them if they're a little bit off, not like perfect red. Black and perfect white. But I do see the benefit of using primary, secondary, things like that because it makes theming your product a lot easier. So I think if I were to start a brand new project and know that I want dark mode or something like that, I would move to this. I I think I should try it on my next project. What about you? Yeah. I mean, I was nodding my head so hard. My head almost fell off. I,

I I primarily do so first, I define the colors. Rid I always define my colors, especially for, you know, blacks and, you know, just the standardized sort of stuff. But then I take those colors and then redefine them into rid This system, which I use as the intentions, whether that's primary accent, those sort of things. And then I'll even go further and have, like, button colors set to accent and stuff like that. It makes theming a heck of a ton easier to be able to just change the accent site wide, especially if you're using CSS custom properties, Which get updated automagically throughout your entire site when you change them. So also can be scoped really nice and easily. So me, personally, I always Set the colors first, and then I use those colors to set the intentions. But then if I'm theming, I'll override. Sometimes I'll override the colors. For instance, we have a nineties version of level up Tutorials and our theme, which is basically our same color palette.

However, the colors are all changed to be, like, named colors.

Like, the purple becomes Rebecca purple, and the the teal becomes the literal world word teal. So it's like the The color, the named colors, the web safe color version of our current, theme. And in that case, I just reassign the colors. You know, this is the new purple. This is the new teal, And the the thing here looks nice. So I'm a big, big proponent of, doing it that way. I like it. I also like doing these shows because it

Sometimes you just do something forever, and then you don't you don't think about it. And then you go, oh, I didn't realize you could even have an opinion about that. You're like, oh, it makes sense. Maybe I should be doing it that way.

Rid So maybe bike shedding is good. Yeah. Right? Totally.

Next one we have here is, colors. If you are specifying a color, Do you default it to RGB, HSL, hex, or something different? I think I usually go for, HSL value, And that's because either my color picker or my design program, I've set it up so that it will default to HSL.

But whenever I'm doing A value that needs to be semi transparent.

I always go to RGBA for some reason, and I don't know why because it is very easy to generate black And white with HSL, and you only have to change one value in HSL to make it white or black. Whereas with RGBA, you have to change all the zeros to 255.

So I want to be using entirely HSL, but old habits die hard, and I've been using RGB for a lot of that as well. Yeah. Rid

that's so funny that you say that because I moved to HSL primarily through our entire system. But you are so right. Anytime I reach for hand coding rid color.

I almost always do RGBA because my brain just, goes there. Maybe I've I've just used it for so much longer than I've 0.5.

Okay.

That's easy. Yeah. Right? But why not HSLA? Rid. 0.5. Okay. That's easy. Right? But why not HSLA? I I I have no idea. All my variables are set with HSLA. I even have variables for, like, The hue and saturation for our colors. That way, I can just tweak the lightness values. So I mean, I have all that stuff there. I just Don't find myself coding it by hand that much, but, yeah, I I I totally agree with you. One fun thing you can do with HSL is that

If you're doing just white and black, the first two numbers of HSLA don't matter. So you could set them to 4 20, 69%, and 0, and that would be black.

And then a 100% would be would be white. And so I always like including those fun little tidbits in my CSS because it makes people stop and go, Wait. Why did he do that?

Yeah. It is.

I don't know. There it's so funny because there's, like, 800 different ways to skin this cat, and, Everybody skins it just a little bit differently. Isn't that the that's the saying? Yep. Yes. That's the saying. Alright. Next one is going to be rid. Default exports versus named exports. Now this one is kind of interesting to me because we kind of went fully onto named exports.

Reason being is that a named export can be, but it's more explicit for the name. It can be renamed upon importing, but It's explicit when that's been renamed upon importing, where a default export, you can just rename that thing willy nilly on the import.

And that is, to me, a bit of a foot gun, especially if you're trying to keep things consistent because if one thing gets re Change somewhere. Right? Let's say you have a React component that's a default export. Yeah. That component name gets changed within the component.

You then have to go hunt to find the export.

Make sure anywhere that you're I mean, you have to hunt the imports anywhere that that's been imported. You then have to Keep those names up to date in sync.

If this thing is a named export, you change that name, your side's gonna break, Unless you, go ahead and change the other one. So me, personally, I've definitely been moving really heavily into named exports exclusively for just about everything With the caveat there being, I almost said stupid, and I don't wanna call it stupid. But, React lazy requires your exports boards to be default, and we use React lazy. So anytime I have a component that's lazy imported with React lazy, then I have to have it be the default import even though I'm not happy about that. Yeah. When I first saw this article maybe, like, a year or 2 years ago where somebody I forgot what the article was. Basically, it says you should be using named exports for everything.

I And don't use default exports. I was like, come on. That's silly. But the more I, like, sort of rattle that around my brain, I'm thinking, yeah, the rid. The auto import works a little bit nicer because it knows what to call it. And if you wanna refactor that thing, then that works really well because it is explicitly named, like Scott said, one other thing is as we are in this, like, weird space of transitioning from common JS to DSM, ES modules, Sometimes you find yourself importing the named export of the word default, which is really odd. So So that's just like another another one. So I found probably in the last 6 months or so, I've changed my tune on this and said, yeah. I think, And, also, just the the fact that you can export multiple things and name them that that exact thing, I have found myself using named experts rid more and more. It's it's not an absolute rule. I don't I don't you'll find me doing default exports still a lot, especially in my tutorials and whatnot, but I definitely see the value in that type of thing. Yeah. We've largely just moved to it being a rule, but it's not like re There's not some mean things stopping you and preventing you from pushing changes if you're using a default export. It's kind of the only honor system or something like that. Rid Not not too intense. Yeah. Next one we have here is also about, JavaScript imports, and that is import ordering.

So some people, when they import their dependencies, they will first import your JavaScript Dependencies that come from your node modules, things that you npm installed, or things that if you're in Deno, maybe things that are you're you're importing from a URL. And then after that, you're importing everything that is local to your project, and you sort of separate those 2. And I think some people even go further and Alphabetize them or something crazy like that. This is one that I do only because my ESLint does it automatically. So I have the setting on ESLint, or maybe it's prettier. One of those does this.

And if you have a local file import in Mixed up with some of your node modules imports, then when you hit save, it will just reorder it for you. And I I find that to be pretty nice, That's not a a hell I die on either. Wait. What was that that import or that changes them for you? It's an ESLint rule. It's called sort imports, And it will just sort them for you. It will also alphabetize name imports for you, which is rid Kinda neat. So if you import a and b in the wrong order, it will reorder them. So, like, why not? It's it's doing it for you. Right? So it's it's not any cognitive load on me. This is something I do by hand right now.

Oh, man.

So

God. So, yeah, not only is this something that I do do, and I really I really like rid My, my import started. I'm doing this by hand, which I'm just feeling like a total goofball right now. I'm feeling like, king goofball.

Rid Sign me up. That's me. Yeah. But, yeah, I do prefer my import sorted. It just keeps it nice and more organized. I can see at a glance especially, we use a lot of, like, aliased paths, And some people prefix their alias paths with, like, amp or, the at the at sign, and, like, then a bunch of packages Started name spacing under the at sign. So it's like, well, I guess that's not really that that good of a signifier that it's a local package then. Rid So ours, we don't prefix it with anything. That would kinda help some of that stuff stand out, so I I like to keep all that those separated.

Anytime we have, like, a, an aliased, like a local package, then we keep those first. So we do NPM packages, localized packages, and then relative imports, whatever. So Next one is going to be, the usage of foobarbaz in examples. I have never read. Used foobarbaz in any of my tutorials, and I probably will not lie because I didn't learn that way. I mean, I've I've, rid When I learned JavaScript, people were using math to teach it, and that doesn't I don't know. The only time I've ever done a foobar baz, rid Literally, the only time I've ever written that code was when I had my 1st Google interview, and they had me do, like, a just basic test rid I don't see the the benefit in using it. I would rather just use some some more real world variable names and examples.

Yeah. Yeah. Me too. I've rid Firmly dug into this as something that I'm very opinionated about, which is, rare for me. I don't feel like I'm super opinionated about much, But this is one thing I'll say no. Absolutely.

At least for my teaching style and the type of people that take my courses, I don't use Foobarbaz in any of my stuff. I find it very confusing.

Rid The idea so maybe we should say the the flip side. The flip side of using these are called metasyntactic variables.

The idea is that if you take Dogs and people and sandwiches out of the equation when learning something and just use foobarbaz, which are nothing. They're just variables.

Then it forces you to focus on what is happening with the data in that function or in that in whatever code that's being written.

I have not found that to be the case at all, especially because, like, you people wanna say, like, when would I ever use that? That's the big question in learning.

And I whenever I teach, I I try to show how it works as well as not necessarily in the same example, but As well as when would I ever use that? When is that handy? What like, why why am I learning this? And what I've heard from a lot of Experienced developers is that I'm wrong, and what I've heard from everybody I teach is that I'm right. Yeah.

Dude, I I feel you so much on that because it's like, That just does not it doesn't speak to me. I mean, I've never written code. Like, if I'm writing FOOPROP ass, what I'm not doing is I'm not I'm more focused on, like, the syntax, the the letters that I'm typing. Right? But I'm not necessarily focused as much on the concepts Yeah. Which is like, Hey. I'm checking to see if this dog exists. Does dog exist? I mean, that's just way more does Baz exist? Who what's who's Baz? What's Baz doing? Is Baz a good dog? Like, I don't know. Not for me.

Let's talk about a, a good product, and that good product is Prismic.

Not only is Prismic a a great product, but they have a great landing page you're gonna wanna check out too. And Wes is going to talk a little bit more about this Headless CMS that makes building web pages super, super easy. Yes. I really like Prismic because they understand

what kind of products us developers want and what kind of products the end user, which I'm gonna call marketers, wanna use. Because the first the very first button on their website is for developers, and then you could click on a button that says for non developers. And it shows you code on the home page as though you can use Graph queue out. Maybe I should explain. Anyone's brand new to this podcast. Prismic is a headless CMS that has a REST API and a GraphQL API. Log in, create your data types, and it will spit out a really sweet API, which you could use to pull into literally any Any code ever. PHP, JavaScript, React, Angular. They have examples for pretty much everything out there, but The developer will, like, will enjoy using this type of thing. They got this really slick thing called slices, and then the end user will like using this thing because it's a really Simple, easy to use, super clean, great UI way for building pieces of content and then clicking them together into pages and and whatnot. So check it out. Prismic, p r I s m I c dot I o forward slash syntax. Thanks so much to Prismic for sponsoring. Sick.

Next one we got here is this is the most controversial one is, people who prefer dark themes unstable.

Yeah. No. It's light versus dark themes, and we joke about this a lot. Let's hear Scott's opinion on this first. Rid. Yes. My opinion is I use dark theme for literally everything, and if there's, like, an OLED,

like, 0 version of the rid theme. I use that one.

I have always liked this. I mean, my favorite version of Android was, man, one of those is called Honeycomb when everything looked like it was spit out of, like, a retro futuristic Terminator movie where it was, like, black and, Like, neon blue, and, like, to me, that aesthetic has always just very, very, very, very much spoke with me. You know, I I don't know why, but, like, you know, Monokai was, like, a such a just a a great thing for me when I went from Dreamweaver to rid. Text me to there's Monokai, and I'm like, oh, this is where I wanna be. So for me, I'm a dark theme. I'm a even in the level up tutorial site actually, This is actually very funny, Wes, because we have, like, a whole bunch of themes in the level up tutorial site. I use the the syntax theme more than anything on that just because I I like the way it looks. But For the most part, I use just dark themes for everything.

Notion, GitHub.

I could just go on and on and on and on and on. It's interesting. I'm split, and it's every single product gets

a I decide which way I'd like to go. In my code editor, I'm dark all day long. I use Cobalt 2, which is my theme, and it's, like, blue. It's obviously dark theme, but it's not, like, dark dark. I don't like I like a lot of these dark themes where they use rid More like blues and stuff like that than like, somewhat dark mode on a lot of things. It's just, like, brown, and I'm not a fan of of brown at all. So In my dev tools, I can't stand the dark theme in my dev tools. It's light all day long for me. Notion What? Light all day long. Give me at OSX, Light light mode all day long. GitHub, dark. Been enjoying GitHub's dark mode. Tripping me out here. Yeah. And it's just, too much dark because I find it hard to read the white text on on a dark background.

I like all the windows shut in my office. I like the lights off. I like

Oh, no. And what Instagram, dark? Yeah. Twitter, dark? Yeah. So it really depends. But every time I see a screenshot of somebody with light mode, I'm like, that looks nice well. That's crazy to me. It never looks nice to me. It looks

crazy.

I don't know. Not for me. Alright. Next one is going to be interesting here because I'm I've definitely been in 1 camp for a long time and have moved to another camp. So this is the long verbose names describing what it does verse, You know, short name, like x. Yeah. A good good example might be, like, time. Const time is equal to whatever, And then a longer one would be cons time until next event or something. You know? Right? So one is saying what it is. It's Clearly time. The other one's describing a little bit more about what it does. Now in the past, I always opted for the terseness Of short variable names, things like a time out really nice and easily quick, parse it all at a second, and I've really firmly moved into the other camp where it's like, If this thing the variable name describes exactly what it does, then I have to write less comments. The comments become less important because the variable name describes what it does. All that stuff is very readable. I'm not having to type most of it out anyways.

Usually, what happens is my text editor auto completes it for me. Or if I need to change the name of it, I rename Symbol, those kind of things. Yeah. So, basically, what I've I've let is I let Versus Code really do all the heavy lifting ready. For me of doing those long variable names. And now I really opt for a long variable name that describes what it does so that I I don't even have to read the comments if I don't want to, and then just say, okay. Time to next event. That's what this thing is. Yeah. I'm I'm in the same camp as well. I probably started off with shorter variable names, but I find myself being like, okay, time. And then I'm like, now I have another time variable. So So do I call that? Time 2? You

know? And if you were to put a little bit more description in it and same thing with when I I do a lot of vanilla JavaScript, I always like to put l at the end or even element so that, you know, something is an element without even having to hover over it. Even TypeScript will give you types, but It's nice to know. Okay. Items is an array of data, and items l is a div or unordered list that's actually in the DOM. So I agree as well. The only case I don't agree is sometimes I'm writing a lot of map filter reduce, And I chain them onto each other, and then I've I've sometimes I just say x because it's nice little inline implicit return. But that's not for code that will be sticking around a long time. It's just when I'm doing quick little

little things. Yeah. Interesting because I I will always still name it, like, what it is. It doesn't have to be a long name. It could be time rather than time to next event, But I I will give it a meaningful name even in those map situations.

You also get better errors. That's the thing I didn't, rid say as well is that if you have an error and it says time or x, it's better to say time to next value dot rid Now is not a method. You know? Mhmm. Next question we have here our next, thing is the editors, rid Versus Code versus WebStorm versus Vim, these are the the 3. Anytime I post anything about Versus Code, rid I get the WebStorm boys in my comments being like, WebStorm could do that forever. Why don't you use WebStorm? Let's talk about that. Webstorm. Webstorm. Webstorm.

And I get the feeling that Webstorm is awesome because usually when people are so emphatic about Something like that. It's usually because it's pretty good. But I've tried Vim many times over my career, not for me, especially as someone who does tutorials. And now especially that I'm getting really into TypeScript, nothing better than Versus Code, I think, for TypeScript dev because it comes

rid from the same folks who make, TypeScript. Yeah. I like Versus Code so much. And even just, like, just on Friday, I retweeted rid. A Versus Code tip about collapsing HTML, that Jared Palmer had tweeted out, and I retweeted it. And it's like so obnoxious when somebody comes in or just use Vim.

You know what, man? You're I don't know if you think That you're helping or you're being clever or that, like, people actually want to hear that. Nobody cares. Nobody wants to hear that. Like, Can we just really you know, if if somebody's sharing a Versus Code tip and and you don't use Versus Code, guess what? You don't gotta you don't have to say anything about it. You don't have to tell you don't have to to push your your VIN on other people because everybody wants to use it. I understand where these VIN people are coming from

Because it is hard to use, and they've invested a lot of time, and they're really good at it. And then when somebody comes along with Something that is so much easier to use, and it it looks like a toy to them. It frustrates them because somebody is happy with what they're using. Rid. I I have the same thing in barbecue land. We always joke about, what is the easy bake oven? The Traeger grill. These, like, pellet grills. You plug it in and you Bluetooth app it, And it makes amazing barbecue, and it bothers, like, legit burning wood, feeling the coals barbecuers because it's much harder, and they spent a lot of time figuring that stuff out. And when somebody comes along With this thing that's much easier but still produces the same output or, in some cases, a better output than a frustration. Same thing with, The Nespresso. Like, have you have you had coffee from an espresso? I have. Yeah. We have a Nespresso.

It's really good. Yeah. And it's It's all been and it's just this little, like, puck that you you pop in there, you press a button, and it makes really good coffee. And that drives People with the, like, $4,000

espresso machine, the grinding it, and going to Ethiopia to get the coffee Oh, yeah. It drives them crazy. Rid Right? And oftentimes, people just see this like, well, maybe if you learn how to use VIM, you would like it. And it's like, yeah. Sure. Maybe if I invested that time, I would I would learn to like it as well, but I'm perfectly productive in Versus Code, and sharing a tip about Being more productive in Versus Code is not like an opportunity to to be like, well, you could be productive too if you put all this time and energy into learning something completely different. You're like, no. I don't want to. You know, let me I like clicking things sometimes. Yeah. Sometimes I do like clicking things. Okay? Yeah. But, for this one, I'm I'm firmly in the camp of, rid I like text editors. In Versus Code versus WebStorm, sure. There's probably some things that WebStorm does easier. Do I have a hard time occasionally getting the debugger to be, as friendly and nice as I want it to be in Versus Code? Sure.

Would that be better in WebStorm? Sure. Does it make up for the cost, like the actual It does not look as nice as Versus Code. And if if that is, like, if that's stupid yeah. I get it. That's stupid. It's a text editor. We're programmers.

At the end of the day, I'm spending all day every day in Versus Code. I gotta like the way it looks. I gotta be able to theme it. I gotta be able to change it. It's Comfy home for me, and, you know, that comfy home has gotta be a comfy home. So I I that that is a stupid point, but I would like to say that. I think it is.

Rid definitely something that I I it's not it's a nonzero factor, you know, in in my decision.

Next one's going to be the use of, rid I'm gonna call this a generic name instead of a descriptive name instead of TypeScript generics because read. In TypeScript's own documentation along with just about thousands of examples that you find online, people just start throwing single variable, descriptors for generics in TypeScript like t and, like And u. And u. You know what? That rid Has that single handedly made generics way more confusing to me than, anything else because, like, That's just so not real world. And when I do generics myself, when I have my code generator do generics as well, everything is really nicely named so you can See exactly what it does when you import other generics from other libraries and things, they always just have the correct name. So why Show t as a generic exam. I don't get it. So I don't use t. I don't use u. I don't use single variable generics. That is very hard for me to read.

And it and oftentimes, it's not saving me anything. Yeah. Generics are probably one of the hardest things of TypeScript to understand, And, like Scott says, making them one letters makes it even harder. I think the reason why they do that is because when you're looking at a custom generic that somebody's written, re It's very clear that t u h, those are, like, variables that need to be passed in versus actual types in your code base. Ready. And to me, that doesn't matter because Versus Code released some sort of update a couple months ago where the themes Your theme can know about what is a valid type and what is an invalid type, and it will allow you to style those differently. So In my Cobalt 2 theme, it's very clear to me when something is a generic variable versus an actual legitimate valid type Because it makes it pink and italic versus yellow and not italic. So if that's the reasoning behind it, that's been alleviated For me, because of how it looks in my code editor. Yeah. And I typically name my

types with capital letters. Start with those with capital letters, and I typically name most of my variables starting with lowercase letters. So that's pretty easy for me to to see there, but, that's typically what I do tip rid Typically. I also typically if I wanna solve bugs, I like to have a visual representation of solving those bugs. And so to get a good visual representation of Solving those bugs, one of our sponsors today does such an amazing job of that. I'm talking about LogRocket.

This gives you a session Video replay of the error happening in progress. You can see this thing happen. You can debug in ways that you've never debugged before Or maybe perhaps ways that you've debugged before, but only your in your local environment when you're causing error yourself because this gives you a scribble video replay with the network tab. It gives you the console. It gives you the dom. It gives you all of those things, and you can scrub back and forth and see exactly what happened, why it happened, where it happened, and rid Who it happened to. So give it a try at logrocket.comforward/syntax.

Sign up, you'll get 14 days for free. This is one of those services You really have to see to believe because it is so so stinking cool. And, actually, Wes, they just got a new little homepage With a little isomorphic three d design here, some logos and stuff. Hey. This thing looks really nice. Oh. Yeah. So shout out to LogRocket rid and their design team for launching a new landing page because this thing looks sick. Next one we have here comes on Twitter from Leah Lundquist, and she says, any indentation

based rid and tax is the worst. The hours I've spent wrangling YAML configs because of a single line was misaligned.

That's that's a good Good question. Good opinion. Like so things that Python, Stylus, I've been a big fan of Stylus, Jade. Rid Ruby. Ruby, these are all indentation based. And when you're 80 lines deep and there's different indentation, it can be difficult.

I like indentation based syntax.

I definitely have had those problems, but I've alleviated that with Versus Code extensions where you highlight what is it called? Let Look it up.

The indentation. Yeah. You maybe it's based on my theme, but, basically, the the indentation will be highlighted so you can rid. Visually see.

And then also, there are shortcuts in Versus Code that will allow you to select based on indentation, and that is super handy because you don't have to guess where do I stop selecting text. You just have to hit this keyboard combo that will rid. Expand to indentation level, and every time you hit it, it will go up one level, higher. So I think With some help in the text editor, they you can find joy in indentation based syntax.

I honestly prefer indentation based syntax. It's rid It's one of the things that I would prefer to have in JavaScript that I like. Was was CoffeeScript indentation based or was it just Yep. Yeah. That's one of the things I liked about Coffee script because it did it felt more like Python or more like Ruby, obviously, more like Ruby. I I really enjoyed that aspect of it. And for me, I don't know how much, you've heard me say this on the podcast before, but I have, in my brain works in a way that is very visual. So My IQ tests and my whatever my wife is a psychologist. So while she was getting her PhD, she scanned my brain over and over again. She knows everything about my brain, and what we found out is that I have very good visual spatial skills.

That's just about it. So, like, for me, if I can see all of my rid Code based correctly indentation, and I what I end up seeing is, like, big shapes rather than individual lines. I'm not a great reader. So seeing those shapes for me, rid. Big, big plus. I mean, indentation Prettier. Right? Prettier and ESLint really changed our lives in JavaScript because they just I made all that stuff super duper easy to not even think about. And for me, being able to recognize shapes and patterns helps re program. So I really prefer indentation based syntax. I understand people who don't. One thing I I like that it does is it enforces Standards in your your code base. I mean, we we have that fixed kind of with Prettier now, but for a long time in the wild, wild west of JavaScript, You get some maniac who's putting their brackets on a a second line of an if statement, and then you're just like, what are you doing? And so, like, now we don't have to worry about that, but there was a time when I was rid Man, I would kill for indentation based syntax here to prevent things like that.

Next 1 is going to be max line length. And now max line length, I don't know what yours has said at West. I've always been a fairly narrow narrow, max line length person, and I really preferred a narrow, Maybe, like, even, like, a 90, something like that.

But recently, our development manager, Tom, he's like he looks much wider.

So I was like, okay.

We'll do a compromise here, and we set it to 120.

It's been at 120 now for a little bit, and I gotta say it's too wide for me. Aw. And I'm I'm willing to I'm willing to make that compromise and, you know, if that's if that's a hill he's willing to die on, I'm willing to leave it at 120, you know? But I like to have multiple tabs open, multiple columns here, and then my 15 inch MacBook Pro at 120 with the sidebar closed, everything closed, and set at 120 and the font size is really pretty small, I gotta scroll horizontally to see the whole rid React component. I love that. But, again, not a hill I'm willing to die on. I'm I'm willing to to to be Flexible on this one. There's a lot of people that say,

max length. The reason why we had that was because of, Like VIM and old, like, monitors, and we didn't have auto we didn't your IDE didn't have line wrapping back then, and Monitors are much larger. I don't use line wrapping. Do you? Yeah. Oh, absolutely. I hate horizontal. So maybe that's maybe that's my problem. Maybe that's the solution here. Yeah. You if you find yourself having to horizontally scroll, then just turn online wrapping.

Yeah. Because that's a A user decision as to how they want it displayed in their editor.

I've set mine to 120 probably 2 years ago, and I've been pretty happy with How everything looks, and I especially like it when you chain methods.

Mhmm. And it it takes them from being all on one line, and it puts them Each method on its own lines, map map filter filter reduce.

I'm a big fan of that. So I think 120 is the sweet spot for me, But I wouldn't really care all that much because your IDE can wrap it. And, also, you can With Prettier now, you can just have your own local Prettier work in that, and then but when you when you commit, it'll just Reformat it to whatever the team's prettier is if you want. That scares me.

It is a little harder if you're doing, like, a pair of programming, though, so I could see that. Yeah. Oh, that's interesting. I turned on line wrapping right now. I'll see if I can get used to Not having, like, having lines that are, like, fake lines.

Oh, yeah.

Next one is and this is one that I Thought about myself the other day. I was writing a massive split filter, map map map. And, basically, it was I was getting this massive block of text, And I needed to split it based on tabs and then split it based on colons. And I was trying to, like, take this massive block of text and making it into a JavaScript rid object because it had a whole bunch of data in there, and I was just kept chaining. I would, like, take what I want. I split it based on on a new line, and then it looped over rich line and split those, and then I called flat, and then there's a a flat array again. And then I filtered it for empty ones, and then I rid Mapped over it again, and I split it again, and I fly. And, basically, I had, like, 20 of them, and I was like, I'm pretty proud of this. And I was gonna tweet it, And then I stopped, and people are gonna be like, you could do that in one reduce.

It's much faster. And then I was like, no. I like When performance is not an issue and even then, like, I hardly doubt I'd be in many situations where this would be a performance hit, I much prefer doing multiple ripped. Split map map map filter

versus 1 massive reduce. What about you? You're wrong. I prefer chained straight up all day. Chain them up.

Rid I prefer chained. I don't know why. I I just don't mind, especially, you know, in, like, React components too when you have, like, here's some data. I'm going to filter it, Then I'm going to map over it, that sort of thing. That's really nice and easy, nice and simple. Then I don't have to Create a pre filtered variable upwards in the component somewhere else.

So Yeah. Explicitly in React components, I'm always changing them or chaining them, but to be honest, mostly, just about all the time I'm chaining them unless there is, like I would say maybe I have a max depth of, like, 3 chains. If there's more than 3 chains, sure. Then that that's getting a little difficult to parse. But if there's 2 or 3, I'm gonna chain them up. Rid. Oh, yeah. I I like doing even more than 3 because you could comment every single one. And, also, it makes debugging a lot easier because you can Every single line is a new step in the process. Oh, wait. Did you say that you liked chaining them? I thought you said you didn't like chaining them. Yeah. No. I said I liked it. I'm so I'm so wrong. I'm sorry. I I said that about you.

No. No. I'm a big fan. I don't know why I heard the I heard that incorrectly. My bad. Yeah. I have a little example in the show notes of of the code I wrote the other day. Oh, yeah. I'm seeing that. I just thought that was something that you didn't like.

Oh, no. That's the code I wrote.

Okay. Next 1 is going to be, index dot JS file. Sometimes people use them as even like a So there's there's 2 ways of doing this the way that I see an index dot j s file being used. An index dot j s file could be, say, like, component name dot j s versus component name forward slash index dot j s. Both of those imports are going to look the exact same on the user's end. When you're importing that, they're gonna look the exact same because rid When you have a folder, you import from that folder, it automatically looks for the index file. Now me, personally, if That is the way that people are doing it. I'm always using component name dot j s because the index is not searchable, and you can have you ever tried to do rid. Command p for index in your text editor to to find file by index or even a good example is us. We have 800 files named resolvers.ts in level of tutorials code base, and I've been slowly renaming those to be, you know, tutorials resolvers because I've just gotten so rid Tired of files that have been named the same thing. They're not the same thing. They shouldn't have the same name. It's so tough for me to to navigate some of that stuff. So if you have a 1,000 index files, that's gonna get really Thinking obnoxious really quickly. And, also, it's just an extra file you have to create or an extra, like, nested folder structure you have to create. Rid. There are instances in which I do use the index dot j s, and I use them in Beryl files that they're called. A Beryl file is basically an index file that Imports a bunch of other files and sort of acts like a module endpoint so that way you could import from folder. Like, a good example would be, I have an elements Folder, which is all of our components that are elements, like, yeah, style components.

Those are all in their own files, and then I have an index rid barrel file that slurps up all of those exports and then exports it from 1 file. That way, I can just import blank from elements Rather than having to deal with any of that stuff. But if this is the the manner in which you're just having a folder of the component name and then an index file inside of that. No way. No. Thank you. Yeah. Versus Code

does a really good job at differentiating The files, if you have the same name. So if you have 2 index dot HTMLs or 2 index dot JSs, either you open them up in tabs Or if you open them up in your command p, it will show you which folder it's in, but I still don't find that good enough to justify Putting index. Js ever. I hate that. It's too confusing. Especially, like, in tutorials, people get really confused. So even if it means that I have a folder called Drop down, and I have a file called drop down dot j s. That's totally fine by me because it is much more descriptive Even with the double drop down in that thing. So Same z's. I do not like index.js.

I'm surprised because you used to be all about the index.js. Rid about jazz? No. I'm only about it for barrel files. Oh, okay. Only about it for barrel files. That's it. Only about it. What else are you only about, rid Scott. I am only about

one of the coolest new additions to the level of tutorials coding platform that we made rid Was a change to use our video provider as Mux.

And Mux, that's m u x. Let me tell you about Mux because we've been using Mux for a little bit here, and, the experience has been absolutely fantastic.

What Mux is? [email protected]/ syntax is a developer first video platform.

And what do they mean by that? Well, ready. It's finally tuned for to be, like, an easy API for developers to work with. I really tested out a ton of video platforms, and what I found is that they're all a giant PIA to work with, except for monks, which I found to be very, very easy and fantastic. And This is me talking, you know, straight from the hip. This is something that I use personally and found this to be obviously the the best platform that I tried because we went with it. And then when Mux reached out to us to sponsor this podcast, I was like, oh, man. I got so many positive things to say about Mux. So, let's talk a little bit about Mux, what it does. It makes amazing video ready. Is easy. It makes the hard stuff difficult with video. You can serve up whatever video format is correct for your user, read. And it does this on the fly using this, like, immediate transcoding, and it transcodes chunks and does this, like, really neat thing where, basically, If a user requests a video at a certain resolution, the Mux will create it on demand at the time when many other video hosts, what they do is they rid That's a tall ingest process where you upload your video to maybe, like, an s three bucket, and then it chunks through and creates 10 different versions of that video, and then you gotta rid Pay to host all those versions. Well, Mux only creates it as you need it. Therefore, so you're not paying for stuff that you don't need. There's also a really awesome rid Some data platform that can be used with Mux as well so you can get detailed analytics on who's viewing your stuff, thumbnails, animated GIF previews, You know that little, like, thumbnail scrubber thing that you do when you hover over a video play bar, and it gives you a little thumbnail? Well, you can do all that more with Mux, and it's Just so, so effortless and easy, and you don't have to sacrifice what video player you're using. It works with just about any video player that supports HLS video. So it is really stinking cool. Head on over to mux.comforward/syntax if you need to work with a video. Let me tell you, there is no more modern solution than Mux.

Alright. Let's get into some more of these here. Yeah. I think we should pick Let's just pick a couple. I'm picking one of mine here that's that I'm I'm really bullish on. Ligatures and fancy fonts. You would not believe how many people I get Comments in my YouTube videos and be like, I like this video until I saw the ligature. I'm like, okay. Let me tell you. As somebody who is visual, Facial, whatever. Those ligatures, they really help me out. Right? Those those patterns. Because when you have an arrow function, right, the arrow in the arrow function is not I mean, syntactically, yes. It's an equals and then a greater sign, but does that have the same function as an equal and greater sign that you're used to? No. It doesn't. An arrow that's pointing to the the function. Right? So for me, those ligatures where it combines those 2 fonts into or those 2 characters into 1 character, that signifies that this thing is its own thing, and it makes finding, like, triple equals versus double or not equals. It makes read. Reading all of that way easier. Also, cursives and whatever. Like, you use operator mono. I use Mona Lisa as my font. Both of those fonts, they provide some really, really nice cursive base or or or changing your syntactical elements up. And, again, what it does is it just Provide you another layer of visual feedback. Some people just see it as noise, but for me, I really, really latch on to it and like it. Yeah. I'm not a disagree. I don't I don't Like, look at yours. I think they look cool, but

I think that it I have to do the oh, okay. Man. The arrow rid is equals open angle bracket. So I've stayed off of ligatures That's crazy. For my own. And I don't know that it's a big deal for rid. For people that are learn obviously, you'd know you're doing it, and people don't don't complain all that much. No. One one of the things we had here is the usage of a fancy font. I really struggled to read your code samples due to your fancy font. When I picked that font, I I taught with it for 2 different, Like, 60 people, and I said, like, hey. Like, what do you think? Is this hard to read, or does it provide a little bit more context? Like you said, Scott, the The cursive and the colors that those can provide more information, especially with some of the the new Versus Code updates that I was talking about earlier. Rid So yeah. I'm gonna say no ligatures, but, yes, fancy font. That's fair. Yeah. Hey. We found, some things we disagreed with. Yeah. Finally. Yeah. There you go. Dark mode and look at yours. Yeah. Wild.

Next one is, if you are declaring a function, do you use a regular function Where which is just the word function. Hey is the name of the function. Do you use an anonymous function and stick it in a variable? So const hey equals function, rid. Or do you use a anonymous arrow function stuck in a variable? So const hay equals an arrow function.

And this this is not one that I'll I'll die on, but this is a very strong preference to regular function by default. Rid I I think when we got e s 6, people went a little crazy with the arrow functions and did everything, and I'm sort of swinging back the other way. Arrow functions are awesome, and I use them for rid. Lots of inline stuff or little implicit returns and and whatnot.

But if you are writing a function to do something and it's not inside of another function, it's not rid On a click handler in line, I go for the regular, the word function, and I can't stand it when people do the especially with the implicit return, in React components where they say component name equals implicit returns, it's hard to debug. It looks funny.

Also, with what

hooks, rid. You kinda have to go back to regular functions as well. This is one of the ones that I am not afraid to say that I've changed my opinion on this. I mean, I think you can probably find some older syntax episodes where we, said that you know, I might have said I used arrow functions for everything. Now that is very not the case. I do primarily use the function keyword rid to define my functions, and I heard that they were easier to debug that way. And while I have not necessarily paid enough attention to find if that's accurate or not, I have just stuck with it. It reads nicer to me. It isn't any more difficult for some reason. Okay. I used to like the way that the arrow syntax work. I use the arrow syntax again mostly in line, mostly as callbacks, those types of things. Yeah. And and if I in fact, If I see, like, the function keyword in a callback or something like that, I will change it to be an arrow function because I do greatly prefer the arrow functions inside of that Specific use case. But for the most part, if I'm defining any sort of functions, even React components nowadays, I am using the function keyword specifically.

Beautiful.

Yes.

We can do one more, and this is explicit return versus implicit return. Hey. How about that 1, Yes. Explicit return is when you use the return keyword.

Implicit return is when you have an arrow function without the curly brackets, And you just return that result.

Now my potentially spicy opinion on this is that I use both of them, and for the most part, I almost Always use explicit returns except for when it can be a little one liner and something really nice and simple, rid Maybe even specifically a React component. You often have an arrow function there on, like, a map or something like that, and then you're just returning components anyways. Rid I will always do an implicit return for that, but even just like little small filter things or something like that, if it's a one liner, rid. I will use the implicit return,

and I won't feel bad about it. I agree with you there. I have a ESLint rule rid That will turn my explicit returns that could be implicit to implicit, and I don't like it because sometimes I I I think I'm gonna turn it off because sometimes I wanna co put a console log or make it variable.

And what I found is Versus Code actually has a Code function built right in or code action, it's called, and it will turn it from an implicit return to an explicit return rid just by hitting command space or command period, and it will switch it over. And I I was, like, tweeting. I was like, somebody should make a a extension that does this, and rid. Someone's like, it does. Versus Code does do that, and everybody was really surprised. So I'm the same way with you. If it's a one liner, I think implicit return is fine.

Rid. Otherwise, if it's multiple lines, the chances of me needing to console log something or create a variable before that thing is high, So I much prefer The Return.

Even though it's a little bit more verbose,

I'm on board with that. Yeah. You know what? Rid. I would never have a rule to enforce it either way because it like like you said, it probably would get very annoying very quickly to me. Yeah. It's annoying. Yeah. So I I don't have a rule for that, but I I do I I use my discretion, which, you know, may be better or not for standards. But, for the most part, I I haven't gotten me in too much trouble.

Alright. Well, there's a couple more here, but I think we'll, we'll save them for next time. Let me know if you like that type of, I don't know if there's very many more things that we could bike shed about, but maybe there's enough here for, a hasty if you enjoy it. Yeah. I think there's Infinite bike shedding possibilities, Wes,

as we've seen on Twitter.

So now's the part of the show where we get into sick picks, where we pick re Things that we find to be pretty sick. Sick as in cool, maybe not sick as in sick. So my sick pick today is going to be related to what I was talking about at the jump. It's gonna be my yard equipment, is my EGO products. I have been using an EGO lawnmower, that's e g o, re Ego Weider and an Ego Leafblower, and they all share a battery ecosystem.

The batteries weigh an absolute ton, And, that's usually pretty good because they they have a lot of battery, a lot of energy in those batteries. So I can get several moes out of one charge of my battery and stuff like I mean, the products are really good. So I have been very into this brand. I will not suggest buying them from Lowe's because that's where they have a deal from. So I could have a, a link to Amazon or something like that. But these products, again, I have the lawnmower, the weeder, the, the leaf blower, and they're all re Hyperpowered. In the past, I've had either gas or crappier, like I mentioned, BLACK and DECKER ones that just didn't have the power, but, like, All of these things are the most powerful power tools, yard tools I've ever used. They are just absolutely beasts. And at the same time, you're not Sucking in a bunch of exhaust. You're not polluting the environment, and you can use batteries. So imagine smelling fresh cut grass as you cut the grass. That's the best part.

The people that use WebStorm are gonna start coming at you because Milwaukee is better. It's the same same,

overlap of people. Does Milwaukee have Yard tools?

They have everything. It's unreal. My brother-in-law has the pole saw, which is Like a chainsaw on a pole, and he brought it over. And we were just trimming trees all over this place, and I was like, man, this thing is awesome. That that's I have a DEWALT stuff, and rid The DEWALT stuff is really, really good, and they have a lot of really good options. But you can't take a picture of a DEWALT stuff without the Milwaukee people coming out from rid. The woodwork been like, it's better.

I I reached peak dad mode the other day on a vlog because, like, you know, we have a I mean, we're in downtown Denver, so it's not like we have a ton of property or something. We have a pretty small lot. Right? And rid. There's some guy using, like, a chainsaw to cut down part of his tree, and I was telling Courtney, I was like, I don't really use a chainsaw. And I was like, wait. What rid What absolutely would I do with a chainsaw? There's like, I have no usage for a chainsaw whatsoever, and I I, like, quickly brought myself back down to reality. But it's It's so funny. I would you know, I was a punk kid. I went to punk concerts, and I could never imagine myself being like, I need your art tools.

Yeah. Man, yard tools? Good. I have I have the chainsaw, the DEWALT chainsaw, and it's awesome. I can't believe how awesome it is. You gotta keep the re sharpened, but that's the same as any exhaust. And it feels less scary than a gas powered chainsaw, which it is not. So you have to be careful. You don't Cut your leg off. Yeah. Yeah. That's good to say. I I can't imagine why that would be. That sounds just as scary. I'm gonna sick pick a tool as well, and these are just rid. I'm not gonna pick a specific one, but just the idea of a tool is a pass through socket set. So if you have a regular socket set, You'll know that sometimes you are working on something, and you have a bolt that you can't get to or you have a bolt where rid. It is very, very long, and you can't get the socket over top of that bolt. And then you have to resort to using a wrench or adjustable.

So a pass through socket set rid Is you'll have to Google what this is to really understand what it is. But, basically, the sockets go into the wrench and not on it, And then they are hollow so that if there's a threaded rod or a really long bolt, it will just pass through the socket and allow you to use the the ratchet on it. I found a set at a yard sale for, like, $3 last year, and I was working on something this weekend.

And I used it, and I was like, this thing is awesome. I can't believe that I have never used this before, and I can think of, like, a 1000 situations where I had to switch to a wrench because the socket set wasn't working for me. So, yeah, if You ever if you ever see a good deal on a pass through socket set,

grab it because they're awesome. You know what? I this is not necessarily a sick pick, but along the same lines, you might be interested in this. Rid A socket adapter for my Yeah. Drill Must have.

Yeah. It's a must have. I you know what? This is sorry. This is so off topic, but We we had bought a fridge from Lowe's, and they've now tried to deliver it 3 separate times and a failed spectacular on all 3 times. And the 2 times, I had to take apart our current fridge to get it rid Take the doors off of the fridge, the current one, so they could get it out because if you don't have it properly prepared, Lowe's isn't gonna take it even though you paid for it. I hate Lowe's right now, so I'm very angry at this. So either way, I hate to take apart our fridge, take the doors off as fast as possible. So I I got these adapters that are for my drill, plug into a socket, And, oh my god. I was like, why didn't I have this before? Socket anything is just so annoying, and if you hook it up to a drill, then it's not annoying. Rid So I don't know. Yeah. Let me just tell everyone who's listening right now, you can get them for, like, $3

on Ebay. There's nothing. And re There's all these, like, weird little once off tools that you might need. Or not even once off. I've used I have a couple sets of those that you just showed me, And they are very affordable on on Ebay. It's in the the extensions as well. I actually ordered a set of extensions just a couple days ago, And, they haven't come yet, but tool time, Wisconsin West. Tool time.

Shameless plug. I will shamelessly plug All my courses, westboss.comforward/ courses. You wanna learn beginner JavaScript, master Gatsby, full stack advanced React and GraphQL,

Beginner React or React for Beginners. Check it out. Use coupon code syntax for $10 off. Sick. I am going to shamelessly plug 2 things here. The latest course At the time you're listening to this, not next week, but the right now at the time you're listening to this, latest course is going to be code automation With GitHub from Brian Douglas. Now Brian, he works at GitHub. And know who's better to teach you GitHub actions and code automation than Brian because He's just a fantastic teacher. So we have this course is brand new on leveluptutorials.comforward/pro.

And get this, if you sign up now, we actually have team accounts. So you can sign up your whole team at once, and your Team administrator can your your company can pay for it. Your team administrator can manage the account, and everybody can have an account. So if you are A developer who works for a team and you want your team to sign up for LevelUp tutorials, make sure you send them to level up tutorials.comforward/pro, And your administrator can sign up, invite everybody. It is, brand new to our platform, and we've already had a couple teams sign up, and we're very excited about it. So Check it out. Leveluptutorials.comforward/pro.

Also, I'd love to tell you about the level up tutorials rid Bring sale that's going on right now. We're doing 50% off of annual subscriptions.

Every single tutorial series on the site is on sale, so head on over to level up tutorials.comforward/pro.

And if you are not currently a pro subscriber, hit that subscribe button, and you're going to be getting a lifetime of 50% off until you unsubscribe. So check it out, re level up tutorials at .comforward/pro. We have a new tutorial course every single month. Tons and tons of stuff, So you'll get access to the entire back catalog as well as 12 new additional courses over the course of the next year, as well as a ton of additional features and tools. So check it out. Leveluptutorials.comforward/pro.

Alright. That's it. Thank you so much for tuning in to the Bike Shed today. If you've got your own ant hills you die on, tweet us at syntax f m, and we will catch you later. Peace. Peace.

Head on over to syntax.fm for a full archive of all of our shows. And don't forget to subscribe in your podcast player or drop ready.