Kate Trahan:
Hello. Welcome to PodRocket. My name's Kate, I'm the producer of PodRocket. With us today, is Paige Niedringhaus. Hi Paige. How are you doing?

Paige Niedringhaus:
Hey, I'm good. How are you?

	Kate Trahan:
I'm doing well. Paige is the staff software engineer at Blues Wireless and also one of the co-hosts of ‎React Round Up podcast. So you might have heard her voice before. And yeah, we were just talking, you used to write for LogRocket, so you might have seen her on our blog as well.

Paige Niedringhaus:
It's nice to be back again.

	Kate Trahan:
Thanks for joining us. And also with me as Noel. Hi, Noel. How's it going?

Noel:
Good. Good. I'm well.

	Kate Trahan:
Awesome. Yeah. So Paige, I think just to get started, maybe just talk a little bit about kind of yourself and what you're working on and we can kind of go from there.

Paige Niedringhaus:
Sure. So I, like you said, I am a staff software engineer at an internet of things startup called Blues Wireless. So mainly what we do is we build notecards is what they're called and they make it possible to have internet of things, objects out in the world that don't necessarily have a good internet connection, get connected to cellular and be able to transmit their data from a far away field or a moving vehicle or anything like that, and actually send it to a cloud and then be able to consume it and use it in some kind of a web application. So that's where I am currently. Five years ago, I worked for the Home Depot as a software engineer of varying degrees. And then before that, I was actually in marketing and advertising. So I did a total career change and decided that software engineering was really what I would rather do instead.

	Kate Trahan:
Yeah. So I think just to get started, we have some questions on React for you. Noel, do you want to get started on the React stuff?

Noel:
Paige, we're curious, kind of, since you've been in the React space, like what are the biggest changes you've kind of seen, like the high level changes?

Paige Niedringhaus:
I mean, some of the main ones that I've seen was that when I originally began with React, classes were the only way to do any kind of state management with React applications. And since then, we've translated to Hooks and that made functional components king. And then now we're moving on to stuff like server-side rendering and React server components and Suspense is finally coming to React, hopefully within the next six months to a year, depending on how quickly React 18 goes from beta into actually production ready status.

Paige Niedringhaus:
But it's just been, I mean, it's been a wild kind of change from having these massive, Angular-based applications where everything is included for you, batteries and routes. And just all the things that you might need to React, which is as bare bones as it gets. It is basically the view part of an application. And then you choose everything else, which some people love and other people hate, but it's been a real departure, I think. And a lot of people, myself included have really kind of enjoyed that way of kind of picking and choosing and getting exactly what you need for the use cases that you might be encountering and trying to solve for.

Noel:
Got you. Got you. So do you feel that before React was more opinionated in how it kind of interacted with the other layers of the stack and it's less so now that we're kind of in this Hooks paradigm? Or do you think those are kind of separate issues?

Paige Niedringhaus:
I think that those are a little bit different issues. I mean, React has always been fairly unopinionated about how you get things done, what kind of router you want to use, what kind of state management, if you need an external state management library you want to use, whether it's Redux or Jotai, Zustand, or Recoil, you name it, it's probably there. But the nice thing about it to me is that it's a much smaller package than something like Angular would be. And if you want to use TypeScript, you can, if you are not comfortable with TypeScript, you don't need to know it and you don't need to use it necessarily, you can just do straight JavaScript instead. If you need a backend server, which most people do, you can either reach for Next.js, which has APIs routes built in, or you can set up an Express server.

Paige Niedringhaus:
However you want to shoehorn it into an application you can, whereas with Angular or even maybe with Vue, you kind of have to play by the rules that they have given you, or the way of doing things that they want you to follow. It just depends on what your comfort level is, I guess, with JavaScript frameworks, because some people I know come from maybe a backend language like Java, where it's very much like, this is how you do it. This is the only way or the right way to do it. So something like Angular is great because Angular is very prescriptive in that way. But if you come from other JavaScript frameworks or Python or some of the other languages, it's just like, however you feel like doing it, we can work with that. It's cool. Just choose to direction and go forward.

Noel:
Yeah, totally. I mean, that's an interesting point. So for those devs that are coming from like a highly opinionated language, even in like the semantics of how you use the language typically, do you feel like it's easier now than it was before to kind of get into like React? Or do you think it was easier before? Because now there's like all these options, like we talked about.

