[00:00:05] SY: Welcome to the CodeNewbie Podcast where we talk to people on their coding journey in hopes of helping you on yours. I’m your host, Saron, and today we’re talking about the new wave of front-end developer tools with Chris Ferdinandi, author of the Vanilla JS Pocket Guide series, and creator of the Vanilla JS Academy training program.

[00:00:24] CF: I can remember early in my career when I was able to talk about responsive web design and concerns around mobile and best practices and usability. There were developers who were a lot more senior than me, who were a lot less versed in this sort of thing, and it put me in a lot of conversations I wouldn’t have been in otherwise.

[00:00:42] SY: Chris looks back at being on the CodeNewbie Podcast in 2020 and what he’s learned since then. He talks about how he sees front-end development changing in the next few years, what new tools are on the rise, and why leaning into these new tools might help you in your future job search after this.

[MUSIC BREAK]

[00:01:06] SY: Thanks so much for being here.

[00:01:07] CF: Saron, thanks so much for having me on. I’m always happy to come on the show.

[00:01:10] SY: Yeah, absolutely. So Chris, give us a little background about yourself. I know we talked to you before and I know that we talked about how you changed careers from being an HR professional to JavaScript expert, which is really, really awesome. We had that conversation back in 2020, but I’d love for you to give just a little bit of context for people who may not have heard that episode.

[00:01:30] CF: Yeah, absolutely. I’m known on the web as “The Vanilla JS Guy”. I didn’t coin the term, but I do spend a lot of time evangelizing JavaScript using browser native kind of stuff, and I help people learn JavaScript. My whole ethos is that there’s potentially a simpler, more resilient way to make things for the web than what a lot of modern best practices might look like. And so I spend a lot of my time creating courses and eBooks, running workshops, and every weekday I send out a short newsletter with some developer tips straight to people’s inboxes. You did mention the career change thing. So I actually started my career in human resources, did that for the first five or eight years of my working life. And then I made a career jump. So I’ve kind of got this really weird and unique background where I know what the hiring process looks like behind the scenes. And I’ve also gone through that process of just giving up on a career you were in the middle of to go do something totally different, which was really fun and wild and scary.

[00:02:30] SY: Yeah. That’s a great way to describe it, fun, wild, and scary. Yeah. Particularly the scary part.

[00:02:35] CF: Yeah, for sure.

[00:02:36] SY: So why the focus on Vanilla JS? What does that mean to you?

[00:02:41] CF: So the focus on Vanilla JS kind of happened by accident. I originally came into JavaScript development via jQuery, which was the way to do JavaScript on the web at the time, but I kept failing the JavaScript portion of front-end developer interviews, and I felt like I didn’t know what I was talking about most of the time. I had huge imposter syndrome. And so I decided I wanted to learn how a lot of it worked under the hood so that I could be more confident going into those interviews. And along the way, I discovered that as I was converting a lot of stuff I had written in jQuery to using the stuff baked into the browser, my sites were also getting a lot more performant. Things were running faster and there was just a better experience for the people who were potentially using the things I was making. And so that kind of really is what hooked me in the web performance angle, which was something I cared deeply about. You asked what Vanilla JS means to me. For me, it generally means an absence of dependencies. So it’s using the things that are built right into the browser. So browser native JavaScript methods or APIs rather than using libraries or frameworks. There is a bit of a caveat here because a lot of people think that means I write every single line of code and everything I build from scratch. I do make use of a lot of different libraries. I just tend to look for ones that aren’t dependent on another library themselves. So if I was looking for like a photo gallery library, I would look for one that just stands on its own rather than having to integrate with something like React or Vue or some other type of library.

[00:04:10] SY: Yeah, that makes sense. So you had pretty strong opinions about Vanilla JavaScript last time you were on the show a couple years ago. Do you still have those opinions now? Do you still feel that Vanilla JS really benefits developers and needing to know it should be a priority? Do you still have those feelings today?

