Should A New Coder Use AI?

Welcome to Syntax Today. We got a potluck episode for you. This is where you bring the Wes. We bring the answers. We got lots of really good Wes, including somebody tried to hack us, and we dive into the the code that they wrote. They tried to use an XSS, and we'll we'll detail it and sort of explain what that is. Really good questions about, like, are people really running five agents at once, and what does that look like? You know? Like, how do you possibly review that much code, if you're running five at a time? What are the different types of pagination someone asked? Like, there's there's cursor Bos, and there's page based, and offset based, and there's there's infinite scroll, and there's money that is being played into it as well.

Should a new coder use AI for coding? Like, what do you think? Right? Like, if if you're just learning to code, if you you Scott HTML, CSS, JavaScript, should you be using AI or not? Skilling up from PHP and jQuery, someone wants to get a new job, but their their skills are a little bit out of date. What do you do in that case? And then finally, like, seems like you got a lot of side projects and and stuff like that, Wes and Scott. How do you possibly manage that with kids and a Sanity, all that good stuff? So those are the questions. Let's get into the first question, which is from Paige Niederinghaus.

Always submits the best questions. I just went and Node her because I was like, make the job easy, Paige. Yeah. By the way, if you've got a a potluck question you'd like us to answer, go to syntax.fm, and there is a button in the URL bar or not the URL bar. The the menu that says potluck.

Click the button, put your question in the box, and we will answer it for you. By the way, somebody tried to cross site script us, which I put it I put it in this episode. We're gonna we're gonna debug why somebody cross site script us. But the page says, hey, Scott and Wes. I wanna ask if you use multiple AI agents while you're writing code with Cloud Code, Cursor, etcetera. I've become a big fan of using Cloud Code to work on features day to day, but I still don't trust it to write new code unsupervised that follows conventions that are already established in the code Bos, use existing utility functions, keep the code dry that wasn't repeating itself, etcetera, etcetera. TLDR, I approve every code change cloud makes before it does them, and I want to watch it like a hawk to avoid the side of refactoring and rewriting, at the end of the features. Online, however, I see folks are how they're able to spin up multiple agents and work on five separate features at once.

AI companies like Cursor are touting how devs can have multiple different LLMs working on the same feature and then pick the implementation they look best. Yeah. That's that's a thing in Cursor. You can you can, like, set it up to rip Yeah. On, like you could say, hey. Make five, and I'll choose the best. Yeah.

To me, it seems like a recipe for a fatigue from trying to review all of this AI generated, too much context switching, etcetera, etcetera. Am I being too controlling by handling all of my agents to higher standards than ever other devs? I'd like to think not.

And it just goes on to say, like, are you guys using multiple AI agents at a single time? And I I I wrote a bit of a book to this because I I feel like this is is a such a good question for kinda where we're at right now. Everyone's talking about how, like, you just gotta have five running out a single time. If you're not, you're you're falling behind. Totally. But Yeah. I find and I'm curious what you think about this, Scott, is I find that the longest part of AI generated code is on either end. First, it's planning what needs to happen for the thing. So whether that is is code styles, whether that's how you need to actually solve the problem, whether that's what the actual problem is and and how to interact with it and and what packages to use, etcetera, etcetera, that like, making sure that you type everything in what is actually happening and giving it all of the context upfront is is probably takes the most time. Right? And then the second last second longest part is is actually reviewing it after the fact. Right? Like, testing that it actually works, that it didn't make a mess somewhere, that it didn't just copy paste and duplicate a whole bunch of styles and and make a problem for for down the road. But I do. I was just saying this. Like, Scott and I, we're working on this, like, syntax code base. We got an episode coming up on that. But that was a code base that was, like, very well defined with, like, how how pages are made, how components are made, how CSS is done, how mutations are done.

And because Scott spent a whole bunch of time upfront Scott of, like, detailing how how rigid it it will be, I found that it did a very good job. Not perfect. There's certainly some messes that we Node. But I think it it because it was a had everything sort of documented as to how it should work ahead of time, it it actually did a better job than a lot of these other, like, greenfield projects where it just kinda goes nuts on it. Right? So multiple agents at a time. What do you think? I am not at a spot where I'm running five of them at a time because simply, like, the actual generation of the code is not the the slow part right now. Right? It's it's simply the two things that I talked about. So much of software development is not just writing code. It's it's me thinking about, like, what's next? So what I'll do is I'll let an agent rip. And while it's working on that problem, I will then shift to looking at, okay, what am I working on next? How should I approach something? What needs Can I log some issues? Do I need to talk to somebody on Slack about this the specific problems? That is where I find it really, really helpful Wes I can, like, just, like where time where I would normally just be, like, actually writing the code, I can then just, like, while that thing is running, I can go switch to what is next. And because of that, I can often, like not running two or three at a time, but they do overlap each other. And a lot of that work tends to overlap each other and thus make it faster.

Yeah. You know what? It depends on on what it is. The things that I care less about, I can run more on. Projects that are either personal software that I I don't care how sloppy it is, Sure. I can run a whole bunch of stuff on it at once and just be like, oh, as long as it's going wrong, fix it. Blah blah blah. But, like, for real software, for real things I care about, no. No. And and I am on it pretty hard. In regards to your point about the the SYNHACKS, you know, making messes and stuff, part of the reasons why we had messes even with was Node even due to the AI. It's because the scope of the project had changed a lot. There were established patterns in the code, that needed to adjust quite a bit. And, like, because of that, I think these would have been bugs and issues that normal devs would have had as well as AI. So, like, to me, like, the I I I wouldn't have even assigned a lot of the issues that we had there to be those types of things.

You're a 100% right. I had a a tweet, the other day that was let me read the tweet here.

Let me just read my own tweet to validate this here, which is, some of y'all I use y'all ironically. But, some of y'all have AI doing everything for you and are still lazy. And that is exactly what I'm talking about with this tweet in this situation because the work up front and the work at the end greatly impact the work in the middle.