Paige Niedringhaus:
I think that it's a little bit easier because to me, at least learning Hooks once I had actually started working with them was easier to grasp I think, than class-based components. So when you start to learn React and you are using some of the older frameworks, if you don't understand how classes work in JavaScript, which is not necessarily something that you'd come across in every application, it can be a little bit off putting trying to kind of wrap your head around that as well as the different component life cycles, like componentDidMount and componentWillUnmount and things like that. But React now with Hooks, is so functionally-based. It's very easy to understand. I write this function, I call it, I put it inside of a use effect, it runs, when these things change or when this component mounts or unamounts.

Paige Niedringhaus:
So to me, it seems like it's actually easier. Although I would also say that there is a benefit to understanding both flavors of React, the component-based or the class-based and the functional-based, just because there's a lot of chance that you'll inherit some older code base, which at least has some class-based components still in it. And you'll either have to maintain those or upgrade them to use Hooks in the future. So there are definitely benefits to knowing how to interpret those and knowing how to go from Classes to Hooks, but I think that Hooks makes it easier to get started with. And I think that it's a lot more straightforward and gives you a better opportunity to kind of modularize your code and make it more reusable and less closely tied to a particular component than when it was very class-based and on state management could only be done in the class-based components.

Noel:
Totally. I guess, do you find yourself working with kind of new React devs very often? Like just interfacing with them at all.

Paige Niedringhaus:
Yeah. I mean, people join your team. So new devs on the team who may or may not be familiar with React, I've worked with plenty who are more backend focused. So they're learning JavaScript and learning React at the same time, which is always tough because I've been there, mostly learning Java and trying to learn Spring Boot framework at the same time. So I can definitely relate to that. But yeah, I mean it's... And then there's always new people who join the team, there's developers who you mentor or you just interact with out in open-source communities, there's people that you meet writing online and things like that. So yeah, there's plenty of people who are still just getting into Hooks or just getting into React and always looking for kind of where to get started or what are some of the best resources for beginners.

Noel:
Yeah, yeah. Totally. And yeah, like I understand it's there, I'm excited there's people just getting into it. I guess what led me to the question was I was curious if you've encountered that people, like new devs that are kind of walking into the space from like not much of a foundation, do you find that they are kind of wind up working in Hooks and stuff just like, because the docs and the React community points them that way? Or do you find that they're landing on old tutorials sometimes and they end up not using React Hooks?

Paige Niedringhaus:
I would say that for the most part people are leaning towards Hooks. Whenever I'm in Discord channels and people are talking about how should they go about learning it or what should they be pointed towards, I would encourage them to start with Hooks, especially because there's better documentation for it, there's more people who are talking about it now and you're always going to go down those Stack Overflow rabbit holes where people are using Classes or you'll see the old style syntax or things like that. But I think that by and large, the majority of the content that's going to kind of float to the surface is probably going to be Hooks-based at this point. And that's one of the things that's the best about people sharing what they know online because there is a lot of new content that's always kind of coming out.

Paige Niedringhaus:
And it's also one of the most frustrating parts because you will find those very old, outdated pieces or you're trying to use an outdated code base, which maybe your company has. So there is no getting around it. You have to maintain this and keep running. In which case, finding the answers can be really tough. But then that gives you a good opportunity probably as a developer to make the case that it's time to upgrade, so that you can stay up-to-date with the current technology and be able to find developers who know how to work with this stuff. Because if there's only that one guy who know COBOL, it's going to be really hard to keep up code base running and keep it up-to-date with just a few people who might have that arcane kind of knowledge of React.

Noel:
Right, right. Yeah, yeah. I bring it up because like, this is a thing that's interesting to me is I'm curious how often people are thrown off. Like, when they're going and they're finding old Stack Overflow issues and they're like... They end up using classes kind of inadvertently, not even knowing that there's another option out there. We kind of touched on this when we were talking with Evan You about Vue, unlike the same kind of problem they're having with like composition API versus options API and like documentation and all that stuff. So yeah, I was just kind of curious, your pulse on that is probably better than mine is. So I guess it's good to hear that people seem to be trending the right direction largely.

Paige Niedringhaus:
Yeah. Well, one thing that I always notice with the Stack Overflow posts is that a lot of times, even though the question was asked six or seven years ago, people will come back today and they'll update it and they'll be like, "Whoa, well, if you look at this documentation, now we can do with ES6 blah, blah, blah, or same thing with React." They're like, "Yeah, you could have done this with classes, but now there's a better way to do it with Hooks." So even though I am not an active Stack Overflow participant, I'll go look for answers, but I don't ever write back because I don't think I even have enough clout in Stack Overflow to make those kinds of things. But people will go back and update the docs or update with new links and stuff like that, which is really nice. It's really a nice thing about the developer community.

