Panel Episode March 2024 === [00:00:00] Welcome back to PodRocket, a web development podcast brought to you by LogRocket. LogRocket helps software teams improve user experience with session replay, error tracking, and product analytics. Try it for free today at LogRocket. com. I'm Emily, producer for PodRocket. And we're back with our panel episode where we cover a wide range of topics trending in the world of web development, as well as going through some of our guest hot topics. takes at the end about what they're all fired up about in the web development world right now. But before we get into it, let's welcome our panel as always. First up we have Paige Niedringhaus, staff software engineer at Blues and PodRocket host. Welcome back, Paige. Hey, everybody. Glad to be back. Yep, Silence. Chris. Hello. [00:01:00] And finally, we have our full time PodRocket host, Noel and Paul, back as always. Welcome back, guys. Emily. Hey, Emily, excited to get into it. Sup. All right. Let's get into topic one. So the latest AI tool is here and per usual, we're getting cries from web developers that AI is once again, taking their jobs, but with this new tool. Called Devin developed by Cognition, a Peter Thiel backed startup. It's being touted as the first AI software developer. Cognition, CEO Scott Wu said that with our advances in long term reasoning and planning, Devin can plan and execute complex engineering tasks requiring thousands of decisions. And it's powered with all the tools a developer would need and the ability to collaborate with the human user. This includes learning unfamiliar tech, building and deploying apps end to end, autonomously finding and fixing [00:02:00] bugs in codebases, and a whole lot more. So far, the reviews are mixed. AI enthusiast McKay Wrigley praised this as the beginning of the era of AI agents, while Ethan Mollick, a Wharton professor studying AI said, Said that the tool is slow and breaks often, but also said that it's the beginning of seeing AI agents potential. So let's discuss to start off this tool in particular, it seems like a shift in developer tools. Do you see this or do you think that this is just a small stepping stone to a bigger and better AI tool and agent in the future? I would love to just jump out the gate with the people who are always talking about Oh, it's going to take my job. Cause that's relating to the question. Like, you think this is up on that new level? Do you think it's like threatening? And I saw this post on hacker news the other day, and it really spoke to me, which was this person was talking about how, okay, if you're a CEO or CTO and you get this AI and now everybody can do 10 times [00:03:00] faster. And you're saying, okay, great. I can take my 1 million staffing costs and reduce it to a hundred grand. That's small brain activity. What you should be doing is keeping your million dollar staffing costs and then getting a ten million dollar output. And if you're not viewing it that way, then the AI revolution can seem scary. But for all the people who are saying, Oh no, is this going to take my job? Like maybe, but you're not going to be out of work because there's going to be ten times more work at the other end of the tunnel. Now I've not used Devon myself, so I'd love if anybody else here has interacted with it because I am mighty curious from some of the videos I've seen on the Twitter community. Recently. So I think like right now it's invite only so the people who are experiencing it are like the AI experts, but I do think it's interesting that this is seeming to make more waves than usual with AI tools because it is being touted as like the first AI quote engineer. I watched some of the videos on Devon's website to just kind of get an idea of how they're prompting it, , what it's actually doing, and It [00:04:00] was really interesting to see, but I also wonder because, these are short videos that they've made. They're three minutes, they're a couple minutes, they're whatever. How many prompts did it actually take to get to the final output that somebody was asking it to, build a game of life or write some tests for this automated script that I already wrote? I just need some tests to make sure that it continues to work the way that it does. So yeah, it's going to be, I'm sure a change in how we work with tech and how we as developers write code or maybe direct others to write code, but there's still that human input that is needed to actually verify that this is what I expected it to do or this is what my, given my acceptance criteria, if we're really talking like a true development story, that it's doing what I expect. So Kind of to Paul's point, it's not going to take your job, it hopefully will make you more efficient at [00:05:00] your job, it will make it easier to write feature stories, but it's still going to need that human verification, this is what I wanted, this is what I expect. This is what it should be like, or there's still going to need to be input. It's not just going to be robots talking to robots, pushing out code at all times. And we're just going to sit back and let it happen around us. We're not to that point yet. agree. So I feel like this one's stirring up waves because it's like very well packaged, right? Like the presentation's very sexy and appealing. And it's like, Ooh, look, we can solve some surprisingly high percentage of GitHub issues. Right now it's like, yeah, but how many GitHub issues are like, Documentation updates and stuff. Like how long do you have to sit there and curate until you find a GitHub issue, that's actually a interesting. And I think that's like my take overall is every example I've seen, even just like independent people that have been invited and testing it. It's it can do the simple thing, which is cool. Like we spend a lot of time doing simple repetitive tasks, the more we can automate that, the better sure. I think it's cool if I can just [00:06:00] have something spin this up and makes it easier to get my, latest react project going, whatever, you name it, but. I've yet to see any like good examples of like, this is actually a problem that I would need even like a mid tier engineer to come in and solve, like there's some architecture going on here. There's some like thought abstraction. I haven't really seen any cases of that. Especially if there's not like clear examples on the internet and stuff already for this stuff. And I feel as, it being in the software space, like those are the problems that we're actually solving and get paid to solve. Yeah. So I don't know again, it feels like a good presentation, but I have the same kind of question that page is like, this feels very curated, like we can find the two or three cases where it worked really well, right? And use those as our demo. But I'm not holding my breath, nor am I like, as someone who like manages people and works on stuff like, Oh, this is going to change how I interact with my team. I just don't, it doesn't even seem like it's close yet. you're now ready to lose half of your team for AI agents instead. Yeah, [00:07:00] exactly. I guess because it's been about like two years of this hype of AI, and I think now it is becoming like a little more serious is becoming more well thought out and everything. What do you think you would need to see from a tool or a product or whatever that you would be like, okay, this is the next step in AI development that is going to like really Give us the tools we need to be more efficient because obviously this keeps coming back to like it's more about making your job efficient rather than replacing you. So like what as a developer would you like to see from tools like this that you'd be like, this is literally saving like half my day. And is that even possible in the near future? . So one thing I saw from one of the demos is it just does its own debugging for itself. So when it encounters errors, it will actually take that error. Google has like a browser as well. Google find some answers and actually try to fix it. So something like that I found is very appealing to me. Because before, if you think [00:08:00] about the present day, you're going to use, someone's going to use chat GPT anyways, hit an error, And then have to copy and paste the error themselves at the chat GPT. So this kind of helps makes that process more efficient. So I was pretty impressed with that specific demo that it went and figured out its own problems. I can find myself using this for just doing like mundane tasks. Like I could be an army of three people working on my own project. But one thing I want to tap on that we mentioned about jobs is I think this is going to actually help weed out companies you don't want to work for. Because they're going to be replacing people with AI agents, right? When you think about good companies, they hire junior engineers to develop them and, , be part of their culture, build those relationships. But when you replace that with a computer, it's like you don't get any of that. And then further, , the AI could potentially be stuck at a level junior or whatever we want to perceive it as. Whereas with actual human, they can grow as well. I'm not saying the AI can't, but I think it's a lot more meaningful as a Human being to be growing your skills and growing those relationships with your [00:09:00] company. So I think it's gonna be very good to identify like those like toxic employers, in my opinion. Silence. like your call out on culture, Chris, because that's something that it's like the AI can produce something, it'll get better producing something. But producing the thing is not what the job is. The job is communication. It's parsing of mental models of something that a team hasn't touched before. And it feels like it's Not the hard skills, it's the soft skills that really needed to develop to really make it useful and to have it like do something like grow with the team, you have a culture that grows and that's crucial to the success and the morale. I think that there's like a technical. Implication here as well. Looking at a code base somewhere like at a company that has really high turnover, you can see it or you can feel it in the code. It's just there hasn't been a clear vision start to end here, or no, no one around anymore really knows like how this thing works. thing works through and through, you get those really hard questions and no one really can answer them intuitively. It takes a really long time. And I'm just trying to imagine that in a code base, it's like Ben [00:10:00] written and modified and edited largely by agents that like don't have any context. And as soon as you have some problem that like, Is not solvable, like it's just going to be a nightmare because it's going to take so much mental overhead to go in and Figure out this code base that no human has ever really touched this far. And I just, I dunno, I find that terrifying. . It just seems like you're going to end up with this code that is like non maintainable. The Matrix. if this is, yeah. If this is the path forward. yeah, proprietary software, it can't just go on the internet and look up how your internal stuff works. there's all that too. And you just, you really hit a good point, Chris, when you were talking about how we hire people and they grow in their careers, because I learned so much in my first or my early dev jobs from senior devs. We pair programmed a lot. They would, I would ask them questions when I got stuck. It was easy to just tap somebody on the shoulder and say, Hey, I know you worked on this earlier. Can you help me understand what's going on now? And with AI. [00:11:00] Yeah, GitHub Copilot can explain stuff to you, but it's just Googling the internet and then coming back with a response that half the time doesn't fix the actual TypeScript issue that I'm facing and my code won't compile anyway. So, and that, the other thing that I think we forget or we lose sight of is that it's like you, Paul was saying, it's so much more than just, Writing code. It is talking to people. It is working on. It is hearing what users problems are and then trying to come up with solutions to fix them. It is thinking about the larger picture of how does this work. Fit with other pieces of the company or other tools that we have or communicating with your team about what is the top priority right now and developers still have to do all those stuff things, especially as you get higher up in your development career or up the ladder. And AI can't do any of that. It has no clue about the larger picture of the company or the conversations that are happening or what people are saying in some other, portion. So [00:12:00] yeah, this will help with your main focus of code, all the other stuff that we do along with it. This is not going to be able to replace that for a long time to come, I think. So my last question in this section. Do we think that this is the beginning of the era of AI agents? Is this hyperbole? I mean, I think it's like a semantics, right? Sure. Like maybe the agents will get really good at doing monotonous things. Like we can debug quicker because we have an agent that assists us, but does that mean we're in the era of agents? Maybe, I don't know. Sure. It's not as serious. we've had chat Assistance for a long time and I don't think anybody relies solely on those. Very true. All right. Let's move on to our next topic. On March 12th, Google launched its newest core web vital metric interaction to next paint or INP. This was created to replace the First [00:13:00] Input Delay, or FID, and NIP changes the way Google assesses website performance. This change is because FID only measured the input delay of a user's first interaction on a page, which was not useful for measuring the overall responsiveness of a web page. INP, however, measures the responsiveness of all page interactions. Many are saying that this integration will affect how sites are now ranked in search engine results and affect how developers then optimize their websites. So first, can someone explain a little bit more in depth how FID works or worked and what an IP is? So the idea with First Input Delay, or FID, is that it is, as you said, it measures the input delay of a user's first interaction. So a lot of times to look good, websites will have something that loads fairly fast so that users can start clicking around, or they can see some loading screen, or there's something for [00:14:00] them to actually be able to know that the website is doing something, that they're going somewhere. So that's what FID did. And it is, it's a pretty good measure of a site's initial speed, but it's not a great measure of overall responsiveness because once you have loaded something, you actually need to be able to interact, add something to your cart or check a price or. Navigate somewhere else. So it wasn't great at measuring anything after that initial load. And then what INP is trying to do is take the longest time that is observed between users performing an action and then the update to screen. So it's a more holistic view of. You are on this website, and you've been there for a while, and you try and click a button, and it takes, it takes a minute to load you to the next page, or it takes a minute to add something to the cart. And so that's Usually where we are, we get to a website and then we're on there for a few minutes doing whatever it is we're doing. And [00:15:00] yeah, it might have a really fast initial page load, but if I'm searching on Amazon for 20 minutes, looking for some particular thing, and it's really laggy in between me searching for things as I'm going down this rabbit hole. That's not a great experience. And that's what I think Google is trying to take more into account is. Once you've been there for a minute and you're still on the site for whatever reason, is it still a good user experience or is it junky once everything has loaded onto the page and you're in the midst of it? Silence. My take is that I don't know if this is going to be super impactful other than maybe pulling things down that were like, Gaming first input delay a little bit, because if you're designing your site to be like, to feel good and responsive, I guess, if if you're, working on your project with that in mind, [00:16:00] you're not going to know what your first input is anyway. So it feels like this is the benchmark that we've all been striving for. Like regardless, cause like you assume that it's going to be like some element on the landing page, but you don't know what it's going to be. So like maybe there'll be some ranking if there's like really high like a high percentage of traffic that is going to a specific element on a page and a company has been able to optimize that one button. Like those things might, those sites might get ranked a little bit lower now. But I don't know. I don't, I'm not losing much sleep over this for any of like our web stuff, because again, we just optimize everything as we've been going inherently over time. And I suspect that this is not going to really alter, that where this like number comes out, where we fall in that bell curve. Yeah, the one that I think about the most and what bothers me the most are recipe blog websites. Because I'll go, and I'll try to find a recipe for potato salad, and I will get 15 massive, 4000 pixel [00:17:00] JPEGs that get loaded in, and then there's a pop up to subscribe to the newsletter, and then I go down to the actual recipe, and it reloads because some other thing is just loaded in. So I'm hoping, I really, I want the recipe. I don't care about your life story that goes with it, but I'm hoping that somehow this will maybe force them to rethink those recipe sites and maybe not try to shove so much content in that causes so much jank and makes it makes it take so long for me to scroll down to actually find the content that I care about. So maybe it will be beneficial for that, but I think it's going to take a long time because I know those sites have massive SEO juice already to probably get penalized for it and hopefully start going away from that. That was actually going to be my question because as a non developer, I'm like, there are so many sites out there that it's just junk and it comes up on the SERP and I'm like, I, this is not even what I'm [00:18:00] trying to look for. So I guess my question is like, Because, like you're saying, all these websites have been around for years, if not decades, and they do have all this SEO information, they have all the optimizations in there, do you think that changing it this way, obviously, it might be much slower, but we will start to see more accurate results in the SERP, we might see better information, do you think that's what Google's kind of trying to do as well? What are your thoughts on that? That's a good one. So I feel this, the rest of the blog recipe, Site is a good example because I guess my like impulse is that those a lot of those will probably technically have pretty good Fid scores already if they work I can click a link and it loads right away I'm not I in my head that feels like a separate problem from like the performance optimized web app Problem in that like it can take me a long time to find the information I need on a website if like the UX is bad [00:19:00] Regardless of if it's really fast or not, and I can put on my conspiracy hat and be like, Google's serving you these on purpose so they can show you more ads. So you click on more ads and there's like this whole dialogue there, but like maybe this will start to be a thing. I can't, I have to imagine that this is going to become an increasing problem for them over time. I'm just not sure if that is their motive. Here, Thinking from a development team perspective, at least in my experience, like Noel, you mentioned. Yeah. It like app performance is something that if you keep it in mind as a team and you move forward with that, this doesn't matter, your apps already performant, at least in my experience, there's a lot of places I've worked a lot of teams I've worked with where SEO, there's a guy who's like, I got this like, I'm going to make it good. And you're like, Okay, insert name, go improve the SEO. And that's going to be like a narrative that happens less perhaps, because it's more like a conscious, thing. You say, Hey team, this area of the app is loading slow. This particular script that we're importing isn't working. And it's a team effort cause [00:20:00] it's going to affect all those features. So my last question was, is this going to drastically change the future of the internet? But it seems like this is going to be a lot slower ramp up to whatever change is going to happen. I think it depends on how impacted. We actually are when people have these bad scores, we don't have that data yet. So maybe once we see that it's like devastating, potentially we'll probably see some change, but just like to Noel's point, if you even know what FID was to begin with, you probably a pretty conscious of just performance in general. So as long as you're just building a web app. As a normal engineer, like not trying to like sabotage your own performance. I feel like it's, it'll be generally performant. Obviously I think people will be more mindful of stuffing functions that actually block the thread with a lot of stuff. But I think I'm giving the benefit of the doubt that if you actually see your site locking up because it's calling some function, you'll probably fix it. But who knows? I'm also wondering if we'll get a lot more sites that like give, do some kind of [00:21:00] responsive feedback much more. Like I'm imagining like you click a button and something changes, like the button changes color when you click it. Cause then you can like juice up this number. As you can with input delay, right? Like make it seem like it's reactive and performant. Even if clicking add to cart actually takes five seconds, but we can make, it's like you click the button and the button, changes from black to blue and you click it like, okay, we've technically redrawn. The number should go up. We already do that with Optimistic Updates, which a lot of people are trying to do in many ways. Yeah, I think you're right, though. People will figure out how to game the system, and they will continue to do just with whatever new rules Google lays out. Yeah. And I think Paul, you did an episode on like concurrent rendering, I believe, which, which basically slices up like big tasks. So it can actually be reactive where the page can be responsive. So we like, if you're making a react app, you have tools to help, make that easier transition. Let's move on to our final topic before we get into our hot takes. So Paige actually shared this article the other day on [00:22:00] Twitter and I found it really fascinating. But Josh Collinsworth he's a front end engineer at Dino wrote on his blog about how he sees the actual practice of front end diminishing. And what he means by that is the pervasive idea that front end development is no longer considered serious engineering is affecting how we all work in web development. So one of his examples is how CSS Is at the same time too complex and too simple creating a dichotomy that pushes it more towards quote unquote unseriousness. So what were your initial thoughts on the article? Do you agree with Josh's arguments? I, have a lot of thoughts. the reason that I shared this was because it resonated with me a lot and I didn't think that it was going to when I clicked on it, but It made a lot of sense. It reminded me of all the Twitter wars that have started about whether CSS is actually a programming language. [00:23:00] I agreed with a lot of his points. It's so interesting how we tend not to, or a lot of times we tend to devalue front end as a less, a more fluffy, softer kind of programming or engineering because, I don't know, because it's UI, because it's working with design, because it's based a lot on what looks good, which is subjective, but it, a lot of it made a lot of sense. So that's why I wanted to share it because. you know, and every big company, every big tech company has always geared their interviews towards backend algorithms, data structures, if you know this, you can get in, but if you don't, if you're more on the front end of things where you don't need those skills necessarily, or need to traverse binary trees, you're out of luck, even if you were a great developer, but you just don't have to use those kinds of tools. Hard computer science skills on a daily basis. So it spoke to me a lot. And that's why I [00:24:00] wanted to share it and hopefully get other people to see it and understand it a little bit more as well. So here's my initial reaction. Just like a quick one. First, super well written. I really enjoyed reading it. Second, I think it's just a by product on being on the internet too much. Especially on Twitter where these conversations happen constantly because. At work or when I'm not on the internet. I don't think I ever have these thoughts ever. I don't think I sit there and I'm like, man, do people not think I'm an engineer? What am I going to do? That is just not a thought that ever crosses my mind. I think it's just because potentially I'm not saying he's on Twitter. I think he is, this is what happens when you surround yourself in like toxic communities and stuff like that. Like, Sure. If I go to interview and you want me to balance some tree or whatever. Sure. I can learn that. And I'll. Do what I have to do the past interview, probably. Does that make me less of engineer if I get it wrong? I don't think so. Like before I was a front engineer, I was a backend engineer for six, seven years. , they both feel the same to me. Sure. If I make a button blue, it's not much harder to write a rest [00:25:00] API for some credit actions. And Java express or what have you, it's just these things are as complex as you make them. Sure. If you're only changing buttons, color, but colors of a button, sure. It's not that hard, but like front end is such a huge spectrum. There's security, there's performance, architecture, like infrastructure stuff. It just depends on where you are, that kind of determines the complexity. And I'm not saying just because you're changing colors of a button, I'm discounting your engineering abilities, but I think it's like obvious that there are parts of the spectrum that are pretty complex. So to give a blanket statement that like front end engineering isn't real engineering. Okay. Honestly, just pisses me off, to be honest. But I get it. Like when I was reading it, I was like, yeah, sure. I definitely resonated with everything he was saying. But at the end of the day, it's I'm pretty good at ignoring people's opinions in general. What people think about me doesn't really impact me unless it's like maybe my parents or like my immediate friends or something like that. So all this stuff is just noise, to be honest. So I'll just keep doing my thing yeah, that's, I think [00:26:00] that kind of building on Paige's point and even what Chris just said I think it's hard. It's like the back end interview Is often cleaner a lot of the time. And then this is maybe like a slightly hot take, but I think it's easier for the backend to feel more pure because there's less like externalities. Like when we're doing front end there's all these things you have to think of it's hard to interview someone's and get a really good grasp of how they would architect a front end app in an hour, like that's a really hard thing to do, but it's much easier to have like, okay. This is a tree balancing toy problem, and we can get through this in an hour and get a lot more signal on a candidate. I think that is hard to do. Like it's hard to do with front end engineers. You can do it, but I think it's easy to fall into the trap of just like we're quizzing on like keywords, right? Like what css selectors do you know? What like how what weird quirks do you know about in the dom? And I think it's hard to get at that core of like is this person actually good at architecting and designing front end apps? Maybe that's just like a failure of [00:27:00] the industry. Maybe it's a failure of the tooling that has led us to this state that like, it is so much harder to get this signal. But I think that kind of fundamental difference is what leads to this. And if anything, I think it's like good to reexamine that because the fact that it is so much harder to evaluate could also signal that this is maybe even like a higher skill ceiling. Space and we just think about it wrong. But I think it, it's hard to break that. And I don't think we're really primed right now to do like the tooling is getting better, but one could argue it's also getting even more complicated. So You processing and all this well in the front, I can tell you the only time I've [00:28:00] needed to use trigonometry with has been in the front end. There's a lot of wild math. I've only had to use like doing front end work. I'm sure a lot of other people have Felt the same way that there's like a complete severing of domains of stuff that you'll only use in one or the other. And they're, they have their own complexities. So definitely, especially Chris, I agree with you when people are like, Oh, it's simple. I'm that pisses me off too. It's the only one I've broken out the, like a math textbook for like, come on, I want to go off this simplicity slash you can't really, gauge a front end engineers experience in an hour. At one part, Josh says that he sees the degradation. Of software developers as a result of the inherent responsibility for developers to be the quote fixers even says if our skills are valuable as duct tape over the cracks of organizational shortcomings, why aren't they valuable during the planning and decision making that led to those defects when we could potentially prevent them? Have you experienced this in your own time in web development and [00:29:00] how do you think this could be rectified? Thank you In the future in engineering works, There's a lot to unpack in that question. I think, I don't know if this naturally comes from organizational structure or anything, but I think it's just the nature of like, we're in a fledgling industry, things are being built all the time and it's easier to build stuff than maintain stuff because like we're talking about earlier, like you lose people, there's turnover, there's like institutional knowledge that's tied to a specific architecture and design that like is hard to maintain over time. So I think that. Is like the tricky part of this equation. A lot of the time is we do a lot of work as engineers to make the thing maintainable. So much of the work we do is for our own future selves or like posterity sake. I guess maybe I question a little bit, like if this is truly an organizational problem, we always argue that we need more time upfront to design things better, but. I don't know. I think we're just like the industry is still, so still [00:30:00] it's so much, more appealing, build the new thing, make it go, then maintain and work with what we've got currently. This is the natural fallout. One thing that might help it is, I know that there has always been, especially when you're hiring earlier career devs, is to have somebody who is a full stack, quote unquote, developer. They know a little bit of front end, they know a little bit of back end, they can work with a database if they need to. They're well rounded enough that they can, Work with whatever you give them and do a pretty decent job at it. But I think that there needs to be more of a focus when they're hiring and staff trying to staff up for senior developers to help lead the teams that they need to be more open to having people who are more specialized in one area or another. Yeah, you need backend engineers who can look at backend code and say, Hey, we can use parallelization or we can use concurrency, or we can do something that will help make this faster because I've done it before. I know that really well. , and at the same token, we need front end [00:31:00] engineers who can look at the front end code and be able to say, Hey, I've seen this before. I have a more efficient way to do this, or, just having that experience, I think companies need to embrace the specialization more and go less for the unicorn who can do both with equal skill, at least at the higher levels, because it, Like we just said, there's too much to be a jack of all trades and a master of all trades, you really, you can't do both well. Try instead of trying to find one person who can do everything, find a couple and be able to combine their skills and point them towards the things that they're best at and let them help in that way. Yeah. I don't really get this statement to Noel's point. This just sounds more like either a culture thing or a process issue with the organization. Cause this can happen on either side of the stack, right? there's, you're going to get tech that either way, right? I haven't seen perfect code. I've been at plenty of companies and like Noah mentioned, people leave. A lot of tribal knowledge is [00:32:00] lost. So I just don't see why it's like specific to like this front end, like discussion, I just think this is just. A symptom of like almost every organization I've been part of this just happens. In that same vein Josh also said that devs often combat the mindset of it's good enough. Just leave it like without going the extra step to make sure that like the product, the website, whatever is up to its optimal performance. Do you think this is another cultural Idea or is this more universal across front end where it's like, it's good enough, leave it, ship it, whatever. And how can engineers combat that mindset? is it an engineer problem? Or, A leadership problem, because typically I feel like it's a leadership problem. Cause like Nolan and Paige mentioned earlier, if you're making an app, you're going to make it good. Like you want it to load good. You're an engineer, you're building something. So who's actually rushing it and saying it has to be good enough. Cause there's plenty of times I know I've [00:33:00] been building and people are like, Hey, you don't need that feature. Or that's iteration two. Like we just need to incrementally deliver. And then it just falls off and it is what it is. We've all been there. Yeah. I think it like depends on what you're building. Is there a marketing deadlines or deadlines in general to where you just have to ship or does your product have an SLA where it has to be very performant and up at, you know, 99. 9999. So it really depends. I think if you're in the, ladder, then you're probably. Going to do your best to make sure it's very performant and up all the time. Whereas if it's like, you know, something it's okay. If it goes out, it's not the end of the world, or if there's a deadline due tomorrow, you're probably not going to stay up all night and make sure you save five milliseconds of performance or something like that. So I think it's very, it's the typical. It depends. I think in this case, I think this is one of those things that like, if you're a dev and you do a lot of side projects and stuff, like if you have a lot of things you'd build for yourself. You can help strengthen that muscle of what do I need to spend time on versus am I okay just shipping? Because if you're building it for yourself, and like, you're excited about just getting the functionality out. I [00:34:00] find at least when I'm working on those, I am also much more of that. Like, Eh, whatever. I don't care if it's 5 percent less performing. I want it to do the thing and like, do that enough times. And you get more empathy for the business. It was like, okay, we're going to need this to do the thing so we can start. Making the money or whatever. And I think it helps you frame that these are things we should spend time on upfront versus whatever we can kick this down the road. It's probably not going to hurt us. Like this is low interest. Debt to take on, just as an aside, if you're trying to get out of that rut and get some perspective, build some side projects. Oh, there's more side projects. All right. We're going to head into our hot takes next. But before we do I just want to tell all our listeners. This episode was brought to you by log rocket log rocket offer session, replay issue tracking product analytics , to help you quickly surface and solve impactful issues affecting Your user experience with log rocket. You can find and solve issues faster, improve conversion and adoption, and spend more time building a better product. All right. So let's go into our hot takes where each guest will tell us [00:35:00] what they are either riled up about or excited about in the world of web dev, Chris, you want to go first? Can I go last? I'm trying to think of, I always think I have one. And then when I'm about to say it, I'm like, nah, This was going to say, Chris, this happened last time. I know. And then I think of, I, then I ended up thinking of a decent one. It's so hard. Hot takes are so hard. I swear. I'll go around through the circle page. What is your hot take? So my hot take this week is going to be something that's been going around the community and it is writing js from CSS, which is the new inverse of CSS in Js. But essentially there's a new library out called Mist, CS. And it encourages you to just write CSS, and it will be able to create a React component out of that. So it can create buttons, it can create different props that need to be passed to those, but essentially it [00:36:00] works with Tailwind, so all of our Tailwind developers can get in on it, but essentially it is trying to, Say that instead of actually having to write JSX or write HTML, you can just write the CSS and it can infer what it's going to be based on that. And this works when you're thinking about the really basic elements like a button or I don't even know what some, a very basic input. But once I start to think about, hey, I want a card with multiple things nested inside of it, or I want a larger page layout with multiple components , in there, this just starts to break down for me. It seems like I need to You know, create classes and have a really good idea of what I want this thing to do before I've actually even written anything, any HTML or JSX and seen it on the screen. So I think that this is an interesting way to approach it, but I don't think that it's going to catch on. I don't think that it's going to [00:37:00] work when it starts to scale and I'm. I really wonder why somebody wanted to do this beyond just to see if they could do it. It doesn't seem like it's going to make me more efficient or better at my job in any way. It seems like it's going to make it harder. But you made it harder in CSS. All Right. Awesome. Paul, what is your hot take? Mine of this month is that everybody should try self hosting stuff more. Recently I had a Next app and I decided to just throw it up on this little dinky laptop server I had at home. And I learned so much about I use this thing called DuckDNS to make my dynamic IP given by Fios a static IP and how to like optimize builds and responsibly forward ports so that you don't get your home network absolutely obliterated. It's a great experience. And now I'm hosting several sites for free. So if anybody has done the business account for Vercel, it's you [00:38:00] pay like per project. Save me a ton of money. So definitely recommend people try that out. Even if it seems scary, it's definitely less scary than you might think. And you'll learn a lot. I certainly did. Ooh, a nice little positive one. Thanks, Paul. No. What is your hot take? Real quick drift on Paul's. If you're like into that, but you don't want to be too scared about opening up your network, you should check out cloud flare tunnels. Yes. they're so good. Yeah. They're an awesome tech. You can like expose one port on one service on a machine without opening up your whole network. And it solved the DNS problem too. They're great. Anyway, mine's like very tangentially related to web dev, but does anyone remember like when NVIDIA was a gaming company? Remember this 10 years ago, And I don't know, I'm just like, I feel like they've been on, they were on like the crypto gold rush and then now they're on the AI model trading gold rush. And they like, I've been very fortunately positioned in both these things, but of me laments. When they were a gaming company. And I'm fearful that if the, some of this AI stuff falls out, like we're predicting a little bit, like maybe this won't be as big a thing long term. And they're like the [00:39:00] only vendor right now that this could end up being bad for the industry at large, but we'll see. We'll see. It's just, I don't know, it's tiring. And then you have to watch all these like business analysts talk about NVIDIA, like they know what they're, what they actually do. It's a ride. As an investor in Nvidia, stop it. ha This is not financial ha! Awesome. Chris, Do you? have a hot take for us? I do. I'm going to go with my original one, which is mean, but it's real. If you are afraid of AI taking your job, it probably Yep. Ooh. That's a good one. Yep. that it can do your tasks really easily and replace you, then, maybe it's time to hit the books, level up, maybe. I think I said that in a different podcast, but now that Devin's out, like everyone's crying about him, it's just, Do what it can't do. I can only do 13 percent so far. So you'll be all right. For your hot takes today. Thank you everyone for joining [00:40:00] us for this month's panel episode. Chris, where can people find you you can find me on Twitter at a trash with two H's underscore dev. I hate saying that every time. And we love it every time. Paige, where can people find you? you can find me on Twitter or X as well. I am at PNidri. Awesome. Paul, where can people find you? Definitely listen to pod rocket cause I have quite a few episodes here with Emily. And if you want to connect just on LinkedIn would be a good spot. Paul Mikulskas. Awesome. And Noel, where can people find you? Yep. Pod rocket as well. I'm kind of an internet hermit, but you can find me on blue sky. Noel dot M I N C dot H O W. And we'll have all of your handles in the show notes. Thank you again, everyone for joining us today. And to all our listeners who are listening today. Next month's episode will be a listener question episode. So if you have a [00:41:00] topic that you have questions about, please send them my way. My Twitter handle will be in the show notes as well. Thank you everyone. And we'll see you on the next podcast episode. Thanks, Emily.