If if you plan, if you have strong preferences, if you have things laid out, if you have good patterns already established in the code base, if you have the correct context priming and all of those things, your end results of working with the AI are going to be endlessly better. Not only that, if you have a very clear understanding of the task at hand and how to solve it, the results are going to be way better as well. We should do a whole episode on this. In fact, I've been planning one on, like, working with AI tools effectively encoding. Some of the biggest problems people have in this regard in terms of being lazy are, one, assuming tools are going to fix all of your problems. You're just gonna say, I'm gonna throw some skills or some MCPs or some some whatever at this thing, and it's just gonna do it. No. You need to have clear instructions.

You need to know what you need to accomplish. And if you don't know how to accomplish it, you need to work with the AI to do that research upfront. Because I think some of you all are are using these prompts JS, like, make this feature, just go do it, you know, and then not being happy with the end results. Because the AI will be lazy. It will duplicate utilities over and over again, it will write sloppy code in various ways. The tools can help, but they're not going to save you. Doing that work up front is going to be the thing that makes it possible. When I started on the SynHex platform, I wrote such detailed by hand planning documents of how the flows work, how the game works, all that stuff.

And, I do think that helped any kind of AI work that we did with it to complete things because it had that information there. Yeah. So it depends. Like, I'm not typically, doing a lot of agents YOLOing on stuff. I'm not gonna throw a bash loop and give it a name of the AI repeatedly working on something. I'm going to, validate these things every step of the way, for code, and I'm gonna do the work upfront. I'm gonna give it clear prompts, and I'm going to have very clear instructions. Speaking of which was Mhmm. You know what does a great job of this JS Sentry.

And Sentry actually just has a new CLI that came out, the Sentry CLI, which is really, really good at this kind of stuff because it can give you the root cause of bugs and, it uses the seer, their AI seer, to give you the root cause of a bug and return that directly from the CLI, which works really well with some of these AI tools because you could say, use the Sanity CLI, get me all of the errors, catalog them as tasks, and however you manage tasks, I use something called decks, and then use the, CSS root cause in the descriptions. And then you can go and have that fix bugs really easily. So Sanity does such a good job of having all that information.

But, again, to to reiterate my point, you're priming the AI with all of the the information that's needed. It has the bug. It has the root cause. It has the files. It knows what to do. It can go off and do it. And if you don't do that work upfront either by hand or with the CLI or with Century or whatever,

it's just not gonna work out as well. One more thing I'll I'll say about that is, like, that's more that I think the use case for running multiple agents at once. It can even be, like, be automatic. Right? Like, you could just say, like, oh, if something's logged in in Sentry, just automatically maybe try to suggest a a fix. And sometimes it's as simple as just, like, checking if a property exists before assuming that it that it is there. Right? But, like like, a lot of people and I have not gone down this path yet, but a lot of people are, like, setting up multiple work trees on their thing. So, like, a work tree ESLint Git. If you check out a work tree, you're essentially just, like, duplicating the code into a second folder. So you can have, like, two or three versions of your code Bos running on your computer at the same time or, like, wherever it is that you're running these agents. It might be in, like, a cloud as well. If you set up your, like, thing properly, with, like, work trees and your npm scripts are aware of of the work trees, then you can run multiple at a time, but I've not gone down that path just yet. One more thing. I know we're talking a lot about this, but I I think, like, another huge use case is simply just, like, those bugs that you have been meaning to fix for a very long time, but just, like, haven't got around to it because it's like, I don't know, takes a little bit to get set up. You gotta research it. You gotta and it it might be relatively two or three line fix, but the the overhead of just having to get into it is the reason why you just never go and fix it. That is such good stuff that you can just set an agent on and and let her rip. Like, even what do we have? Like, the sound was too loud on on on one of our, like, audio things that played.

And, yeah, I coulda, like, branched out and and made a pull request and all that, but, like, just let an agent rip on it, find out where in the code base it JS, and it's just as simple as just one thing. Make the volume 20%.

Boom. Yeah. Let it go. Yeah. Hit the merge button.

Word.

Next question here from Max. I see a lot of websites use pagination or infinite scroll, but I don't think I've seen any good explanations of it anywhere. Why do websites use pagination? How would you decide on a good page side and when it might be a better idea just to show everything at once? Oh, okay. So for me, I'll tell you this. This is definitely a vibes thing. I'm sure there is a hard number here. But for me, it's a lot of dogfooding your own stuff, using your own work, your applications, seeing what feels good, what feels bad. The things that work well for, I would say, something like infinite scroll JS more of like like a feed. Right? A feed is always going to just continue to give you the next thing. It's like a never ending well of content. You can just Yeah. Keep mindlessly scrolling it. Hard lists of Scott of data, to me, that that tracks more for pagination because you'll want people to be able to navigate to a specific page. Like, Syntax has nearly 1,000 episodes now, and we wouldn't put our main listing of all of the episodes as an infinite scroll because you could never say link to page 19 and and get, like, the early or those episodes here or there.

To me, that makes sense for pagination.

However, how many do you have is totally a vibes thing. Like, for instance, the the syntax, listing, I believe, is, a three card

per row. And then, therefore, it makes sense to have multiples of three. Right? It never works with responsive, though. You always got Node, yeah. Yeah. When they go down to two and you've got, like, that weird that weird one thing missing.

Well, you know, you just go from three to to one. Yeah. No. You have some views where this feels absolutely bad. No. I to me, personally, that that's it. And that's the distinction, but a lot of that comes from just using your stuff and knowing what feels good and what doesn't feel good and predicting the needs of your users. Right? We should also say there's there's kind of, like, two types of pagination. Right? There's there's offset pagination