Noel:
Yeah. Yeah. Definitely. Definitely. Yeah. So I guess kind of with that, are there any struggles that you see React devs, I guess kind of new or old kind of running into right now in particular, just like pertinent issues?

Paige Niedringhaus:
I think one of the biggest ones still is that people try to learn too many different pieces of a React stack at the same time. So they're not just doing React. They've also got Redux in there for state management, or they've got XState in there for state machines or they add too many tailwinds. They've got too many technologies that they're trying to learn all at once. So it's really difficult to parse out who is doing what in that scenario, like is Redux handling my state management? Or is XState the one that's responsible for this component updating? Things like at make it a lot harder than it needs to be, I think, to actually get a grasp for what is React doing versus what are these extra things that I've also added that I heard were cool doing for me as well.

Noel:
Right. Yeah. It's like, "Do I use Redux? Do I use the context API?" There's so many decisions. That's kind of what I was alluding at before. I was like, when a new dev is coming in, so they're familiar with something else, it's got to be overwhelming, in particular in React. Because with Vue, you kind of... Well, formerly there was one way of doing things, now it's somewhat fragmented as well. Do you think that the kind of the Create React Apps and stuff like that are helping with that problem, those CLI tools? Or do you think that they're kind of exacerbating it?

Paige Niedringhaus:
I think that those are immensely helpful for getting started honestly. I used Create React App even within the last company that I was working for, Home Depot, because we were an internal tool, so we didn't really need anything like server-side rendering or the SEO benefits that might be provided by something like Gatsby or Next.js. So it really was as simple as a Create React App stacked on top of an Express server to be able to reach the API services that we needed. So having that, you just enter a couple of commands and then right out of the box, you're spun up and you've got a couple pages and you've got the little React loader just kind of spinning, that's really, to me, really helpful to see some progress, even though you didn't do most of it, it's kind of scuffled it out for you.

Paige Niedringhaus:
But to be able to just see that you got something started in a browser is really I think a good thing. So I think stuff like that is awesome. And I love that Next.js now has all these different starter projects as well. So you can get up and running with that quickly. And Gatsby has all these different themes and kind of starter packages too. So I think that those things are awesome. And once you've kind of seen how a couple pieces are glued together, then it opens your eyes to how you can start adding onto it and changing things and making it the application that you actually need it to be. So I'm a big fan of those kinds of things.

Noel:
Nice. Yeah. Yeah. I totally am generally as well. I use them, whatever the pertinent tool is for the project I'm working on, in every case as well. But again, I guess kind of to your point of like jumping in and trying to learn too much at the same time, when you do create your React app and it's prompting you for all these things I can include or exclude from the project, do you think that that... Like, that's kind of what led me to the question, do you think that that ever encourages people or leads people to become overwhelmed?

Paige Niedringhaus:
I guess that it could, but I would hope, and it's been a while since I've spun up a new Create React App, I would hope that you can just hit enter most of the time and it will just go with kind of the most basic defaults or the most popular defaults. And then once you've started to get into it and you've started to define what do I actually need for my project, or what kind of things do I need to change, you'll have gained at least enough experience to be able to make those better decisions the next time you're faced with starting some sort of a new project like that.

Noel:
Yeah. Got you. I haven't done Create React App in a while either. So maybe I'm like making an issue out of nothing here. I was just curious. Because I feel like when I've jumped into frameworks, that's hard. I don't remember my earlier React days anymore too well, but that is often what led me to like, "Oh, now I've got to research this. Now I've got to research this. I've got to figure out all this stuff to make sure I'm doing it properly." So yeah, I wonder if that is ever leading to it or if devs, or just like, "Whatever, I'll be fine. I'll figure out as I go." Yeah, I guess, when you're looking at struggles that React devs are having, do you feel like the documentation on newer features is usually sufficient? Like, is everything always there? Or is it sometimes easier to not lean on the super new stuff because it's just not ready for consumption yet?