[00:04:28] CF: I do. I’ve probably mellowed a little bit with age, but a big part of my passion for Vanilla JS is that, well, two things. One, if you author what you create in mostly Vanilla JS, you ship a lot less code to your end user, which means they’re using less bandwidth, which is particularly important when you’re working in developing areas or areas where wide access to broadband is not readily available. But a lot of times the actual process of building things is easier too, at least if you’re at a certain point in your career. I know for a lot of mid-level to senior engineers, tooling can make work a lot faster and easier. But for a lot of people who are earlier in their career, tooling becomes a barrier to entry. And so for me, understanding kind of the fundamentals and really kind of focusing on the platform means that you can open a text editor and open a browser and just start coding. And you don’t have to worry about opening up a terminal window and installing a bunch of things and running a build tool and then starting up a server. You can throw all that away and just start working. And even as a more seasoned developer, I still find that a very enjoyable experience. I do think tools have their place. I do think they’re an important part of what we do as a profession, especially as the things we build become more complex. But I also think that as an industry, we sometimes over prioritize them.

[00:05:53] SY: Yeah. Yeah. That’s very well put. So I want to get into the trends that you’re seeing in the front-end world. So I know that JavaScript tools like Vue and React are very common, very widely used. They’re definitely on the list of things that people should look into. They make that list very frequently. But you say that there’s an emerging trend around server-rendered HTML with little sprinkles of client-side JavaScript, kind of sprinkled around in there. So before we get into that trend, let’s break down kind of some of those basic definitions. So what does it mean for JavaScript to be on the client side?

[00:06:28] CF: When we talk about client-side JavaScript, we are talking about code that actually gets shipped from a server to the browser where it’s run. All of the front-end libraries that we use today are client-side libraries. So something like Vue or React. When someone opens an app that’s been built with those is generally downloading Vue.js into their browser or React.js into their browser and then running a bunch of code that calls functions that React has or supports. And so the client is just another fancy term for the browser.

[00:07:05] SY: Yep. Yep. Absolutely. And what is server-rendered HTML? What does that mean? So to answer that properly, I think maybe the easiest way to answer that would be to juxtapose it against what things like Vue and React do.

[00:07:17] CF: Okay.

[00:07:17] SY: So with tools like Vue and React, you have some templates or some HTML that you’ve authored in JavaScript. And when your JavaScript loads, those inject HTML into your user interface or into the DOM as it’s often called. The opposite of that, server-rendered HTML is where the HTML that gets rendered into the browser just comes that way from the server. So it’s a .HTML file and all of the elements that are in the UI or many of the elements that are in the UI, they just came that way hard coded into an HTML file. I mean, when I say hard coded, that doesn’t mean that you necessarily have to write .HTML files and upload them to your server. You can do that, but there are a lot of tools that kind of automate or blend the lines a little bit here. And I guess one other important thing to note would be that these two are not necessarily mutually exclusive. You can use server-rendered HTML for some things, and then layer JavaScript-rendered HTML on top of it, depending on your use case. You have to pick one or the other that can blend together very nicely, which is, I think, really the meat of what we’re going to talk about today.

[MUSIC BREAK]

[00:08:26] SY: So we talk about the trend of server-rendered HTML with sprinkles of client-side JS. What actually is the trend that we’re seeing?