Wes, like, you have listing one to 10, and you have 10 per page, and you click on page two, and then you see 11 through offset. Where offset pagination does not make sense is where the content is updating frequently. Right? So you might be for example, if if you had a list of, like, like, tweets and and those are updating every minute or so, you might be reading page, like, one through 10, and then you push page two. And then the tenth one from the page one is now now the eleventh one, right, because it it got pushed down. And if that's the case, you have to use something called cursor based pagination, where instead of saying give me the fiftieth, one give me 10 from the fiftieth one forward when you sort by date, etcetera, you simply just say, give me all of the items that are between these cursors, meaning that, like, this is the ID of the last item that I saw. Now the next page will be the items that are are after that. And and often, they simply don't even have, like, page numbers associated with them. They are simply based on, like, the piece of content that you are viewing. And and that's helpful if you wanna bookmark something long term, or if you have helpful if you wanna bookmark something long term, or if you have constantly updating data.

My favorite pagination is infinite Scott, but when they update the URL. Because I find, like, a lot of infinite scroll, if you accidentally bump something I was we we were looking at the Restoration Hardware website with my wife the other day.

And they have, I don't know, probably 80 different items in their, sideboards category, side tables and sideboards. And we were scrolling for, like, probably ten minutes, and I clicked something by accident, and it was over. It that was it. I screwed it up. And I had to go back, and I spent, like, three minutes trying to get to the freaking bottom of the thing, and it just kept loading more in. And and what they should have done there is that every single time that you load a new page or you pass a new piece of content, you should just update the the URL with push Scott so that if somebody then refreshes that page, you go back to where you were in that in that specific that was a that was a problem with Pinterest as well. It's it's less of a problem with, like, discovery things Wes you're just like, I don't know. The speed is different every single time that I refresh it. Yeah. I I mean, that that to me JS, like, a clear situation. A product listing is a clear situation where I don't think you should have infinite scroll. That's just me. I think it's fine because, also, people might get to the bottom and not realize there's more. Or, like, every time somebody gets to the bottom, there's a choice in their head that says, do I Scott, or or do I do anything? But if there's always just more that's why, like, TikTok does so well. Right? There's always more. There's always more to consume, and it's very hard to snap out of that loop to say, should I keep going? Other thing is about pagination is that, like, this is maybe less of a problem now, but, like like, ads.

People used to put three items on a page because every time you cut the next, that that's a page impression. So a lot of pagination on the web right now is simply just sticking around because there's somebody that works in ad sales that does not want their page impressions to go down the slightest amount.

Ads. Yeah. Wow. ESLint,

this is a really good question.

How much would you use AI, like Cloud Code, if you were learning to code today? I am learning to code having completed the web development boot camp, JS, CSS, and HMO, and I have a basic level of Python.

I am debating how much I should be using AI to help program in a paralysis analysis situation. Should I fully embrace AI and be prompting what's called code to develop projects, or do I just, like, put that aside and and simply learn it myself? This I honestly have changed my opinion on this many times over the years. Right? Because there's something to be said for, like, no. Don't touch it. Like, learn the fundamentals first and then, like, suffer through that, and then you you can use it. But the reality of a lot of that is that everybody else is using it, and you are probably going to get, like, left behind in a lot of these things. But if you simply are just boop boop boop into the box and and hoping the answer comes out and not actually learning anything and not actually, like, solving any problems, you're not gonna make it. Right? Because there are much smarter people. There are much more experienced people in this industry that will be able to do that as Wes, and they're Scott, and they can they can solve problems. Right? Yeah. Yeah. So, like, should you use it? I think you should use it to help you to research, to find problems, to understand features. I use AI all of the time to sort of supercharge my learning and understanding of of areas that I do not quite understand. Right? Like, you are a problem solver, and part of that problem solver is understanding the code base, understanding what errors might be, understanding how these pieces work together.

And AI can really help you with that. Right? Like, Wes, it can write the code for you as well, but, like, one huge thing is that it can help you figure out how to solve a problem and how to do that research very productively and not get, like, not get hung up on these just obtuse problems. Like, like, we used to spend days. I used to sometimes have bugs that would would, give me days and days of of problems Wes, like, now it's just, oh, what do you think this could be? How did these things interact? You know? Like, help me debug this. Add some logging into here. It's it's just so much faster to be able to do those things. So you have to as a as a web developer getting into this industry, you have to figure out how to solve problems, how how to become smart in this. And and this is a tool that you're going to use how to do this. If you use it simply as a crutch, like, it almost comes back to this, like like, a calculator and, like, learning math. You know? Like, my kids are are are learning multiplication and division right Node. And it's like, yes. Of course, you can just boop boop boop those numbers into the calculator.

Yeah. Right. Spits it out. But, like, you you kinda do need to understand how this stuff works and and why it is working. Not because you're gonna need to do long division one day, without a calculator. You you have one in your pocket. But because the way that you think and solve problems with that in your head, that's such a such a crucial skill for life. So that's that's my thoughts there. Oh, yeah. I have some more more examples here, but you go ahead, Scott. I've been yeah. Yeah. You could continue afterwards. You know, I I think that, like, I a 100% agree that, like, your

brain needs to work through concepts for you to be able to even know, like, what the problems are, what the solutions are, what the general flow is of things. And the way that I use AI personally to help me discover those things without it doing things for me is taking things that are difficult for my brain to really parse and break it down into ways that I can learn more better.

So, like, for instance, Node of the things I I really like diagrams for stuff. I really like bulleted lists. I really like technical explanations and code. What I don't like is big paragraphs of text.

Again, I talk about dyslexia on this show all the time. But when I see a big paragraph of text, I I lose my place in it. I retain nothing. And another big problem is that a lot of developers are not good at technical writing in a way that makes things approachable.

They're either too close to the problem or they're too nerdy to even really understand what the average person is going to think about while they're, like, trying to learn a tech.

Like, people who are are knee deep into difficult technical problems are oftentimes going to give explanations of how things work in a way that makes sense to them. And because they're so much smarter than most people, it's not going to land. So I really use AI to distill not to be like, go into the AI and be like, tell me about this. But to give the AI someone else's documentation that I'm having a hard time parsing and saying break this down into bulleted ESLint.

Create diagrams for me. Create, like, ASCII diagrams of how this thing actually works. What connects? What are the major technical pieces here? What are the things, and how do they speak to each other? Like, those types of of questions that you can ask to the AI when you're presenting it with actual documentation for it to get its information from, and it's not, like, going to be hallucinating.