Paige Niedringhaus:
I think that for the most part, the React team does a really good job of trying to stay up-to-date and keep their documentation up-to-date. I'm a huge fan of Rachel Nabors who does a lot of their documentation. I think that she does a fantastic job of it. It's really hard when you try to think about all the various use cases that people run into trying to use React applications. Some people have real time use cases, some people have just static sites, others have super dynamic things that have to keep updating all the time. So I think that they generally do do a good job. And then once you've reached the end of the documentation and you still don't understand, that's when you start looking for the tutorials, because people have written a million of them.

Paige Niedringhaus:
And sometimes it takes me five or six, where I have to read just different takes on people trying to solve similar problems before I'll finally find the one that clicks for me, but there usually is that sort of thing. And if I can't find it, that's a great option for me to then write my own blog about it once I finally do figure it out. Yeah, so it's a good learning experience because you get to see a whole lot of different people and how they approach and solve these problems using this framework that we all are fans of, but then you can also find kind of those niche use cases that only belong to maybe your problem that you're trying to solve and share it with somebody else because most likely someone else is going to be trying to do something similar to what you are. So I really like to take that as kind an option to put up my own, spin on it and try and help somebody who might get stuck on something similar.

Paige Niedringhaus:
So it's something that definitely does happen, but I think that by and large, they do a really good job of trying to keep it generic enough that it could be applied to a lot of different situations for things that people are trying to solve for. But one thing that I have noticed, and it's not necessarily just React developers, but it's, I guess people who are newer to development in general aren't taking advantage of all the tools that are available and that maybe more experienced developers are really familiar with. And this is things like linting, like formatting of code, letting Prettier do the code formatting for you and letting ESLint be there in your VS Code, telling you, "Hey, there's a better way that you could be writing this." Or There's a more preferred method of doing stuff. And I think that that's something that maybe newer developers are less apt to take advantage of or even to know about that really would benefit them a lot.

Paige Niedringhaus:
I don't really know where exactly that would be, because it's not like we have just javascript.com or something that is like, these are the recommended things that we think you should do. You just kind of get that as you gain experience and you work on teams with other developers who have found these tools and started to utilize them, but it's something that I don't think is talked about enough and it really should be, because it'll make your life a whole lot easier. And especially when I pair with my teammates and I see somebody who's not using it, it's like the first thing I want to do is help them get Prettier set up so they don't have to think about code formatting on their own.

Noel:
Totally. Totally. Yeah, yeah. I don't want to keep coming back to it, but I feel like that's another one, like in Create React App, in these CLI tools, at least the Vue the React app, I think there's a prompt in there. At least there was last I used it. Like, set up code, Linkedin code formatting and then like, again, I don't really, Newdev, I don't really know what that is. Leave it turned off, but it's like, "No, that one... Like, just turn it on. It'll be great."

Paige Niedringhaus:
Right.

Noel:
Yeah, yeah. For devs that aren't on your team directly, how do you help people figure out what tools they're not using that may make their lives way easier?

Paige Niedringhaus:
That's a great question. I mean, without actually seeing somebody else's VS Code set up and I hope that they're using VS Code as their IDE, it's kind of hard to know, but I definitely see it when I'm pairing with somebody. Like some of our designers are both designers and they can do web development. So they know some HTML and some CSS and stuff like that. So pairing is a good way to do it, but then also if you're all working on the same project, trying to provide some of those base starter files in your project. So for Prettier, you'd have like a .prettierrc file and the whole team would be sharing that. And it's the same things for everybody. For ESLint, you'd have a .eslintrc. For Node management or NPM and Yarn management, you might use something like Volta or like NVM so that the team again, is developing against the same versions of Node and Yarn and things like that.

Paige Niedringhaus:
So trying to kind of put guardrails around a repo or a development team in those ways is a good way to do it without forcing people to take your style of coding as the end all be all, but at the end of the day, it's kind of like you, I guess, as a team have to come to whatever your working agreement is. It's like, we're going to use NVM for Node management. We're going to use Prettier. We're going to use ESLint with the Airbnb configs turned on. You just kind of have to decide what things make sense for you and then try and get people up to speed. Like, I have a list that I just keep on a file on my computer of like all the extensions that I use for VS Code. So if anybody needs it, they can just ask me and I can send it to them.

Paige Niedringhaus:
But there's no... I guess it's just kind of how you prefer to do development is going to dictate what things you gravitate towards and what kind of extensions you employ. And I always like to listen to podcasts like this one, to hear what other people are using and follow stuff on Twitter to see what the hot new extensions are, but it's just kind of word of mouth and, I tried this and it was really cool. And I think you guys should check it out, kind of things as well.