[00:08:33] CF: For me, one of the things I’ve noticed, because I’ve been doing this for about 10 years now, is every five to ten years we see a big shift in the way development works. And it never looks like a big shift at the time. It always looks like some kind of emerging trends and then before you know it, it completely dominates the industry. So when I started, jQuery was the big way to do JS and then eventually the browser caught up and jQuery, I don’t want to say became obsolete, but a lot of the things it did, the browser could also do without jQuery. This stuff used to be really, really hard and suddenly it wasn’t anymore. Some stuff was still difficult. And so you had this wave of transitional tools, Umbrella JS comes to mind, that kind of bridged that gap. And you also had tools like low dash and underscores. And then eventually the browser kind of caught up to those two and new libraries started coming out that addressed a new set of problems. And that’s when we started to see things like Angular and then Vue and then React, and there was a bunch of other tools that didn’t necessarily that rise to popularity that showed up at that time as well. And I see us at the beginning of another shift. I’m starting to see a handful of tools that take some of the approaches or the ways that we build interfaces today. But move the actual generation of HTML from the browser to the server. So I’ve seen this happen from a few different angles. On one end, you’ve got things like Next.js and Nuxt.js that they’re like meta frameworks that bold onto React and Vue respectively and allow you to author your React or Vue code on a server running node, and it’ll generate HTM on the server, ship that to the browser, but then also ship React and Vue so that once that initial page load happens, JavaScript can take over and handle any additional changes that need to happen. Those are interesting, but they also still ship a ton of JavaScript to the browser. So then you started to see on the other end some tools that aim to do similar things as React and Vue, but smaller. So you’ve got Preact, Evan You, who created Vue, created this thing called Petite-Vue, which is like a smaller version that’s intended for maybe progressive enhancement or just some light UI changes rather than building the entire app in JavaScript, and that’s a lot smaller too. And so that’s kind of one other little subset. And then for a while you also had kind of the rise of static site generators. So these are tools that kind of go in the complete opposite direction and rather than bothering with JavaScript at all, you are writing some content in markdown and you’re writing some HTML, depends on the tool, but sometimes it’s Ruby, sometimes it’s Go. Sometimes there’s just plain old HTML, but it’ll take that markdown and mash it into some templates and create some HTML for you. And then we started to see just in the last, I want to say, six to twelve months, these hybrid tools start to come into play that take some of what Next.js was doing and Nuxt.js and some of what the server-side tools were doing and some of what like Preact was doing and mash them all together. And this is for me where things are starting to get really interesting. On one hand, you’ve got a tool like Eleventy, which is a static site generator, but because it’s run on Node and JavaScript, it allows you to do a bunch of scripty stuff on the server that you can’t always do with some of those other tools, and it can run dynamically and like generate HTML on the fly a little bit like we used to be able to do with PHP. So I’ve seen people do these really cool interactive apps with Eleventy. You’ve also got tools like Svelte and now Astro, which allow you to write your templates in a JavaScript-y way. So the same kind of code you would write with React or Vue, you do with Svelte. But rather than being a thing that runs in the browser, it’s a compiler. So once you’ve finished, you build your files out into HTML and it will take that code that you wrote and convert the mostly JavaScript into mostly HTML with a little bit of JavaScript so just edit the dynamic stuff as needed. So it’ll have hooks to do things like when someone clicks this button, update this element. And rather than putting a whole library behind that, it’ll spit out stuff that looks a lot like what you might do if you wrote just old school DOM manipulation with some Vanilla.js.

[00:12:59] SY: Now why would I want that? Why do I want HTML compilers?

[00:13:05] CF: Yeah. The big benefit of these tools is performance. So React and Vue and client-side libraries like that. Well, I guess there’s two. It’s performance and it’s also resilience. So those big libraries, they’ll share like the minified and gzipped size of them. And these are like kind of compression techniques that you can use to make files smaller. So you look at something like React and it’s 30 kilobytes, minified and gzipped. But that’s the size that gets sent over the wire. And that’s still actually quite a bit of code. But once the browser gets it, it then has to unpack all that code and it ends up being several megabytes in size. It’s pretty big. And then to run that code, the browser has to compile it and parse it and interpret it. There’s all these like under the hood things that happen before the JavaScript can actually run. And then every time you go to update the UI, there’s a bunch of abstraction on top that makes those updates a little bit slower. And then because you have all this JavaScript in place, you get this additional thing that happens where things can break. And when JavaScript breaks, the browser is a lot less forgiving than when HTML or CSS break.

[00:14:13] SY: Interesting.