You still still have to, like, validate these things. But, like Mhmm. If you just ask an AI, like, how does this thing work? It will often just tell you even if it doesn't have the information in front of you. But if you present it with hard documentation and say, read through this documentation and distill it into diagrams, give me bulleted ESLint, technical explanations, blah blah blah, to me, that's how I personally use it. And then that way, I'm reading. I'm consuming.

My brain is doing work, not Mhmm. Just fix a problem for me, whatever. Because you do need to know how this stuff works. Today, you still need to know how this stuff works. One example in the Synhax platform that we we just made on so part of the platform is is taking a target and taking what somebody had coded in in comparing them. Right? We we we export them to a PNG, and then you you basically diff them and figure out what the score is.

And one of the problems we've had in the past is, like, slight variations in it could like like, a box shadow that's 10 pixels more than it should be or a color that is slightly off. Those things can just throw it off, and it's just, like, kinda unfair because, like, you clearly got it, but it wasn't it just wasn't wasn't great. Right? So, like, I I started that, but, like, okay. We need to build, like, an algorithm to compare these two things.

So I I asked, like, look. What are ways to compare things? Right? And and we figured out, like, there's actual pixel dipping.

Just straight up, is this pixel red and is the other one red? If so, then you got it. If not, you didn't.

Then there was also this structural similarity index measure, and then there was also, like, weighting the pixels a little bit differently and and and figuring out, like, if the pixels are up and down. But, like so I researched that with AI, and I figured, okay. These are a couple different ways. So I said, alright. Let's let it rip. Give me example in in each of them, and we can I was able to test them all fairly quickly, and then we realized, like, okay? Like, the the structural similarity doesn't work in a lot of cases. Right? There's so many little edge cases, so we threw that out. The actual, like, straight up pixel diffing, not very good. And then the actual, like, weighted comparison algorithm it made, it wasn't very good either at all. Right? So, like but but that wasn't a waste. That was really quick research that I did, and it was able to scaffold it out. Then Wes did a whole bunch of work or our I did a whole bunch of work on figuring out different weights and and how to weight different types of Vercel. And if there's transparency, we waited a little bit less. And we got it to a pretty good spot, and then we all tested it. And then we found, like, some major flaw where, like, if you set the background image, it would bring you to, like, 98% or, like, yeah, or or background color. We're like, no.

I've spent so much time on just, like, trying to figure out what a good solution for this Wes. And, like, of course, I asked the AI, and it it just kept spitting out these just garbage solutions there. Yeah. And then the actual fix was just, like like, Scott, CJ, and I, we just, like, talked about it for, like, probably half an hour. And we're like, can we scale up the Scott, maybe figure out what the score is with the background? And then but, like, that, like, half an hour of actually problem solving and looking at it and figuring out, like, why is it causing this? What are our possible options? And then finally, we had this idea. We'll talk about the actual solution in another episode. But the actual solution that we came up with, then we just type that solution into the box, and it was able to actually generate the code for you. And it worked it works awesome now. Very happy with it. So, like, that I feel like that's a pretty good explanation of, like, problem solving, but still using the AI to help you solve the problem.

You know?

Yeah. Yeah. I do think that is it.

You you should be, like, using it to help you save time not to to do things for you. I mean, Primagen said it really well. Like, it's making you dumb if you're just letting it push all the buttons for you. Yeah. And especially if you're first starting, man. Yeah. It is crazy. I keep going back to that tweet about people being lazy now that they have access to AI because, like, that really like, with this Claude Bos stuff, man, people would rather hot potato all of their data through Discord servers, through other people's servers when, like, you could just tell the AI to write you a chat and have it available with Tailscale or whatever.

And people are just like, I just want it in my, Discord because that's easy.

Like, okay.

But now you're you're just sending your like, these same people are the same people who don't understand that Yeah. Whatever personal data they're plugging or I or API keys or whatever are not just going now to anthropic and OpenAI servers. They're now Yeah. Going and saving permanently on Discord servers and going through that it's just increasing your attack vectors. It's increasing your insecurity.

Like, you gotta know how this stuff works. You gotta use your brain, people. And I think that's becoming such a a major problem. Just yeah. There there's so there's so many instances of Yeah. The AI people. A developer thinking that I find this stuff so hard to talk about because I'm so bullish on it,

but I also like, I think so many of these people are, like, wrong of Wrong. Yeah. Know? Like lunch. Yeah. If if you think that you're a developer and that it's just gonna do absolutely everything for you, it certainly is doing a lot more for you, and it's certainly affecting the job landscape and and everything in web development. But if if you think that it's going to just absolutely just totally do everything for you and you're gonna just sit pretty and allow it to to do that, you're gonna be in in a bit of trouble.

Yeah. And that's actually one of the things that drives me nuts about people leaving negative comments about us talking about AI on this YouTube channel. We have, like, I feel real measured takes. Not only that, but we we we understand how these things all work and connect.

And you you either get criticized by the people who are don't have the technical understanding and are yellowing everything, or you get criticized by the people who, on the other end, just

see all the other grifters and annoying people and just gonna lump you into that category simply for saying the words AI. Like Yeah. They're oh, you it outputs bad code. You're in trouble. It's like Yes. Yeah. But, also, it's really, really good. Like, have you have you seen some of the stuff it can do? It's very good. I I don't think you're giving it enough credit.

Yeah. Yeah.

Yeah. It makes me frustrated. Cool. Node a non AI Wes. Next.

Yeah. Node an a non non AI question next from Will.

Hey, Wes and Scott. I went the traditional route, CS degree, theory heavy curriculum, solid fundamentals.

It absolutely gave me a framework for thinking and learning, and I don't regret it. But, man, a lot of the practical stuff was left for me to figure out on my own. Yeah. That's totally it. With the job market the way it is, I don't I didn't even bother applying.

I set up my own LLC and started building clients right out of the gate, which meant learning real world development immediately.