Noel:
Nice. Well, that in mind, do you have any extensions that are like sleepers nobody knows about that people should be checking out?

Paige Niedringhaus:
Let's see, I've got my VS Code open right now. I mean, I really do love the Prettier and ESLint, those are probably the two first things that I'll add to a new project when I'm getting started. Because I can't live without code formatting meting any longer. I don't know how we did before. Another one that I really like is called Polacode, and that's great when you need to actually take photos of your code for like articles that you're writing or just nice screenshots that you want to share. It makes it really simple and it makes them look really good.

Noel:
How cool. So it's like screen capture right in VS Code. So you can like highlight blocks and stuff. Is that what it does?

Paige Niedringhaus:
Yeah. You pretty much just highlight a block of code and then you can open Polacode in a separate window inside of your VS Code and then you can kind of format it, drag the window, smaller or larger to get it where you want to be. It's really handy. I'm a big fan of it except for the accessibility issue, which comes with it. But it kind of depends, if you're using something like Medium where it doesn't really have nice code formatting, then it's probably a pretty good option. And maybe you can just link to like a GitHub gist or the actual files if people want to go and copy the code word for word.

Noel:
Yeah, sure. Cool.

Paige Niedringhaus:
Some other ones that I am a big fan of is Better Comments. That one is nice because you can do things like a comment and then to do, and it'll highlight it in orange so that it's easier to kind of find it when you're going back over your code to make changes or things like that. So those are some of the ones that I find myself reaching for a lot and using a whole lot.

Noel:
Nice. Nice. Very cool. Very cool.

	Kate Trahan:
We'll include those links in the show notes as well.

Noel:
I've got one too. I've got REST Client is one I've discovered recently. It's like Postman kind of, but it just a like lives in the editors. So you can like save requests that you make all the time. It's great if you like have an API, you've got a debug or something frequently. It's been super handy. Yeah. Yeah. Check out all the extensions. Cool. Yeah. So I guess kind of, I want to dig into your background a little bit.

Paige Niedringhaus:
Sure.

Noel:
So you said you were in marketing originally and then you kind of made the web dev transition. Can you give us like... I don't know, how did that happen?

Paige Niedringhaus:
It happened because the last marketing agency that I was working for didn't have enough work to keep me, honestly. It was a pretty small agency and we had a number of clients and it just kind of turned out that after the new year started, there wasn't really enough marketing specific work that they needed to keep me on for. So I was about to get married and they just kind of said, "Unfortunately, this is what it's come to." So it was either, go find a new job and do something else marketing related, or it was a chance to go and do something different. And I've kind of been thinking about code, because I wasn't really loving some aspects of marketing, like the client management portion of it. I really liked being able to be one of the people who was either writing copy or making content or building stuff, not so much managing timelines and making sure that the teams working with me were on task or on target. I'd rather be one of those people who was on one of the teams building the stuff.

Paige Niedringhaus:
So I had been trying out Codecademy and freeCodeCamp and stuff like that online. And when I finally didn't have a job that would be taking up my full-time, I decided to just give it a shot and go to a four-month coding bootcamp. And it turned out to be the best decision I could have made. It was a 16 week, nine-to-five plus after work and weekends kind of experience. And right at the end of it, I got hired by Home Depot to start working as a software engineer there. And the rest is really history, but it was by far the best decision I could have made and the best chance that I could have taken.

Noel:
Nice. Nice. Yeah. I'm sorry you were kind of forced, but I'm glad it all worked out. Yeah.

Paige Niedringhaus:
Yeah, yeah. It was really not something that I was expecting to happen when it did, but I think it was absolutely the best thing that they could have done because I don't know if I would've taken that chance if I hadn't been let go.

Noel:
Got you. Got you. Like, would you recommend... Say there's someone, they're in a similar position or they're thinking about kind of making the plunge, would you recommend a coding bootcamp or something to them?

Paige Niedringhaus:
I absolutely would. So the one that I went to is called DigitalCrafts and they've been slowly and steadily expanding. When I went with them, I think I was in their third cohort. So they were really small and scrappy and very much still in a startup stage. But I would absolutely recommend that to people who are looking for it because I think that I could have done the self-taught developer thing, but it would've taken me probably a couple of years to really learn as much as I did in 16 weeks because I had a teacher, I had TAs and just the other students that were around me kind of pushing me to learn more and be better. So I would say that if you really want to do it in a short amount of time and kind of get as much as you can for $15,000 $16,000, which is a big investment, but the first job that I had right after that was paying $65,000. So yes, it was a bit of an investment upfront, but the payoff has been way, way more.