[00:14:13] CF: So because it is a scripting language, everything just stops working. And this is like if you ever click a button and nothing happens or you open an app and you just get that like white screen of death where there’s nothing at all in the browser, it’s because the JavaScript broke somewhere. Something’s not working, and one error caused the whole house of cards to come crashing down. Whereas with HTML, if you type an element name wrong, the browser’s like, “Oh, we’ll just treat it like a div and move on.” And it just keeps going. And so the benefit of these tools is they create an output that gets sent to your user that loads faster, it’s less prone to breaking, and still gives you that state-based UI authoring experience if that’s a thing that you like or want. So if you’re someone who enjoys building apps the way you would with a tool like React, you’ll get that same experience, but you’ll produce something that is less likely to break and is going to work a lot better for your end users. And then where things get really interesting is there’s this newer kid on the block Astro that does the same thing that Svelte does. But rather than having to use like a Svelte specific set of conventions, you can pull in all of your favorite libraries. So you could pull in a React component and some tool that you really like from Vue and a Svelte file that you were already working on. And Astro will compile them all together and spit them out into just a little bit of JavaScript and like remove the library piece and just pull out the good parts. So actually one of the folks who works over at Netlify in Developer Experience, Jason Lengstorf, whose last name I’m almost certainly butchering. Jason, I’m so sorry. He actually ran a test with this, where he took this old site that he had built with React and Next and converted it to Astro using 90% of the same code. And the output client-side JavaScript was 10% of its original size.

[00:16:05] SY: Wow!

[00:16:05] CF: Decreased page load time by 30%. So just huge wins all around for the user with the same exact authoring experience that he had before.

[00:16:14] SY: Very cool. Very cool. So how do you feel this will affect front-end development in terms of the process, the steps. How would it affect what we do in front-end developer roles?

[00:16:27] SY: Yeah, there’s a few different views you could take of this. One of them is the short term, one of them is the midterm, and one of them is the long term. So in the short term, I don’t expect much will change. I think learning things like React and Vue are still great skills, especially if you’re looking for a job. You can roll into a job with those like right now, today. I think tools like Astro make the transition from, “I know these things,” to, “I’m doing it this new way a lot easier because you can take the tools you’re already using, make a few changes and go.” So they’re not necessarily huge changes. I think in the middle kind of range, looking out a little bit, we will likely see a few things happen. I imagine tools like React and Vue, just in their raw form, will become less popular over time. I don’t think it’ll ever go away. The same way that people still build sites with jQuery today and jQuery is still a huge presence on the web, even though it’s not necessarily the modern or new way of doing things. And a lot of what it does can be done in the browser. I still see a lot of jQuery. So I imagine same thing with React and Vue. They won’t go away. So if you learn those things today, you can continue to use them. But in the longer term, I expect that a lot of what we use libraries for today will eventually make its way into the browser. This is a trend that we see happen kind of a lot where this same thing happened with jQuery, where a lot of what jQuery could do was in the browser, and then you had these kind of transitional tools that bridged gaps for a little while, and then eventually the browser kind of fully caught up and we moved on to the next thing. And so what I’m not sure of, I think for me the big question mark is, “Are tools like Svelte and Astro transitional or will they be tools that are going to stick around for a long time?” My hunch is they will stick around for a while, but I’m not entirely sure. The other angle here, especially because I know we have a lot of listeners who are earlier in their career, learning some of these newer approaches, learning how to use compilers like Svelte and Astro, probably not a huge, like, “I need to know this right now for the job I’m looking for today,” kind of thing, but potentially a very powerful thing to know one to three years from now. I remember when I started working in the industry, responsive web design was a buzzword and it was very new. And this was the time where everybody used to have separate mobile and desktop sites and they were all set to a fixed viewport size. And if you went to a browser on your phone, you’d get redirected to like the m.myawesomewebsite.com version of the site, if you were lucky. Other times it would just be oriented for a desktop. And I can remember at the time, every interview I went on, I’d ask like, “What’s your approach to mobile design?” And you’d get a lot of folks who they viewed it as this thing that was going to come and go. I remember one interviewer in particular told me, “Oh, mobile’s a trend and one that I think is mostly done. Nobody wants to do this stuff on their phone.” [00:19:20] SY: Really?

[00:19:22] CF: Yeah. And like they were very obviously very, very, very wrong because mobile is not only not gone anywhere, it’s exploded.

[00:19:29] SY: Yeah.