For example, in school, client side and server side validation was drilled into us, which is great because we always wrote it ourselves. Zod was never mentioned. Validation schemas weren't a concept, and I heard someone casually reference them after graduating and had to stop to Google what they even were. The rabbit hole changed how I build forms entirely.

Same thing with email. I was taught use SMTP for contact forms and transactional email. Full stop. Bos and forms brief, SendGrid, Postmark, none of them ever came up.

Even more surprising, no one talked about SPF, DKIM, and DMARC, Deliverability

We have an episode on all of those things.

Deliverability wasn't a topic. Spam folders weren't a topic. You just send email and hope for the best. Now I'm about half a year out of school running my own shop, and I keep wondering what else am I missing, what didn't schools teach us that actually matters day to day. You know what's funny, Wes? I was on the board of the web development curriculum, I believe, at the University of Florida. I should know Node.

This. I should. But it was it was just long enough ago, like, ten years ago that I I I've completely forgot. But I used to go to meetings for this thing, and it would be me and, like, six other developers.

I remember just thinking, like, they need so much help with this curriculum.

They're doing things even even back then, and things were moving fast ten years ago. But, like Yeah. Still, I remember thinking, like, wow. This curriculum is so out of date with what I use day to day, what most people are using day to day, the types of technologies that they were teaching, like, web design and Photoshop and stuff like that, even though, like, that was just, like, part of it. And and that this was past the time Figma existed, Sketch existed, Illustrator. We're vectorizing everything. That's beyond the web topics.

So Vercel specifically moves so slow us on this practical stuff, the stuff that you hit. I would say so much of what I've learned that's been applicable in my early career was all learned from mentors and my boss and, like, my various bosses and coworkers at different jobs.

Like, I don't think I would have picked up JavaScript frameworks as early as I did if the guy sitting next to me wasn't experimenting with early Angular or, the other guy was checking out React the moment that it was announced.

So, like, part of this needs to be fixed by having a more solid network of people to bounce ideas off of or people to follow and listen to who are trying interesting and different things. So, like, I I don't have a good answer for the actual question here.

I do think you just need to continue to gain the experience, but don't because you went off to do your own thing and you have your own clients, you have the potential issue of, like, remaining in a vacuum. So just do your best to make sure that you don't get stuck in that vacuum.

Wes, do you have an answer to the actual question? I did I did literally exactly this.

I straight out of university started, like, freelancing, running my own company. JS always, grinds make years when people are like, they should teach x, y, and z in school. And, yeah, but, like, school teaches you to theory, like, how to think, how to research, how to how to tackle things.

And the fact that they didn't teach you Node and, like, all these really specific things technical details. Yeah. Is those are simply just implementation details. Yeah. And there JS no chance that they can fit an entire career's worth of learning into, like, a like, a three hour class once a week. Right? Like, I've taught many people in my life in person and in my courses.

And what a lot of people, like, email me being like, well, I know absolutely everything to be a web developer after taking this course. Like, no. No. Absolutely not. Like, it's going to teach you, like, here's how to put these pieces together. Here's how to learn. Here's how to debug.

And then the rest of your career is simply going to be learning new things. This stuff changes absolutely every single day. You're picking up new approaches. And the fact that you were taught client and server validation, great. Now you can go figure out, okay, what are people actually using? You have to go and build stuff to actually figure out how these things work. You gotta hit problems with spam to have to dive deep into what the hell SPF, DKM, and and DMARC is.

That is your job as as a web developer. So I don't think like, yeah. I think sometimes these these universities, like, teach you old stuff, and it's really hard to keep curriculum up to date.

But I don't think they've really did you too dirty when you like, your job as a web developer is just to get out there and and to just consume all of the stuff and to learn it all. So yeah. Yes. Trial by fire. Someone tried to XSS us. I thought this was kinda interesting. We'll put we'll put the, thing up on the video, but I'll explain it as well JS when people submit potluck questions, you can type whatever you want in the Bos. And somebody wrote, closing text area, open script tag, fetch webhook.site forward slash some URL, and then encode URI component document dot cookie. So what they were trying to do here is they were hoping that we were pulling in this user input and simply just setting it as as HTML. And this used to be a much more prevalent thing where frameworks didn't take care of it for you. Meaning that, like, if you are displaying some text JavaScript code on your your browser. Right? And and what this one was trying to do was to try to run a script tag that, when loaded, runs a fetch request, takes the entire document cookies, not server side cookies, just just simply client side cookies that you can access with JavaScript, and then send them over to this random website, which it seems like it's been taken down already. Probably Wes some sort of bot, but that was kinda interesting. And if we were to ever build something and, like, we've done this in React. We have something called dangerously set inner HTML. That's exactly why it's called dangerously set inner HTML. Because if you were to take this comment and dangerously use it as HTML instead of just dump it into, like, a React component, then it would Yep. It would execute the JavaScript and run that fetch, and you would be be out of luck.

So kinda interesting one. You don't see XSS too often because, like, all of the frameworks make it very hard to actually XSS yourself.

But it's it's still doable, especially with, like, a lot of these, AI agents where they are returning markdown.

If you're not properly sanitizing that markdown, that could have, like, a script tag in it, and then that would execute when it's turned into HTML.

Yeah. Alright. Next one from Talks Ixnilot, which is a Scott Tolinski backwards, apparently.

Syntax history question.

When you first started the podcast, who was on your list of potential cohosts, and who did you consider, like, adding a third host? I will say this.

When I independently came up with all of the ideas and concepts of logos and everything for Syntax on my own independently that didn't happen, by the way.

I I thought of every single I think Wes was the last person, on the list, and I didn't consider him until everyone else had said no. The podcast did not exist in any form outside of Wes and I, having good vibes and having a good rapport and being fans of podcasts and having strong opinions on podcasts. If it wasn't Wes,

I wouldn't have done it. I didn't even consider. Yeah. Yeah. Not literally nobody. And I I think that that's just so much more common in the industry. Yeah. Sometimes people have ideas, and then they go search for the people.

But often, a lot of great companies, a lot of great projects, they simply just come out of two people shooting the shit, chatting, and then realizing, we think the same way. We would work well together.