Noel:
Yeah, yeah. Totally. Totally. Yeah, I feel like having that kind of... Like, the guidance there is big. Circling back to those points we were touching on before, just like, the space is so big. I can't even imagine where people start coming in totally fresh. So, yeah.

Paige Niedringhaus:
Yeah. And that was one of the things that was probably the most difficult for me is like, I did the free coding academy or whatever online, and I kind of understood the building blocks, but trying to put that together into an actual website still didn't really make a whole lot of sense to me. So actually being in class and watching my instructor start a brand new repo and this is where the HTML files go and this is where the CSS files go and this is how you connect a JavaScript file in there to get some functionality or some dynamic interactions, that was the kind of stuff that I couldn't really put together based on the online editors and things that I had done before that.

Paige Niedringhaus:
So to me, it was so beneficial just to be able to ask those questions and when I'd get stuck, have somebody look over my shoulder and kind of say, "Oh, it's missing semicolon or parenthesis or something here that's causing your code to break." That's the kind of stuff that I don't think you can really replicate online. And to me, that was so valuable as well as just being able to talk to him about his career in web development and hear how he'd gotten jobs and the different things that he'd had to deal with working as a developer with teams, just that kind of experience was something that I would not have gotten if I was trying to study on my own and be a self-taught dev.

Noel:
Got you. Yeah, yeah. Well, I guess on some of those earlier points you made about kind of having that pacing and stuff, people that maybe aren't able, they're scared to make that plunge, commit to like a full code camp. Like, do you feel that there is a way to kind of get that experience still where they don't feel like they're operating totally on isolation, but they can kind of get that feedback and work collaboratively a little more?

Paige Niedringhaus:
I mean, there are part-time options that they offer if you just kind of want to get your feet wet with coding. Let's say you're a UX designer, but you want to have a better understanding of HTML and CSS, there are like part-time coding boot camps that you can do on nights and weekends. I know that those are pretty popular and gaining steam, but for me it was more or of an all or nothing kind of mindset. I was like, "If I'm going to do this, I want to do it completely." I don't want to just... If it turns out that I really don't like coding that much, then I at least have some really great skills that I can say in addition to being a marketer, I can also do a little bit of HTML and CSS.

Paige Niedringhaus:
But by the end of the coding boot, it was like, let's see if I can actually fool somebody into thinking that I am good enough to be a full-time web developer. Because that's very much what it felt like. It's like, I am not qualified for this at all, but maybe somebody will take a chance on me and give me a shot. Which is absolutely what happened. I mean, Home Depot took me in and I learned so much from the team of developers that I worked for and the managers and just everybody in that organization. And now I've been able to take everything that I learned there and translate it into written articles and working with my new company, which is a startup. So there's a lot less guardrails and a lot less processes in place, but I've been able to take a lot of that and kind of help make that part of our development process there.

Paige Niedringhaus:
I mean, I even went so far as to actually write an entire course on modernizing React applications, which if you'd told me that I would be doing that five or six years ago, I would never have even known what you were talking about.

Noel:
Nice. Nice. So, yeah. Is your course specifically geared towards kind of like React devs that have a little bit of experience or I guess web devs that have a little bit of React experience. Like, who's the target?

Paige Niedringhaus:
Yeah. The target is really people who come into enterprise-level organizations like Home Depot, like Google, like Microsoft, and you might not necessarily be working with the most up-to-date version of a particular framework, whether it's Angular or Vue or React, but you inherit some of these longer lived monolithic projects. So at Home Depot, I worked on the same team for pretty much the whole five years that I was there. And we went through everything from an Angular one application to a React application with class-based components. And then we upgraded it to using Hooks. And we went from using Jest and Enzyme for unit testing to Jest and React Testing Library. We went from Puppeteer for end-to-end test to Cypress. So it's all those things that you just kind of learn when you're maintaining a longer lived application.

Paige Niedringhaus:
And there's really not a whole lot of guidance or good examples of how to go about doing that online, because when you look at the tutorials, it's like we start with the most up-to-date version of Create React App. Well, that uses Hooks. So we never even get a chance to look at class-based components. Or we talk about all the functionality of building a working application, but things like how to unit test it or how to end-to-end test it or how to add linting to it, all those extra things that go into enterprise-level applications, that have to have really good uptime and no bugs or as few bugs as you can release into production, the better, those kind of things really don't get talked about until you're can kind of in the middle of it with your team.