[00:19:29] CF: But this shift I think has the potential to be not as big as mobile I think, but it has the potential to be like that because I can remember at the time I was this newer developer who was not super, super great at the way we were doing things today, but I had a much deeper understanding of responsive web design than a lot of the more senior developers did. And a couple of years down the road, that put me in a really good position to be kind of more of an expert on certain stuff than some of my peers. And so right now, today, I think we’re at the start of another shift, and if you invest some time into learning some of this stuff now you have the potential to be seen as the expert in the room in a year or three amongst people who maybe have a little bit more experience than you, but were ignoring some of this stuff to focus on the way things work.

[00:20:21] SY: And that was the question I was going to ask next is what timeline are we talking about? And you kind of just answered it, one to three years. Is that the way you envision kind of these trends really being front and center?

[00:20:33] CF: Yes. Although, I’m trying to think back now to how things went with like React and Vue because I remember React and in in particular Vue kind of showed up a little bit late to the party. Angular was like the elephant in the room for a minute. And it was weird. It was like a trend that started to grow very slowly and then suddenly it was everywhere. But yeah, if we’re talking about from today, one to three years feels like a pretty good bet. I’ve been seeing more conference talks around using some of these tools and how you can work them into your existing workflows. And so I think it’s going to be one of these things that we’ll start to see more awareness, more awareness, and then it’s going to be like the big thing and it’ll almost feel like unavoidable. We’re not there yet, but I think we’re headed in that direction.

[00:21:18] SY: So where does this fit into your general thing of being the Vanilla JS Guy? Yeah. How does that all fit in?

[00:21:31] CF: Yeah. So there’s a few pieces here. So a lot of my advocacy around Vanilla JS is really born out of a desire to prioritize the people who consume our stuff over us as developers. For a while, I used to talk about how UX is more important than developer experience, and it sometimes feels like we have that backwards where we tend to really love these tools because they make things easier for us as developers. And this newer suite of tools feels like it… I don’t want to say inverts that, but at the very least puts the user experience back in focus as a priority where the things that you’re generating are a lot smaller, a lot faster, a lot more resilient for the end users. And so I think that’s a very, very good thing. The other piece of this, I was literally just talking about someone with this yesterday about how one of the things you learn as you start to get deeper into libraries is that a lot of what you write in say React is mostly Vanilla JavaScript with some kind of helpers and utilities and stuff thrown on top of it. And a lot of my favorite Vanilla JS methods are things that people use in React quite a bit. And so I’ve had a lot of students who really struggle to learn these tools and then step back and focus on Vanilla JS for a little bit and then go back to them and find tools like React or Vue a lot easier to pick up because a lot of kind of the nitty-gritty details that get glazed over in tutorials, they suddenly have a better understanding of. And so for me, I think understanding Vanilla JS and also how things like HTML and CSS work are going to help people make transitions into these tools a lot easier as well. From a bigger picture, I’m probably someone who will still continue to just open a text editor and a browser and go, but I think these tools are going to be a really great thing for both developer teams and the people who use the things that we build.

[00:23:37] SY: Coming up next, Chris talks about how we’re going to see another shift in how we build websites and whether or not it makes sense to start looking into new tools now after this.

[MUSIC BREAK]

[00:24:00] SY: So I want to leverage some of your HR experience and kind of bring that into this context. If you were looking for a front-end job right now, and let’s say you gave yourself three months to prepare, three months to get your stuff together, to prepare to apply, how would you spend your time? What would you learn and what would you do?

[00:24:21] CF: Yeah. So if I was learning this today, if I only had three months, today, I would focus on, it depends. So…

[00:24:31] SY: Okay. Assuming you’re going for a front-end role, yeah.

[00:24:34] CF: If you’re just going for blanket marketability.

[00:24:37] SY: Okay.

[00:24:37] CF: It’s really hard today to go wrong with React. It is just very clearly… I don’t want to call them like market leader. I don’t know if that’s the right word, but it is the tool that you see come up the most often in job descriptions, in, “We’re looking for someone with experience with,” especially at newer businesses or job descriptions that are trying to attract up-and-coming developers. It’s just one of those phrases that you can throw on a job description and you know you’re going to get a large applicant pool. So it pains me to say, but it’s hard to go wrong with React, if you’re looking for a job today. The other kind of angle here, I think the reason why I said it depends is because there are still a lot of websites and web apps that are built with and use jQuery. One of the things, I’ve talked to a lot of WordPress developers who have told me they haven’t bothered moving away from jQuery because It’s already there. It’s already loaded in the UI in WordPress apps.