We should we should do something. So that was I thought that was kinda interesting one. The fact that it was organic

makes it so much better. All of the best things in media, art Yarn organic.

You Node? Like, I'll never understand when there's, like, in in music, when somebody is like an industry plant and becomes successful like Drake. Right? Like, how do people sucks. Yeah. How do people fall into that and be like, oh, yeah. This industry plant, that is, like, the art for me. Like, that just speaks to me. This person who is most people, unfortunately.

I it is. Like, in the AI music on Spotify Ugh. Kills me, and it's so popular.

Musicians, all the best bands were just people who found each other organically, and it worked.

So, like, I'm not calling this podcast Yarn. Node. I am. I I just think that that's how it operates for me personally.

Yeah. I and for me as well. Like, I I don't think that I would be able to disingenuously do something like that, like like, be an industry plant or like, you see it on TikTok as well where where people are able to simply masquerade as something and it make it work. One really interesting thing is is Finn McKenty. He had this YouTube channel called punk rock MBA, and he I don't know. Almost half a million subscribers, hundreds of videos about the history of of punk and hardcore and and everything like that. And then one day, he simply just stopped and said, I actually wasn't really into that music at all, but he just, like, was just JS crazy like, knew everything about it and did amazing research. And I don't know if that is true or not, but part of me like, I know the guy, and I I think, like, part of me thinks that it is it is true, and he figured out this one industry, which is crazy to go into the punk hardcore scene Yeah. And just be an absolute not necessarily con, but just like, I am doing this because I realized this is a niche, and I am going to absolutely kill it in this niche.

And he did that, and then he stopped, and he's like, I'm gonna do something else. Like, I I did really well on that. I don't know if I could ever do that. You know? No. That's not for me. Yeah. The vibes has got, like, Scott vibes has gotta be on for me. Yeah. Yeah.

Christian says, hey, guys. I've been working as a front end dev, small software house for about five years. I'm looking to move to a larger company I'm finding difficult given my background.

I'm overqualified for junior roles, but due to the tech stack Pnpm and jQuery, I don't fully meet expectation for mid level positions in bigger companies. How would you suggest approaching the situation? I feel like we've we've talked about this 7,000 times on this podcast is that you are a problem Vercel, and your tools are are out of date. Alright? Obviously, people still use PHP, but, like, that stack of PHP and jQuery is is very old by now. Right? Like like, we Yarn many like, React is what? Like, twelve, fifteen years old by Node? Your tech stack is out of date, and and you need to scale up and and very quickly on on modern tech stacks because that is a like, you probably have several decades hold of, like, you probably missed two or three waves. You know? You missed GraphQL.

What else what else did you miss? You know? We're on local for first Node. So I would probably you just have to you just gotta build the side project. You gotta scale up. You gotta get better at these things. You gotta build something. And if you can't do it at work, you gotta go and build a couple little side projects so you can scale up and understand how these things work. Right? Like, I would probably do a good balance of keyword stuffing because, like, this is don't choose I'm I'm curious what Scott thinks as well. But, like, if you Yarn going to build a side project, you kinda have to aim it at what do employers want, and not necessarily just what you personally want to use. And I think today, that would probably be React, Drizzle, or Prisma using vanilla I just said Drizzle.

And Tailwind. Yeah. Yeah. See, this but, like, the thing is is that Prisma is even if you don't like Prisma, it's absolutely huge and used in so many massive companies right Node, and that's that's a a very hireable skill. Node is really popular, and then, like, you have to scale up on using AI APIs, so integrating these AI LMs into products JS well as using LLM AI coding tools to to build your things. I think if you were to get good at all of those things, you'd probably be ready for applying to these mid level jobs. Yeah. I am I'm the worst person in the world to give this advice because, if you don't know some, like, obscure, unreleased library that has eight downloads.

Yeah.

Yeah. It it is so funny. I was just talking to Courtney about this, and I was talking about the Claude Bos stuff, which is now OpenClaw. And I was she was like, well, maybe this time, you being, way too early on something will actually come in handy because of It did. Yeah. It did. Yeah. For sure. Yeah. Very funny.

Like, that is a problem of mine. I I I'll just I'll agree with whatever your take was here, Wes, because otherwise, I don't I don't think I have a good one. I like the the cutting edge stuff as well too. But, like, if you're if you're trying to feed your family and get a job, like, you have to kinda look at like, there's the old saying JS no one ever got fired for recommending IBM. Yeah. And, like, you have to understand what are these larger companies that don't move as fast as us using.

I have the issue of I I was described by one of my professors as quixotic to a fault, where I'm so overly optimistic about things like, oh, of course, this tech is gonna take off. Oh, of course, this is the way. Of core like, I I am firmly optimistic in those ways, and that leads to me to become supremely blind as to practical choices on things. So I I'm not the most practical dude. That's definitely the truth.

Next question here from John Love.

I've been following you and heard that you all have kids, jobs, and a lot of side projects. I am in a similar boat, but I have no idea how to make a time to truly dive deep on a side project or learn how to set up hardware, How are you able to balance your time between family, work, and extracurriculars, so to speak? The the biggest thing for both of us, I would say, is that a big part of our jobs is to explore and to learn and to teach. And you don't do that without getting deep into side projects as a part of my job.

So while I am maintaining code bases and I am working on things long term and managing the syntax team and that kind of stuff, that does take up time. But I would say and, obviously, recording the podcast, I would say it's still a good 50% of my time is spent exploring and diving into topics and getting to work on side projects as a part of my actual job.

So the things outside of that, though, oftentimes Node Yarn, like, diving more into, like, what are things that I can do with my kids? Like, my three d printing stuff JS entirely like a project to do with my kids from the start, to the point where both of our kids can load and unload the three d printer. They they can do things with it. They can choose what they want to print. They can explore ideas on it and those types of things.

Node side projects oftentimes Yarn, like, the things I actually process better. Like, for instance, a thing I just built that was, going to be very useful to my wife and I is we're going on a a big trip this year to celebrate our fortieth birthdays.