Paige Niedringhaus:
So this was my way of trying to show all the stuff that I kind of learned along the way and how you might go about doing it for an application that you might encounter in a job where you're doing basically the same thing, trying to keep a long mission, critical application going and improve it along the way.

Noel:
Yeah. Nice. Nice. Very cool. Yeah, I feel like that can be a tough spot, especially like when you're in an old org, you're like struggling for resources already. You're just like, "I don't even know where to start." Yeah. I've been there before, so yeah. We were doing it with Vue, but yeah, I feel that pain. Nice. Very cool. Yeah. Is there kind of, I guess, anything else you wanted to touch on with problems that are... Maybe problems that devs have that are going through that experience in particular that might be like a good, quick piece of advice for them to take a way?

Paige Niedringhaus:
I mean, one thing that I would say is if it's possible find somebody in your team or in your organization who doesn't necessarily need to be an expert in whatever framework you're trying to work in, but they need to be, I guess, well versed in the tenets of just good software development. Like, we have a developer on my team now who is not necessarily a JavaScript engineer, but he has such good experience building large applications in general that he can really be... He's been a fantastic person on how to kind of pull logic away from the components that are actually doing the presentational part of it, and helped us to make a more modular project so that when we need to switch out like a backend from pointing to this one particular database to another, it's going to be really, really simple to do that.

Paige Niedringhaus:
So having somebody who can kind of talk about how to architect applications in a way that makes it easier for you to switch out different pieces when need be, or model certain architectural patterns, that is still going to be really valuable, even if you're making what seems like a much smaller or a less complicated project, because I can guarantee you that wherever it starts, it's definitely not where it's going to end. It's going to get way more complicated way quicker than you and imagine. So if you can kind of start off with a good baseline or a good architecture, it's going to make everything a lot easier as that application gets bigger and more complicated.

Noel:
Yeah, totally. Totally. Yeah, it can be really hard to kind of get that high level vision. For sure. And like, figure out how you're going to do this. And I think it's good there's more content out there now, but it's still a really tough problem, especially in like solidarity, if you're trying to do it by yourself, that can be so-

Paige Niedringhaus:
Oh yeah. Yeah. It's much easier when you've got a team of people and when you can kind of have those people who maybe didn't help build that particular feature, but can then look at it and say, "This is how I think I would refactor it if I was going to take a stab at it." Having those extra opinions really makes all the difference.

Noel:
Yeah. Yeah. And just like, yeah. Once you can hit the point of having everybody on the team onboard and like, "Okay, we all have a shared vision." Like, you've got to get there. So yeah. Having somebody on board to help you swing can be super cool. Kate, do you guys want to chat about podcast stuff a bit?

	Kate Trahan:
Yeah. So this is also a fun fact, which our listeners know, and they're probably sick of me talking about it, but I did a bootcamp also and I worked in a marketing agency before. So it's funny because we actually just had Hannah Neil, a community manager at NGINX. And it's funny how many people in this industry have like marketing backgrounds. There just seems like more and more, and that's really great to hear.

Paige Niedringhaus:
So what did you think of your bootcamp? How long was it? And what was your experience coming out of it? Did you decide that you wanted to do full-time web development? Or did you want to do something else after?

	Kate Trahan:
So I'm not a full-time web developer. I am still in marketing actually, but my course was, it was, it sounds similar to what you did, it was every day, all day, basically for six months, maybe it was five months. And the course actually I took was Java Android, which I do not use. And I actually had to like borrow a phone from a friend because I was like, "I've never even used an Android phone." But no, I mean, I obviously learned a lot and I mean, even though I'm still in marketing, everything we touch at LogRocket marketing is related to web development somehow. So yeah, I think it's really helpful and just kind of understanding, or even like, as we're sitting here talking, I know what a linter is. It kind of helps have like a mind map of everything. For sure.

Paige Niedringhaus:
Absolutely. I mean, I think it's so valuable when you are like a product manager or a designer or anybody really who works with developers if you have a better understanding of kind of the limitations that developers work within in terms of what frameworks can do or what CSS and provide. So I agree with you that even if I wasn't doing this full-time, just being able to better understand and talk to development teams about what was possible, I think is a hugely underrated, but really useful tool and level of understanding that people don't necessarily get, unless they do some development themselves and kind of feel the pain that can come sometimes with development.

	Kate Trahan:
Right. Yeah. And I think too, I mean... Well, actually I was just talking to Paige about how I'd spilled a bunch of water right before this reporting. And it was like all over my equipment and stuff, but like setting up the audio equipment, I guess I'm just like less scared of technology in general. Even if it has nothing to do with our web development, I'm like, I know I can't break this because... Like, you just have like more of an understanding of like... Where before, I probably wouldn't have that confidence.

Noel:
Yeah. Nothing is magic. Nothing is magic. It's all just, yeah. Yeah.

	Kate Trahan:
Exactly. Exactly. Yeah. So I want to talk a little bit about the React Round Up podcast. So the podcast is at 170 episodes, I guess, kind of, when did you get involved? And tell us a little bit about that story.

Paige Niedringhaus:
Sure. So I got an involved in March or April 2020. It was probably right around the time that the lockdown was happening for the first time in the U.S. And it just so happened that I had been on an episode as a guest. I was talking about, I think, a conference talk that I had given the previous fall about responsive design with React. And I had also been on another podcast owned by the same kind of overarching stable of podcasts and the Devchat.tv is the name of like, kind of the producer of all these different ones. So I'd been on JavaScript Jabber and My JavaScript Story and then React Round Up. And after I was on as a guest, the host asked me if I wanted to be one of the co-hosts, because typically it's a panel of two or three co-hosts and then one guest who comes on and talks every week about something really cool that they've been working on within the React ecosystem.

Paige Niedringhaus:
So I said, "Yes." And it just kind of snowballed from there. It's been really fun, because I've gotten to meet so many interesting people in the React ecosystem. We've had Tanner Linsley on to talk about React Tables and React Query. We've had Kent C. Dodds on to talk about Remix. We've just had a whole host of really interesting kind of React-based people who are doing cool things in the industry. And every week we put out a new episode where we talk to them about something. We've had some really cool machine learning and AI, conversations lately with different people. So it's a really fun way to kind of keep up with what's new and different in the industry and what people are trying. So if you like that kind of stuff, in addition to LogRockets podcast, I would definitely recommend you subscribe to this one. Because we have some pretty interesting guests who come on and tell us what they're doing that's new and different.

	Kate Trahan:
Absolutely. Yeah, absolutely. Yeah. I think, like you were saying, it creates a network of not only listeners, but also guests and even hosts. So I don't think anyone's competing, like the more podcast, the better. I think it's all positive. For sure. Yeah. So with that, what are plugs you'd like our listeners to go to? Where do you want to point them? Where can they find you? That sort of stuff.

Paige Niedringhaus:
I mean, the easiest place to probably find I me is on Twitter. So I am on with a really terrible Twitter handle. It is P-N-I-E-D-R-I, because I chose it back in 2009 when Twitter was just getting started and should have made it something easier and more memorable than that, but I didn't. But in addition to that, one thing that plug is we were talking about how a lot of developers will join organizations that have older applications that they're then in charge of maintaining and improving. So I wrote a course with a company called Newline, which does all kinds of web development guides and tutorials and just really good, high quality content. So an entire course, which is 10 modules, 54 videos, and about 10 and a half hours worth of video content is there about all of this.

Paige Niedringhaus:
So it takes you from an old application and we update it from Class components to Hooks. We do all sorts of custom Hooks, we do context, we set up linting, we set up Prettier, we set up testing with Jest and React Testing Library, we use Cypress for end-to-end, we add in a component library, which is Ant Design towards the end of it. So you can see how you might integrate something like that into your application. So really, it tries to be a full look at what you might encounter and how you could go about in kind of a systematic way updating or upgrading an application once you've gotten ahold of it.

Paige Niedringhaus:
So that's going to be my plug. And then if you want to kind of keep up with what I'm doing, I write pretty regularly. At least once or twice a month, I'll release a new article on my website and then I also will cross post it to Medium and to dev.to. So there's lots of ways to kind of keep up with what I'm doing. And most of it is going to be front end, web development-focused. So if that's your bag, then you definitely probably want to keep an eye on me.

	Kate Trahan:
Awesome. Yeah. And we'll include those links in the show notes as well. Paige, thank you so much for joining us and we will see you around.

Paige Niedringhaus:
Absolutely. Thanks again for having me. It's been really fun to talk.

Brian:
Thanks for listening to PodRocket. Find us @PodRocketpod on Twitter, or you could always email me even though that's not a popular option. It's brian@logrocket.