[00:25:37] SY: And that’s really used too.

[00:25:39] CF: Yeah. They’re already paying the jQuery tax, so they might as well just lean into it. So depending on what you want to do, if you’re someone who’s drawn to, say, the WordPress community and the WordPress ecosystem, and there are a lot of businesses that run on WordPress, there are also a lot of legacy applications and I don’t use this in a bad way, but like boring technology at boring industrial companies that still run on jQuery. And that can be an awesome career choice too because they often pay well, have really flexible work arrangements. They’re not kind of the hustle and bustle of an agency or a startup. So if work-life balance is really important to you, that’s not necessarily a bad move either. So depending on kind of whether you want a lot of change and the newest tech and a lot of excitement, React. If you’re looking for something maybe a little bit more boring and slow paced, and again, I do not mean that in a bad way, jQuery is not a bad choice either because it is still very much on the web and very much in use. And that’s if I only had three months. And that’s just from a technology side. There are a whole slew of other things I’ve been doing in conjunction.

[00:26:45] SY: Would it be valuable to learn any of these emerging new tools, these trends we talked about? Or would it make more sense to wait a few years and kind of see where these trends land to start learning them?

[00:26:58] CF: So it depends on how long you have. So if we’re just talking like, “I’ve got this three-month window,” I think going either deep on React or splitting your time between React and jQuery is personally the way to maximize your… I’m putting myself in the position of, “I need a job now. I need to pay the mortgage or rent, keep the lights on,” what have you. If you had a little bit more time, if you’re giving it six months to a year, I think learning these emerging tools now is a good thing to do because I’d say sometime in the next… if your company’s not or the company you go to work for is not already having these conversations, they will be in the near future. And being able to confidently speak to the pros and cons of different approaches you might use to building the new thing or updating your existing code base is a really great thing career-wise. I can remember early in my career when I was able to talk about responsive web design and concerns around mobile and best practices and usability. There were developers who were a lot more senior than me who were a lot less versed in this sort of thing, and it immediately positioned me as an expert on a thing that put me in a lot of conversations I wouldn’t have been in otherwise because of that. And while it’s probably, I don’t even want to say premature, I just don’t think you’re seeing lots of places in the industry immediately jumping to these tools, but I’m seeing more and more of it. And so I think at some point, these conversations are going to come up and it’s a really great thing to be able to speak about them.

[00:28:34] SY: Absolutely.

[00:28:34] CF: So, yeah, I would, if you have the time, if you were talking about a slightly longer term view, I think now would be a great time to start looking at these tools as well. Especially if you think about something like Astro where you can learn that in tandem with React, where you can do some React stuff and then bolt it into Astro and kind of convert your React app into an Astro build. It provides you a way to kind of run those things side by side and maybe learn these two different approaches at the same time, or at least one after the other.

[00:29:03] SY: Yeah, that makes sense. So for folks who do have the time to learn some of these tools, where do you start? Where do you begin?

[00:29:11] CF: Right. So I actually have not seen a lot of tutorials around either Svelte or Astro yet, which is probably a note to myself that I should…

[00:29:22] SY: You should do it.

[00:29:23] CF: I should consider.

[00:29:23] SY: Yeah.

[00:29:24] CF: Consider putting some stuff out on there. For right now, the websites for these different tools, they do a relatively good job of getting you started. So svelte.dev for Svelte or astro.build for Astro are probably good places to start. One other thing that folks might consider is heading over to Netlify and looking at some of their boiler plates and their starter demos. They have a really robust developer experience team that puts together a lot of kind of demo projects with these tools because they can be built and run on their platform. They have some things that might be worth poking around at, if you want like a project in progress that you can make some changes to and break some things on. That’s a good way to go. But Svelte in particular has a really nice tutorial section that walks you step by step through going from like a very simple hello world to adding some interactivity and it all just runs live in the browser, so you don’t need to download anything to get started. So that could be interesting for folks too.