And I was like, you know what'd be really cool? It'd be like a trip hub where every single day of the trip has the itinerary.

It would have on maps all the locations.

And then if you select a day, it would have all the addresses and phone numbers of anything you're doing that day. It would have budgeting built in so you could see how much the entire triple cost. I could use AI to estimate costs of dinners and stuff like that. Like, point it to the restaurants and say, hey. Estimate me a cost of dinner for all these restaurants.

And it's like, that is an app that my wife can get behind because it is, taking the things that I'm bad at, which is planning and augmenting them so I can help her, plan better and, therefore, is an a useful use of my time that's not just me wasting time on my computer when I'm outside of work? Yeah. People ask me this all the time, and

I would say my, like, most biggest frustration in his life is simply just not having enough time to do all the things that I want to do. And, probably, everybody has that. But I don't know, some tips that I do have is I like to start an idea, dive in, master it, and and finish it. Right? Like, I'm not into 10,000 things at once. I'm simply just like, I wanna learn this, dive in. I I figure it out. I move on, and and I move on to the next thing. Right? I've done that with electronics, small engines, three d printing, home reno, cooking, like, so many different things. And then I just feel like I have a very good like, I still do lots of three d printing, but I'm not, like, I'm not learning the three d modeling software for hours on end. Like, I I know how to use it now, and I'm pretty good at it. And and when I need to do something that that uses that, then I can can get into it. The other thing is is, like, I go so much based on excitement.

By trying things and and just dipping into different things, you're going to trip upon something that is exciting. And and once you hit that, you're gonna you're gonna find time. Right? Like, it's the same thing with, like, literally anything in life. You know? Like, working out or whatever is, like, as soon as you, like it like, something clicks in your head where, like, Wes. This is this is great.

You're gonna you're gonna figure out how to find time for those types of things. Right? Like, sometimes I have, like, four hours of screen time on my phone every single day, and I'd sit in front of a computer all day. Right? There's probably an hour or two there that I can can squeeze it out. Right? Next step is asynchronous learning. Like, listen to podcasts, YouTube videos.

Like, there's so much dead time that you can have asynchronous learning, whether you're driving or just, like even just, like, standing in line at the grocery store. I will just whip open an article and just, like, just starts pnpm through it. You know? Because it Wes, can I

interrupt here with something that I did yesterday that I'm not super proud of? There was a a long line at the pharmacy at Target, like like, 15 people.

And since setting up my Tailscale network, I have OpenCodeServe running. I was vibe coding in line at the pharmacy.

Instead of just, like, existing there, I was, like, prompting AI agents to to work on something stupid. And I'm just thinking to myself, like, I can't shut this off right now. Why can't I shut this off? That that's a problem, I think.

Oh, that's crazy. My last tip I have here is just cutting out as much, like, stuff that you don't like. Like, I I seem it seems like I like a lot of stuff, but, like, I don't know I don't know anything about movies. I don't know anything about pop culture. I don't know anything about hockey or anything any sports. You just mentioned all the days that I like. Olympics are on. I had no idea that there was Olympics this Yarn. And those are not bad things. Like, I'm not saying, like, don't watch hockey because, like like, well, do whatever the hell you want with your life. Those are very enjoyable things for a lot of people. They are just not for me.

And and I have different weird interests that I'm able to to talk about rather than, like, hockey players and and movies.

See, I need those things. Otherwise, my brain would just be Exactly. Yeah. Like, and you know Yeah. What it is for you. You know? Totally. Yeah. Yeah. That is my get out of my my head

kind of moments that I need. If I have, like, a long stressful day, my go to is not to watch TV, or to, like, watch, like, a brain like, a lot of people are like, oh, I love watching, like, Love Island or, like, these, like, brain dead TV shows because it just is a way to shut my brain off. And I Yeah. If I'm, like, feeling stressed out and my wife's like, you wanna just, like, watch a show or whatever, I'm like, I kinda just wanna, like, write a article or watch a YouTube video on three d printing or something like that. Like, that's what it is for me, and and I know that about myself.

We're currently watching Single's Inferno on Netflix, which is a it's a Korean dating show, which is so I love I love Single's Inferno every year just because it's so different. Like, if you were to put I I always think about, like, you were to put one American on this show, and it would be, like, a a a bomb going off because of Yep. Just how insanely different the dating culture is. It it's so interesting.

But I love I love that kind of trash TV. That's me. Jason Bourne says, I've been playing around with transformers.

Js. This is a JavaScript library that will allow you to, load in LLM models from generally from, like, Hugging Face. It's it's built by Hugging Face, and you can just, like, run them in JavaScript whether that's in the browser or in Node. Js. I'm working on a personal dev site. The idea is to use a small in browser me model, feed it my CV and LinkedIn data, and then build a chat g p t style rag search that can answer questions about my work history, mostly in a fun way to learn rag and LLMs and something genuinely useful for recruiters and potential clients. I've had a very rough working version. I've embedded my CV data into JSON and passed the relevant chunks to the model from console logs. It does seem to retrieve the right context, But the responses come back as I don't know or say there's no context.

I can't tell if this is a prompting issue, a limitation of smaller models, or I need a larger model with better reasoning. So this is kinda interesting. So RAG, what that means is that you take something, like, we use we use rag on Wes don't actually have it on Syntax site right now, but I've used it with the syntax transcripts Wes you take, like like, what's called an utterance, like, two or three sentences that somebody has said, and then you can you you vectorize that. You store in a vector d b, and and that vector is just a a representation of what you said in numbers.

And then you it's it's mapped in, like, a thousand different dimensions, and then you can use vector search to find things that are are similar to that. Right? So you I could search for, like like like, React pitfalls, and then it would bring up all the utterances where we talked about things that are similar to that without actually having to, like, say the words React pitfalls. So what he's done here is he's is he's vectorized his whole LinkedIn and and and cover letter and all that stuff. And then what you do is before you you run the LLM chat, you you do a vector search based on what the user has asked, and then you put those retrievals. It's called retrieval augmented generation. You put those things that you found in the prompt, and then you ask the question given the this data, and it it'll spit out an answer for you. Right? So he's having a problem where it's like, yeah. It gets the right context, but it's it's not doing it. So, like, your rag might not be picking up the right bits. So when I was doing the transcript utterances, sometimes it would find the the actual utterance that I wanted, but it was missing context from, like, maybe what was said before or after.