[00:30:30] SY: Now at the end of every episode, we ask our guests to fill in the blanks of some very important questions. Chris, are you ready to fill in the blanks?

[00:30:37] CF: Yes.

[00:30:38] SY: Number one, worst advice I’ve ever received is?

[00:30:41] CF: That you need to have a five-year plan.

[00:30:44] SY: Tell me about that.

[00:30:45] CF: Yeah. So I’ve just always been bad at five-year plans and I’ve always been pushed heavily to have them. But one of the really nice things about our industry is that things change so dramatically in five years that having a five-year plan doesn’t always benefit you. By the time you get there, the industry had potentially moved on to a very different direction.

[00:31:06] SY: Yeah. Yeah.

[00:31:06] CF: Yeah. So if you’re someone who’s like, “I want to manage people,” awesome. If it’s more specific, like, “I want to work on this very specific technology,” well, that technology might not exist in five years or have gone in a very different direction.

[00:31:18] SY: Such a good point. Absolutely. Number two, best advice I’ve ever received is?

[00:31:23] CF: To start blogging every day.

[00:31:25] SY: Oh! Nice! Tell me about that.

[00:31:28] CF: Yeah. So I used to blog intermittently and I had a business coach a few years back tell me that I should start writing every day, which I thought was ridiculous because I figured no one’s going to read that much stuff. For me, it doesn’t seem like a lot. But one of the things that happens when you start doing that is your articles start getting shorter just out of necessity. And it means a lot of stuff that you previously considered too small to write about, you just write about anyways.

[00:31:53] SY: Oh, interesting. Yeah.

[00:31:55] CF: You discover that a lot of other folks may have had questions or not known about this thing that you just recently discovered that you thought was too small to share with other people, and it opens you up to this whole new world of people who are interested in a lot of like similar things to you, it also creates this amazing trove of like brain dump stuff that you otherwise would’ve forgotten about. And I’ve lost track now of how many times I’ve done a Google search and found a thing I wrote a few years back that I forgot about.

[00:32:23] SY: That’s cool. Yeah.

[00:32:25] CF: Yeah. So writing every day has been absolutely transformative for me.

[00:32:29] SY: Wow! Very cool! How long does it take you to write every day?

[00:32:33] CF: It depends. I generally try to keep it to under a half hour, so it’s like just a thing that I do while I drink my coffee in the morning. So I aim for about 15 minutes. Sometimes if I have like a big thing that I need to share, it’ll take longer, like 30, 45 minutes, which I know is not realistic for like a lot of folks. But yeah, I generally try to keep it to like 15, 20 minutes.

[00:32:53] SY: Nice. Nice. Very cool. Number three, my first coding project was about?

[00:32:58] CF: It was actually an HR blog. That’s what got me into coding in the first place.

[00:33:00] SY: Oh, cool!

[00:33:02] CF: I had this WordPress site. I wanted to have more control over how it looked and worked. So I started digging into the code and that’s what kind of kicked this whole thing off for me.

[00:33:11] SY: That’s really cool. Number four, one thing I wish I knew when I first started to code is?

[00:33:16] CF: That most folks are actually self-taught and mostly figuring it out as they go. I can remember when I started, I was under the impression that most people in our industry had computer science degrees and knew all this stuff and felt really, really like I didn’t belong. And after talking to a lot of people, I learned that most folks in our industry are actually self-taught or went through a bootcamp, and everybody’s just kind of figuring out a lot of this as they go. So there’s a lot of knowledge sharing and a lot of asking questions and not to feel so bad about not knowing all the answers.

[00:33:49] SY: Right. Right.

[00:33:50] CF: That was a really big light bulb moment for me that made me feel a lot more comfortable doing what I’m doing and really kind of made it click for me that yes, I do belong here.

[00:33:59] SY: Right. Right. You do. You do belong here. Well, thanks again so much for joining us, Chris.

[00:34:04] CF: Saron, thank you so much for having me. It was a real pleasure.

[00:34:14] SY: You can reach out to us on Twitter at CodeNewbies or send me an email, hello@codenewbie.org. For more info on the podcast, check out www.codenewbie.org/podcast. Thanks for listening. See you next week.