So I modified it so, like, yeah, you can get the one utterance, but maybe pull the last two before it and the other two after it and then use that as as context. If you are a 100% sure that you're getting all the right context, then, yeah, the model JS probably just not good enough. I don't find that transformers JS in local models is very good for simply just straight up chat. Where transformers JS in smaller local models make more sense is that models that do a very specific thing.

Depth detection, face segmentation, object detection, toxicity detection, text to speech, translation, things that are tuned and trained exactly to do one thing well and not I I find it not as good as, like, these, like, just massive LLMs that you can give a text, and it will return it to you. So, yeah, get a bigger model. Get a bigger model. Yes. Alright.

Last one here is yearning for the past.

The question is why are Chad Whitaker videos showing up on the Syntax YouTube channel? His videos are so out of touch with the rest of the content. I was excited to see another Syntax video on my feed only to be disappointed that it wasn't Wes, Scott, or CJ.

They are who I wanna see and who I wanna hear from. Well, thank you for saying that you want to hear from us. I I will actually talk about the Chad stuff because Chad is a really talented, developer.

He has such a long history and knowledge of open source and does all of the open source funding stuff at Century.

Now, there was an opportunity for Chad to be able to share some of that knowledge on, Syntax. So I I'll I'll say first and foremost that when it came up, to have that opportunity to have Chad share some of his knowledge, he produced a little bit of a pilot for us. And I was like, oh, this is great. This is a change of pace from what we have on the show or on the channel.

It covers things that, frankly, the three of us are not as deep into JS Chad was. And through that process, I do think we all learned that it it wasn't necessarily a good fit despite the fact that I think Chad's content is great, and I I think it's very underviewed. I I think if you're out there, you should go listen and subscribe.

And so because of that, Chad is going to be continuing his content, but he is doing so on his own channel, which we'll link in the show notes. So I I think we got that feedback, but, also, I I do think, you know, you're right. It probably wasn't a good fit because it was too different. And I'll say I'll say straight up, that was my choice. And I I think that I thought it was going to be a nice contrast. But, ultimately,

I think it was probably better, for him to continue producing it in a way that's light. And it's it's doing better on his own channel as well because of the Totally. Finicky, finicky algorithm.

Yeah.

Totally. So we'll link that up. And if you're interested in Chad's stuff, if you're interested about open source Tolinski, like, Chad went to Ukraine and interviewed the Drizzle folks. Like, he's done some amazing stuff Yeah. On on his channel. So follow that channel. He'll be continuing to do it there. But if you weren't a fan of that content for whatever reason, you won't be seeing it JS a part of the normal syntax feed going forward.

Sick picks. I I'm gonna sick pick. I feel like something I've talked about a few times on this show, but I don't know if I truly did it as a sick pick. My terminal screen, you can see it tells me when my next, Penguins hockey game is on. They're playing the Islanders on February 3, and this is just one of the many screens that this little thing has on it. It's a really simple device. It's a e ink with a battery and a USB to charge it, one on and off button. You can write your own software for this thing super easily, and I'm a huge, huge fan of this device. It's one of the few things that I keep on my desk. And, yeah, it has the Penguins game on here right now, but every fifteen minutes, it changes to a different screen, whether that's how many days are left in the gear or my calendar or what the weather is for the next week or all kinds of stuff. And it's so easy to code your own of anything you want on here, GitHub contributions.

I have, like, YouTube subscribers, that kind of stuff.

So check it out. T r m n l. I think this is like if if I would have this for our our gift episode, I would have said this Wes, like, a perfect holiday gift, but I did ask for this for Christmas myself. So, really neat stuff.

Sick. Yeah. I really I really want an e ink display.

That seems so cool. Somebody asked a pnpm up question about a different e ink display, so maybe I'll take a look at that as well. Speaking of electronics, I'm gonna sick pick my soldering iron. So in the past, I have I have one of those, like, USB Bos, like, soldering iron pnpm, and it works great. But I find that I don't always have the right cable for it because it needs to be like, like a power delivery cable. And then I also find that I have to find the power bank, and then sometimes it's in my backpack or whatever. And I find that, like, I don't use it as much because I have to, like, run around looking for everything that I want. So I've had this also, I've had this one for many years. This is a Ryobi soldering iron, and I use this one all the time. It gets hot very quickly, and it just, like, works. So I have tons tons of these Ryobi batteries. You can just slap one in. It's always in my workshop. It has a nice it has a stand in itself. You know? So if you are going to be buying a soldering iron, don't buy one. The ones that plug into the wall are great, but, like, I hate having to find a plug because it Yeah. Same. You can never like, you have to solder it right next to the plug or find an extension cord. The these battery ones are absolutely perfect. The battery lasts, like, I don't know, many hours of soldering. It auto shuts off. It's just a fantastic little thing. So whatever. You don't have to get the Ryobi one or ever. You can get the DEWALT or whatever version of it, but I've just been very happy with this sort of package as a

as a soldering iron. I've been having the worst time soldering. I feel like that is one skill that I've tried to hone. I've watched YouTube videos. I've practiced. I've tried all I'm so god awful at soldering.

I do have one of those. Yes. Not that one in particular, but I do have a feeder like that. Yeah. Yeah. Are you using the little USB c one? Yes. And it gets hot fast. It's nice. It's got a nice little tip on it. Yeah.

Yeah. It's it's tricky. It is it is a hard thing to learn. Mine mine aren't perfect, but I feel like after, I don't know, ten years of doing it, I've I've gotten pretty good at it. Yeah. I've been garbage since day one and and still yeah.

Awesome. Alright. Well, thank you so much for tuning in. We will catch you later.