[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 front-end development with Laurie Barth, Senior Software Engineer at Netflix.

[00:00:18] LB: There are other languages, but the reason JavaScript is super common is because the browser has a JavaScript engine built into it, and that is what interprets the language.

[00:00:29] SY: If you have a question for Laurie after listening, don’t miss The Ask Me Anything Session she’s hosting on the CodeNewbie Community Forum. Just head to community.codenewbie.org and you’ll find her thread on our homepage and she’ll answer you directly in the comments. That’s community.codenewbie.org. In this episode, Laurie talks about the difference between front-end and back-end development, the difference between a front-end language and a framework and what people who are new to coding should consider when learning front-end development after this.

[MUSIC BREAK]

[AD]

[00:01:11] Hey codenewbies, are you ready to take your skillset to the next level? Maybe you want to learn SQL or interested in building a new app. Sometimes taking that next step can be intimidating, but we have good news for you. Cockroach university is a free online learning platform that teaches you the core concepts behind SQL databases and how to build a sample application there's quizzes, tutorials, and prizes along the way.

Get started for free today@cockroachlabs.com slash COVID. Twilio quest is a desktop role-playing game for Mac, windows, and Linux. To teach you real world developer skills. Take up the tools of software development. Become an operator. Save the cloud, download and play Twilio quest for free at twilio.com/score.

Career karma helps code newbies with free career coaching and a community of peers and mentors. To help you learn to code and find a high paying job in tech in less than a year. Download the clear karma app and get started in live audio rooms, hosted by bootcamp grads who landed coveted jobs in tech like Netflix, Tesla, Twitter, and YouTube.

Be one of the over 300,000 people they've helped get started. Visit careerkarma.com/

[AD ENDS]

[00:02:09] SY: Thanks so much for being here.

[00:02:11] LB: It’s awesome to be here as well. I’ve been listening to this show for such a long time.

[00:02:14] SY: We are honored to have you. So Laurie, you’ve worked a lot on a bunch of really amazing places. You were formerly at Gatsby and then you started working at Netflix not too long ago. Tell us about how you got started on this awesome coding journey you’ve had.

[00:02:29] LB: So I’ve been at Netflix for a couple of months now, but I started my career about, oh goodness, a decade ago now. And I started actually in the federal government, not as a software developer, but as a program manager.

[00:02:40] SY: Oh!

[00:02:41] LB: And it was my dream job and I was really excited about it. And I worked there for two and a half years and I hated absolutely every second of it.

[00:02:48] SY: Oh, no!

[00:02:49] LB: It was just a terrible fit for me.

[00:02:51] SY: What made it so bad?

[00:02:52] LB: So there’s sort of two things that made it so bad. I was bored.

[00:02:55] SY: Okay.

[00:02:55] LB: That was one piece, but two is I had a mathematics background and a minor in computer science. I was getting my master’s in computer science while I was there. The federal government does this funny thing where they try and make the workforce look smaller than it is. Yay politics! And the way that they do that is that they hire a bunch of contractors to do all of this work. And that’s super frequent in the technical space. And so they have government employees, which is like federal civilians, which is what I was, and our job is to manage the contract of the people doing the work.

[00:03:29] SY: Okay.

[00:03:29] LB: And so it was just a really bad fit for me. I was like, “I don’t care about cost schedule and performance really at all. Put me in front of a computer and let me do something. I didn’t get all this education for nothing.” When I decided I was going to leave, I didn’t think I had the chops to be a full-time coder. I was like, “I’ll get some technical analyst hybrid kind of job.” And I talked to internship bosses that I had and other sort of family connections, which I was very grateful for. And they were all like, “No. What are you doing? Go be a junior dev.” And I did. And I was a consultant at a couple of different places over the course of seven years. And when you’re a consultant, you see so many things and you work all over the stack and with all sorts of different technologies. And so it let me sort of figure out what I liked and I kept navigating towards, I call it middle end now, but it’s sort of like front-end tooling. And I got really used to not, “I’m super dogmatic about this one technology, but what is the best tool for this client?” And so I got to see a lot of things and that’s how I ended up at Gatsby. Obviously, if anyone’s ever seen me before, they know that I write a lot of blog posts and do a lot of instructional videos about normally JavaScript type things. So that was sort of in tandem with my work life. And so that’s how I ended up at Gatsby. And then when I left Gatsby, I went to Netflix to work on internal developer productivity tooling.

[00:04:52] SY: So how did you get exposed to coding in the first place? Where did that start?

[00:04:55] LB: When I was a freshman, I started working at the political polling center on campus because my two majors were mathematics and political science. So it made perfect sense, statistics and politics. And I worked there during the year, in the call center, and then after my sophomore year, I was sort of experienced enough to be a value for the summer. So I stuck around to be a summer intern and my boss, Angie, gave me a lot of crap to be perfectly honest. And she was like, “I graduated with all of these different experiences and all I have to do all day is teach myself computer science. I have to teach myself SQL. I have to teach myself parsing. All of these things are necessary. And if you’re going to work for me for the summer, I’m going to make you take CS 101.” I was like, “Angie, no, I’m not that person. I’m not the kid who’s been playing with their parents Commodore since I was 12 in the basement.” Frankly, I’m not that guy. That was the vision I had in my head. But she literally wouldn’t let me intern for the summer unless I also agreed to take CS 101.

[00:05:59] SY: Interesting. Wow! What a boss.

[00:06:02] LB: Right?

[00:06:03] SY: I love that.

[00:06:04] LB: She was at my wedding. Yeah. So I did it. I took CS 101 and I loved it and I took CS 102 and I was in DC for a semester and I interned at NASA working on their website and then I stayed for the summer and I interned at the White House and I worked on their website. And then I came back and decided to cram the rest of a CS minor into my senior year.

[00:06:28] SY: Ooh! That sounds intense.

[00:06:29] LB: I was very lucky because I was a math major and all of the CS courses at that time, my school didn’t have a CS major. It only had a minor and it lived in the math department. So all of those professors knew me and they were like, “We’re going to make this happen. We’re going to make this work.”

[00:06:44] SY: That’s awesome.

[00:06:45] LB: And so they sort of like Rubik’s Cube the schedule around so that could get it done. And so I ended up graduating with a Bachelor of Arts with one degree in mathematics, one degree in political science and a minor in computer science.

[00:07:00] SY: That is amazing. You really got a lot out of your college education.

[00:07:04] LB: Oh, yeah. I never went to a party in my life. But you know what? For my own reasons. Right?

[00:07:11] SY: Yeah. Yeah.

[00:07:12] LB: And it’s really interesting because I think a lot of people talk about like, this is a total tangent, but a lot of people talk about going to college for four years and what it means in the United States and how much it costs and people graduating and going to have a good time and find themselves in all of these things. And I’ve always been a proponent of wait to go to school until you sort of know what you want to do and you want to make the most of it. And that was 18-year-old me. I was always that person. So that worked. I could do the go from high school to college thing, but I think for a lot of people, it’s maybe not the right path, but that’s it. That’s a tangent.

[00:07:47] SY: Tell me about that first junior developer job. I’m curious specifically about the emotional part of that, because you said like, “Oh, I don’t know if I can do it. Maybe I should do a technical analyst position.” But I mean, you went for it. You did it. What was that like?

[00:08:00] LB: So it was interesting. I applied to three technical analyst roles and no one called me back.

[00:08:05] SY: Interesting. Okay.

[00:08:06] LB: I applied to nine junior developer jobs and seven of them called me back.

[00:08:11] SY: Whoa!

[00:08:13] LB: Yeah.

[00:08:14] SY: Very interesting.

[00:08:16] LB: Yeah. So first of all, this was over a decade ago and I think that’s important to say because so many people ask me these days, “How did you break in?” And my advice just does not apply. It just doesn’t apply anymore because it was a different universe.

[00:08:30] SY: Right.

[00:08:31] LB: But a couple of things happened. So I was lucky enough to have a few people that I knew, whether from internships or personal relationships who were in the field and could sit down and look at my experiences and say, “This is what your resume needs to look like.” So if it had all been about, “I was a program manager of technical projects,” no one was going to hire me. But when you were able to enter and leave that with, “I’m halfway through my master’s in CS and I’ve been doing these other coding things. And while I was on the job, technically as a program manager, I was also sometimes writing Java and JUnit code.” When I was able to piece that together, it looked a lot more impressive. I think seven places called me back. I got to second round with five of them. I got to final round with three of them. I got two offers.

[00:09:19] SY: That is not bad. That’s a really good hit rate.

[00:09:24] LB: Yeah. Looking back at it, I’m like, “I have no idea how I did this.” But it’s interesting because that I eventually chose is obviously the place that I have the most context on sort of how I ended up there. And I went into that interview, it was a hands-on coding interview. They gave me a laptop and sat in a room and there were two problems that they had me solve in addition to the other sort of white boarding conversational rounds. But they had me do like a tree traversal that I just happened to have studied.

[00:09:50] SY: Nice!

[00:09:50] LB: And the second thing was scraping a website and grabbing the URLs and turning them into something else. I can’t even remember, but it was nothing I had never, ever done before. I had no idea what I was doing and I had the Java docs open and they were like, “Oh, why don’t you look at this method?” And they were basically telling me how to do the exercise while I was there.

[00:10:11] SY: Okay.

[00:10:12] LB: Right? So I thought I was like, “I have no chance. I’m not going to get this job.” And I asked them later, I said, “Why did you hire me?” And they said, “Because you were so open to feedback. We knew we could teach you because you were really excited to learn.”

[00:10:24] SY: Very interesting. Very interesting.

[00:10:26] LB: Right?

[00:10:27] SY: Okay.

[00:10:28] LB: And that’s how I ended up with my first junior developer job. And once I got into the job, I realized that I had something my colleagues didn’t and they had something I didn’t. So they all had finished their masters and they had undergrads. And one thing that I say about most computer science programs, and this is just anecdotal, undergrad is a lot more applicable. It’s a lot more hands-on coding. A master’s is more about sort of like the architecture of software programs, if that makes sense.

[00:10:55] SY: Interesting.

[00:10:55] LB: And so I didn’t have the hands-on stuff. I hadn’t done as much other than my minor when I was an undergrad. And so all of my colleagues had more of that. They had built and written more code than I had, but I had worked more than they had. I had a sort of pick-my-head-up-and-look-around perspective on how the whole code base might look because I watched people manage these big programs in the federal government. And so it took a while for me to figure out how to build Maven for the Java back-end and understand how to use Git properly and configure intelliJ and all of those things, and those were really stressful moments and I really struggled with them. But I had a pretty good sense of when my code didn’t look very good and didn’t make sense or when I was working on a ticket that the business logic we were implementing didn’t make sense and we needed to revisit it. And so my tech lead and my program manager really appreciated that. And I was sort of able to provide this different type of value while I was ramping up on these other skills.

[00:12:03] SY: So I know that you worked at Gatsby as a software engineer. I’d love to hear a little bit more about that. Maybe starting with just what Gatsby is.

[00:12:12] LB: So Gatsby is a front-end framework. It’s built around combining React, which is another front-end framework, and GraphQL, which is an alternative to REST for interacting with APIs. And it’s designed to be incredibly performant. So it does a lot of things at build time instead of at run time. And that is to say you are creating an entire page of HTML that’s then just going to be given to your browser and it’s just going to work instead of your browser having to go through and interpret all this stuff and create the HTML for itself. And when I was there, I actually had two different roles. So when I started there, I was on the learning team and that meant I worked on our docs and I did some DevRel stuff and it was all around, “How do we teach people how to use Gatsby? How do we promote best practices?” And the company reorg a bit, specifically the learning team reorg, and it was moving over to marketing. And I sort of had a moment where I sat there and I said, “I don’t know if I want to move in that direction. I think I want to go back to being an individual contributor and sitting with code all the time.” And I am very lucky. The VP of Engineering at the time and my boss at the time and my to-be boss. Everyone was on board. And so I moved over to the themes team and the themes team was sort of the like developer enablement team. And it had all of the extras and bells and whistles that made working with Gatsby easier. So that was Gatsby themes and theme UI that was working on some of the CLI, command-line interface stuff that you do in your terminal to get a Gatsby project up and running. One of my final projects there was working with my colleagues on the next gen Gatsby image, which is one of the most complicated projects I will ever work on in my entire life. You have no idea how browsers treat images and fallbacks and it’s just hydration and very hard. Grateful to have learned it, but it was not easy. And like code mods, and basically I got a really good introduction and level of experience with all of the tooling that most people set up once on a project and don’t have to worry about, but when you’re building a framework, you have to think about it every day and you have to enable it every day. And I ended up in sort of this niche world of front-end tooling.

[00:14:38] SY: So how did you like that job, that world of front-end tooling? It seems very, like you said, niche, very specific.

[00:14:45] LB: I really enjoyed the work. Yeah. I think it is one of those things where as soon as you feel like you have a foothold in one area of it, like, I got really comfortable with Yarn Workspaces, for example, and then the next week it’s like, “Okay, now you need to learn Yargs and Inquirer to work on a CLI tool.” And then the next week it’s, “This is all about browser performance and understanding core web vitals.” So the goalposts are always moving and it stretched me and helped me grow from a purely engineering standpoint, probably more than any other role I’ve been in because all of the consulting roles I did, I was consistently working in different tech entirely. And so it would be shallow dives into everything from Python to PHP, to DevOps, to database design, to Vue front-end framework, that sort of thing. But in Gatsby land, it was a smaller pond. And so every time you dove in, you were going deeper and deeper and deeper.

[00:15:51] SY: And what about Netflix? What are you up to now?

[00:15:53] LB: Yeah. So now I’m at Netflix and the way Netflix is organized is it’s sort of two companies in one. There’s the streaming side, which is all the stuff we’re familiar with as consumers of the platform. So there’s a streaming app for your phone. There’s streaming on the browser, but there’s also streaming apps for PS5s and Roku TVs and all of those things. And then there’s the studio side because Netflix creates original content, which means it basically runs its own studio, and there’s lots of software and engineering that goes on for that. And because both of those sides have large groups of engineers, they share some resources and that’s called the platform team, and that’s where my role is. So I’m working on a system that’s going to help enable developers to discover and use all of the different services that are sort of turnkey for them. So you can imagine in a company that has engineers working on so many different things, having a way to just work with the Netflix cloud offering and node is like a turnkey solution. But how do you discover that that’s a thing? There’s an authentication solution or there’s a GraphQL solution or all these things, how do you find these systems? How do you figure out who owns them? How do you ask questions about them? How do you find out if they’re down or broken? So we’re working on a platform that does that.

[MUSIC BREAK]

[AD]

[00:17:35] Explore the mysteries of the Python temple, the OSS Elfa pant and the flame of opensource all. While learning the tools, uh, software development with Twilio quest become an operator. Save the cloud, download and play Twilio quest for free at twilio.com/quest. Career karma helps code newbies with free career coaching and a community of peers and mentors.

To help you learn to code and find a high paying job. In less than a year, download the clear karma app and get started in live audio rooms, hosted by bootcamp grads who landed coveted jobs in tech like Netflix, Tesla, Twitter, and YouTube. Be one of the over 300,000 people they've helped get started.

Visit careerkarma.com.

[AD ENDS]

[00:18:05] SY: So now I want to dig into front end, I want to dig really deep into front end. But before we talk about that, let’s talk about just the general difference between front end and back end, what they look like, what they’re about. Let’s start there.

[00:18:18] LB: So back end is where I started and back end is always interesting to me because it’s something you can’t necessarily see very well. So some people would consider back end to range all the way to like AWS cloud stuff, DevOps and databases, and that’s certainly a piece of it. But for most people, they consider it the API layer. And that is how you are retrieving your data and how your data is getting transformed or mutated before it’s passed onto your front end. And that can mean pulling data from a bunch of different resources. It can mean that you are consuming something that has timestamps and continuously serving it. So it’s both the method by which you give it to somebody else and the different pieces of the puzzle, the actual data that you’re pulling together. But the only way to see that is to have something like Postman, where you make a REST API call and you see JSON data in the response object. There’s no UI for back end. The UI for back end is front end. So front end is consuming those APIs and displaying them for users. Theoretically, that could be as simple as I’m going to make a REST call and then I’m going to spit out a bunch of JSON plain text onto a page and display it in the browser. That is a front-end. That is a way to display data. However, in the modern era, that’s interactive forms and buttons and styles and animation and manipulating data and giving you error messages that just exist on the front end because your password is invalid or your email isn’t really an email or so many other things. So it is basically everything between the API layer and what your end user sees. That is all considered the front-end domain.

[00:20:18] SY: And where does HTML and CSS fit into all of that?

[00:20:21] LB: So HTML and CSS is a front end. So if you had no API at all and you just hard-coded all of your data and said, “I want a list of names of people,” which you could do, you could put that in HTML, you could style it with CSS and you could save it as a file and it would show up in your browser and that would be a front end, and that would be all you needed. And you could have no styles at all and just have it be HTML and that would still be a front end.

[00:20:49] SY: So is it possible to do front-end work with just HTML and CSS? Do you need JavaScript? How does that work, especially in modern-day technology and building modern apps and websites? Is there still room for just a very simple HTML and CSS layer?

[00:21:04] LB: I would say plenty of people believe that there are. I would say it also depends on what you’re trying to do. We underestimate and in some ways under teach things that are available in HTML. The browser itself has a ton of APIs. So every time you console.log, that is the console API that is provided to you by a browser. That is part of the things you get. And the way we talk about that is not necessarily very clear. So you can absolutely make a site with just HTML and CSS. It will probably not match the level of interactivity and dynamic behaviors that you are used to when you go to your favorite shopping site, for example. That being said, not every interactive site is built with JavaScript. There are Python front-ends that people just forget exist. There’s this thing called Pyramid that is a framework for Python front-ends. There are other languages, but the reason JavaScript is super common is because the browser has a JavaScript engine built into it. And that is what interprets the language. And so when you write JavaScript on your personal computer, you download node because that’s giving you a JavaScript engine to allow you to run it locally outside of a browser and build your application. But once it’s in the browser, the version of JavaScript and the JavaScript engine that’s running against your code is what the browser is giving to you. And that’s why people talk about Internet Explorer and having to support Internet Explorer because that JS engine is older and there are certain things that you might write that Chrome can understand and Internet Explorer cannot.

[00:22:51] SY: Yup.

[00:22:52] LB: So many front ends are designed to be rendered in the browser nowadays. And in that situation, it’s “easier” to write in the thing that the browser understands. And so there are all of these frameworks that have been written to enable you to do that.

[00:23:09] SY: Tell me about the difference between a framework and a language. How would you kind of separate those two?

[00:23:14] LB: So for languages, the language is how you write your expressions. It’s how you define your variables and write your for loops and all of those things. A framework is giving you an opinionated way of defining those files where you write that language of passing around data using that language, of building that project and potentially deploying that project that’s written in that language.

[00:23:44] SY: So do you need a framework? Can you get away with not using one?

[00:23:48] LB: Absolutely. There are people who will admonish me for ever mentioning frameworks and say, “People who are learning should use VanillaJS.”

[00:23:56] SY: Yes. I’ve definitely heard that argument. Yeah.

[00:23:57] LB: Yeah. So just to be clear, VanillaJS is not a framework. VanillaJS is people’s way of saying JavaScript without a framework, but it’s really confusing if you’ve never heard it before.

[00:24:07] SY: Yeah. Yeah. Yeah. Well, I’ve always seen it as a joke website, I don’t know if it’s meant to be a joke website, but I don’t know if it’s just VanillaJS.com, but the thing that’s like, “Here’s this simple framework.”

[00:24:19] LB: Oh, yeah, yeah.

[00:24:21] SY: we’ll put a link to that in the show notes, but it’s really funny. Like if you know that JavaScript is not a framework, but if you don’t know that it’s kind of confusing.

[00:24:29] LB: Right. It’s super confusing. You can write things with JavaScript, with HTML and with CSS and have a JavaScript site. Absolutely no question. Why you would reach for a framework is a couple of reasons. If you want to get experience with writing something that could be production ready and work across multiple browsers, you often have build tools built into frameworks. What that means is you write your code using whatever version of notice set up for that framework and then it builds a version that’s targeted towards an older version of JavaScript that will run on all these different browsers. And you don’t want to have to worry about that yourself. And it comes with ESLint rules or pretty other rules that format your code and you don’t want to have to worry about that yourself and it comes with nice CLI commands that help you run in develop mode that you don’t want to have to worry about yourself. And it comes with libraries and helper functions and ways of doing more complicated rendering or state management that you don’t want to have to worry about yourself. And these are all buzzwords that come up as you extend past, I’m writing it to do app, for example. And to do it, apps have state. Right? So there are ways to do things in VanillaJS and the reason people reach for a framework is often because it helps larger teams be productive or more complex projects be productive or projects that are going to get iterated on over time be more productive. And so if you’re just one person learning, you might not want to reach for it. The reason people often do is because they want to learn the tools they expect they’d use as an employed software engineer.

[00:26:19] SY: So we talked about Python and we talked about JavaScript. What are the other coding languages that have a place on the front end side of things?

[00:26:29] LB: PHP is one that people might be familiar with, specifically if you’ve used WordPress, all of the templates are written in PHP. I’m pretty sure there’s Ruby code for front end. I’ve not written it myself, but I’m pretty sure that’s the thing. And then there’s a lot of different things that compile into JavaScript. So there’s lots of languages that are built on top of JavaScript, like CoffeeScript, which isn’t really as much of a thing anymore, but TypeScript, which absolutely is.

[00:26:57] SY: Why do I need a thing on top of JavaScript? What’s kind of the point of that?

[00:27:03] LB: A lot of people hate JavaScript.

[00:27:05] SY: Oh, no!

[00:27:06] LB: No. That’s sort of the tongue in cheek answer. Let me go back to foundations for a second here, actually.

[00:27:12] SY: Okay.

[00:27:12] LB: So JavaScript engines are in the browsers, as I mentioned before, and the JavaScript engines, because each browser has its own, these sort of need to agree, right? Because then you would have to write different code for Chrome that you write for Safari, that you write for Firefox, and that would be a nightmare. So they are all following a specification called ECMAScript. And ECMAScript is saying, “This is what an arrow function should do and what the syntax should look like and this is what optional chaining is and this is what const versus let is.” All of those things are in the ECMAScript specification. That is a living specification. There’s a group called TC39 that helps to make changes and add more features to the specification. And all of the JS engines are writing implementations that match that. So you have all of these JS engines in the different browsers, but they all adhere relatively to the spec. That means that JavaScript as a language can move sort of slow because it’s spec driven and this spec is run by a committee and each of the browsers have to implement things. And so if you want to either change behavior, that would be a breaking change and just have it as an expectation that this is how your language works, but it will compile down to JavaScript and run on a browser, that’s why you might make a wrapper. If you’re TypeScript, you might make a wrapper because you want type safety in JavaScript and JavaScript doesn’t have any typing. It’s not like Java that the name is a misnomer. There are no types. And so TypeScript was written to introduce type safety and it compiles down to JavaScript, but maybe someday the specification will allow for typing in JavaScript, but we can expect that will take years if it will ever happen. And so for people who wanted to see that, they needed to make something that existed on top of it.

[00:29:12] SY: So if I have all of these choices and I’m trying to figure out, how do I, number one, get started and also kind of where do I want to end up? Right. What kind of languages do I want to be familiar with? What should my tool set be as a front-end developer? I’m sure they all have their ups and downs, their pros and cons, but how do I decide? What are some factors I might want to keep in mind as I figure out my front-end toolset?

[00:29:34] LB: Don’t listen to Twitter.

[00:29:35] SY: Okay.

[00:29:37] LB: There’s a couple of different nuggets of not wisdom so much as my personal advice based on that. So one is once you pick something, by the time you’re finished learning it, it’s not going to be the newest and the shiniest, and that’s okay. Don’t switch. Keep learning something and learn its surface area as much as you can. Because if you learn anything in technology, as completely as you can to feel comfortable building something real in it, then when you switch to a different technology, you’ll be able to map the patterns and it’ll be easier to learn the next thing versus if you keep shifting and jumping around, you’ll never solidify those patterns in your brain. And I say this as someone who did CS 101 and CS 102 in Java, and then had to finish my CS minor in Python and my brain broke. And there are patterns that I didn’t learn until five years on. So personal advice. The second thing is don’t listen to Twitter because Twitter will convince you that you should change because Twitter is where all the people who are building the bleeding edge things are and some of those things are going to be wildly successful and some of those things are going to fail and you’re never going to hear about them again. But for 24 hours or two weeks, or even two months, you are going to see that name everywhere and you are going to convince yourself that if you don’t learn this, your career is dead in the water before you even start it. And it’s not true.

[00:30:58] SY: Yeah.

[00:30:59] LB: So pick what you want to work on and then stick with it and don’t let anyone dissuade you from it, because even if they’re right, even if you should have learned this other thing, it’ll be easier to learn that other thing once you finished learning the thing you’re already learning.

[00:31:13] SY: Yeah. Yeah, absolutely. I think it’s a huge problem in our community is just jumping around or hearing about what the new and latest hot thing is, jumping on that and then it kind of fades, interest wanes a little bit, then you move on to the next hot thing and it can be really hard to make any kind of progress when you’re approaching learning that way.

[00:31:32] LB: Absolutely. And to that end, look at where you want to work. Do you have a specific industry and you want to work in their tech department? Because let’s be honest, there are tech companies and then most companies have tech. Do you want to work in a local place and you know your general market area, your geography? Look at that. Are you 100% convinced that when you finish learning code, you want to get a junior developer job in San Francisco and move there? Okay. Relevant knowledge, take that and look at real live job descriptions, because if you were to go by the internet, you were to go by blog posts, if you were going to go by Twitter, if you were to go buy Twitch streamers and YouTube videos, there’s like three things you would ever learn.

[00:32:18] SY: Yeah.

[00:32:19] LB: And can I tell you that there are three things that exist in production code? If you were to listen to any number of people, Angular is dying and/or dead. Angular is everywhere in enterprise. And enterprise is big companies and big companies hire junior developers. They hire entry-level people because they have the structure to support them. So do not learn Angular because you think the only thing that can ever make you successful is React. We’ll get where you want to work and what you want to do and pick those tools. And that being said, you’re going to look at a list of 20 technologies and freak out that you have to know them all.

[00:33:00] SY: Yeah.

[00:33:00] LB: You don’t. Pick a framework. And I will say, if someone’s going to argue with me when they hear this episode, I think it’s really important to learn HTML well, I think it’s really important to learn CSS well. I am not one of those people who thinks you have to learn those before you pick up a framework.

[00:33:17] SY: Ooh, controversial. Tell me more.

[00:33:21] LB: I am a display down person.

[00:33:23] SY: Okay. What does that mean?

[00:33:24] LB: The way that I learn is I see something working and then I want to understand why, and I want to dig into it and I want to break the thing that I had working or change the thing I had working and say, “Oh, that controls this and this controls that,” but I need example code. I need patterns to match. I need something that works before I can start to break it down and learn it. So it’s a lot easier to get something working and get something live and see what would “be production code” or grab someone’s GitHub project when it’s already in a framework because that’s what people write these days and that’s what exists. So look at the framework, look at the code, and then break it down. Try and figure out what’s the framework, what’s JSX, what does that mean the HTML tags are versus the components. Look at the class names. Are you using some sort of like SASS or LESS or CSS and JS solution? Are you using style sheets? Figure out all of the layers of what you’re looking at and learn it that way.

[00:34:27] SY: That’s an interesting perspective. I like that. So tell me about frameworks. We spent a lot of time talking about languages. What are the frameworks? You mentioned Angular was one. What are some of the others?

[00:34:38] LB: Angular, React, Vue, Svelte. Then there’s the meta-frameworks like Gatsby and Nuxt and Next and Redwood.

[00:34:48] SY: Oh, boy!

[00:34:48] LB: I know. And here’s the thing. It’s analysis paralysis.

[00:34:51] SY: Yeah. Yeah.

[00:34:52] LB: So the big three have been around for a while. Svelte is sort of the new kid on the block, but Vue, React and Angular are probably the most common solutions you’re going to see. So someone is going to yell at me for calling React a framework because it’s technically not, it’s a library, and we’re not going to get into that distinction because for all intents and purposes, people treat them the same, and I don’t want to have that argument over semantics, even though it’s technically true.

[00:35:16] SY: Okay.

[00:35:16] LB: So if someone says, “React is a library,” okay, fine. Not the point. Is Vue a framework and React is a library? Maybe, probably, and one can’t be used with the other. So what is the point of this debate? The meta-frameworks are using one of those three frameworks and they’re doing one of two things. They’re either extending it to provide for something like server-side rendering, which you probably don’t need to understand at this point in your journey, just know that it’s a different way of making something performant and it has different trade-offs and that’s cool. Or they have decided that Vue, Angular, React are the wild, wild west of frameworks and they don’t enforce best practices and they don’t enforce certain patterns. So this meta-framework exists to be more opinionated to give you bumpers as it were as if you were bowling and say, “Okay, you should only do this.” And that’s really helpful when you’re learning. But it also means if you pick a meta-framework that doesn’t work well with what you’re trying to accomplish, you’re going to wind up fighting it the whole time.

[00:36:25] SY: So when it comes to frameworks, you mentioned kind of the big ones, but then there are just so many other ones. I don’t know if you know the answer to this, but why are there so many? Right? Why are there so many different interpretations and opinions of how to do front-end? What are some of the big differences between them?

[00:36:41] LB: So do we want the diplomatic answer or the sassy answer?

[00:36:48] SY: I’m kind of curious to hear both, if you’re comfortable with that.

[00:36:51] LB: This sassy answer is the JavaScript pros always think they’re right and therefore can build it better than the last person.

[00:36:58] SY: Okay.

[00:36:59] LB: And not just pros, but…

[00:37:01] SY: People?

[00:37:02] LB: People.

[00:37:03] SY: People.

[00:37:03] LB: The diplomatic answer is they’re each designed to solve a pain point that the creator found in a different language when applied to their use case.

[00:37:13] SY: Right.

[00:37:14] LB: And that’s the super important part is I see this sort of across the board about technologies where someone says, “Why would you ever use jQuery? jQuery is stupid. It’s nonsense. It’s outdated. Why would you ever use it?” It’s like jQuery was designed to solve a specific problem, and you may have decided that there are things that solve it better now, but you may not be right. I see this more with PHP. People are like, “PHP is terrible.” I was like, “But there are problems that PHP sells better than JavaScript does.” There are problems that Angular solves better than React does. There are problems that Next solves better than React does, but there are problems that React solves better than Next does. Right? And they’re built on each other. So Next is a meta-framework of React. It does server-side rendering. There are lots of things that it does that would be harder to do it in React unless you really knew what you were doing and you wanted to write a lot of code yourself. But if you really know what you’re doing with React, you may find yourself fighting against Next.

[00:38:19] SY: Lots of options. Wow!

[00:38:20] LB: And that’s the thing is you can’t make a bad choice when your goal is to learn. You really can’t.

[00:38:26] SY: Yeah. Yeah. I like that. Coming up next, Laurie talks about common combinations of front-end tools after this.

[MUSIC BREAK]

[AD]

[00:38:53] Hey codenewbies. Did you know that all apps need databases? Take a look at your phone and see what apps you have. Instagram door dash, Venmo, Lyft. They all use databases, databases make up the software layer that power our apps and most databases you sequel for writing and querying data. So once you master coding, you're going to want to start to consider the tools you need to create your app, including the data.

The expert, the couple flaps, the company behind the leading database solution. Cockroach DB offer free courses for all skill levels taught by in-house experts. You'll learn about SQL databases and building applications with quizzes, tutorials, and prizes along the way. Visit  dot com slash  to take your coding skills to the next level and get one step closer to becoming a software developer.

[AD ENDS]

[00:39:45] SY: So if you are a new developer, just getting started, what are some things you should consider when it comes to learning a front-end framework? What are some factors that I should think about?

[00:39:55] LB: Figure out where you want to be when you’re done with your learning journey, I think, is the first one. So if you are looking around, we mentioned this sort of job in your area and everyone’s learning Angular, maybe you want to learn Angular. And if you’re learning just to learn, you can choose literally whatever looks fun. If you’re learning with a specific goal in mind, take that into account when you pick your framework. If you have total greenfield, every option is open to you and there are absolutely no criteria helping you pick, this is how I break down the frameworks. Someone’s going to yell at me. Angular is incredibly opinionated. Pretty much everything Angular does, it has its own specific name for. It puts like NG in front of it. And that makes it great once you learn it, but the learning curve can be super high. React is what I called the wild, wild west of frameworks and that’s why it became so popular because it’s super extensible and transformative and you can use it for a bunch of different things because it’s not as opinionated. But it’s so far not opinionated that there’s no expected router that you use. There’s no expected state management that you use. There’s all of these different options. So once you pick React, then you need to pick a library for this and a library for that and a library for that and a library for that. And so if you are overwhelmed by picking a framework, maybe don’t pick React because then you’re going to have to pick a bunch of other things. The happy medium in between, there is normally Vue. Vue comes with Vuex and Vue Router that are the expected best practices way of doing things. Vue has a very great and welcoming community. It probably doesn’t have as many tutorials and blog posts as some of the other ones do.

[00:41:40] SY: There’s also meta-framework, which I think you may have mentioned a little bit earlier in this conversation. What are meta-frameworks? It seems like something designed just to further confuse new people. Is that basically what it is?

[00:41:53] LB: No. It’s not, but it has the unfortunate consequences of further confusing new people.

[00:42:00] SY: Yes.

[00:42:00] LB: So meta-frameworks, a lot of them are built on React or Vue. I’m sure there’s Angular meta-frameworks, but I’m not as familiar with them. And basically they are opinionated wrappers on top of those frameworks/library. So Nuxt for example is a way of creating a more performance, slightly more opinionated site using Vue. It’s called Nuxt. It’s built on Vue.

[00:42:26] SY: And why do I need to wrap a framework?

[00:42:28] LB: So wrapping a framework is where you get even more benefit on the things like build rules or it does prefetching of links for you like Gatsby does or it comes wrapped with GraphQL or it has a whole plugin ecosystem. When you get to the point of a meta-framework, if it is opinionated enough, then developers can make really strong assumptions about how things are going to work and build other opinionated things for you to use. So the plugin ecosystem that exists around Gatsby, there’s some stuff in Next land, all of these different meta-frameworks have these turnkey solutions for e-commerce or integrating with the GitHub API or performant images. And they’re able to do that because they know things about how the site will build when it’s built on Gatsby or Next no matter what, which isn’t really true if it’s React out of the box. There isn’t enough there. There’s enough different directions that framework can go in. There’s enough different implementations that can happen, but it’s very hard to build a turnkey solution.

[00:43:39] SY: So we talked about languages, frameworks, meta-frameworks. Let’s kind of bring them all together. What are some common combinations of these three layers that we might see in production?

[00:43:51] LB: Yeah. So every meta-framework I mentioned is based on the JavaScript language.

[00:43:57] SY: Okay.

[00:43:57] LB: So you will be writing JavaScript. That being said, for stuff in React land, for example, you’re going to be writing something called JSX and this confuses people. And I think it’s important to explain what it is. So JSX is a way of writing, basically HTML templates in JavaScript. So you’re going to see DOM elements. You’re going to see an <a> tag and you’re going to see an h1 and you’re going to be looking at a large div or main just as you normally would, but intermingled with that is going to be JavaScript code. It’s going to be things that look like HTML tags, but are custom things called components that you defined or it’s going to have slightly different APIs for passing things around or using variables from your JavaScript in that JSX. And so you have languages, in this case, JavaScript, which is how you are writing your code. You have a framework that wraps around them that gives you opinions and other helper utilities for how they expect you to write your code. And then a meta-framework is essentially a more opinionated version of a framework.

[00:45:17] SY: So I want to talk about the history of front end and how it’s changed over time. You’ve been encoding in tech for a decade. So I’m curious, where was it when you first started? What was kind of the state of front end back then and where we got into today?

[00:45:32] LB: Templating is the best way I can describe it.

[00:45:34] SY: Oh, interesting.

[00:45:35] LB: And templating still exists. If people have seen Handlebars or Mustache or any of those things, they’re still real. They’re in the wild. One of my first roles was using Struts, which is a throwback for a lot of people. But it was a Java back-end and Struts was basically templating using variables and then there would be like random jQuery script tags in a given file to give it additional functionality. Once I moved past that, it was Angular 1. And Angular 1 is not the Angular you learn today.

[00:46:09] SY: Right. There was a major change. Was it between two and three where there’s a major change or was it one and two?

[00:46:14] LB: No. It was one and two.

[00:46:15] SY: One and two. Okay.

[00:46:16] LB: So Angular 2 was such a major change that if you look it up, people will call it Angular.js versus Angular.io.

[00:46:23] SY: Oh, wow!

[00:46:24] LB: Like Angular.js is 1.0 and then Angular or Angular.io is anything past two. And like TypeScript 1.0 was just starting when I was a couple of years into my career. And so I’d say the biggest change, there’s probably two biggest changes. One is animation. So the levels of things that you can do in native CSS are wild. There are a lot of CSS frameworks that have come like SASS or LESS. And the W3C who are the people who do the CSS specs, so TC39 does the ECMAScript spec and W3C does the CSS spec, they have taken a lot of those awesome things from these CSS wrappers and decided to make them part of the native spec. So there’s lots of changes in that space. JavaScript, the language has come a long way. There’s been a ton of things added. A lot of the array functions that people reach for all the time, .map and .filter and .reduce, those things weren’t there yet. But I would say that the front end was a much thinner layer than it is now. So you didn’t have nearly as many dependencies in libraries. NPM was sort of a twinkle. I think it was just getting started, but it was like not nearly what it is today, the availability of third-party OSS tooling wasn’t nearly what it was today. And your concerns as a front-end developer were much smaller, which is why I could be a Java back-end developer and learn on the job some front-end stuff and then grow as the front-end ecosystem group. So I didn’t start out as a front-end person at all. I started out as a back-end person and the only reason I’ve been able to end up as a front-end tooling and front-end area specialist, I consider myself probably a little bit of both, but the only reason is because I got in sort of like when it wasn’t as much a thing. It was a thing, but it was the layers of concern and the breadth of it was not where it is now, which is hard. I feel like I’m making this sound terrible for people breaking in now. I don’t mean to.

[00:48:41] SY: I mean, there’s a lot to learn. It’s a growing industry. We are producing and iterating and innovating. So that just means we have more options. We have a breadth of things that we could possibly learn.

[00:48:52] LB: Exactly.

[00:48:53] SY: So tell me about the skills needed to be a successful front-end developer, whether that’s kind of soft skills, technical skills. How do you think of some things that people should develop in their career, in their skillset that would make them really good at front end?

[00:49:07] LB: So we’ll start with a skill that I do not have, which is the ability to match a design to an implementation.

[00:49:14] SY: Oh, interesting. Okay.

[00:49:15] LB: And one of the skills that you should have that I would say I do have is to look at a design that somebody has and break it down into its disparate parts. I think this is true of programming in general that you can look at a hole and find smaller pieces to implement and build into that bigger piece, how to break down a problem. That being said, for front-end developers, that often means design. And if you look at a mock-up and you’ve implemented the component and you can tell if it’s slightly, like the pixel is like two pixels off, that’s a really great skill that I do not have. And designers will come to me all the time and be like, “Oh, I made some tweaks.” And I was like, “Great. Sounds good. No issues with that.” So that’s a useful skill. I would say the ability to be uncomfortable because front end is so large that you’re almost always going to be implementing something and digging into something that you’re not familiar with. So the ability to understand the overall concepts at play, whether that’d be package managers or build tools or browser APIs or DOM elements or the framework you’re working with, I just named a lot of things, but understanding those different pieces in the abstract and just saying, “Okay, these are all these things.” And then when you see a problem, looking at each of those things and saying, “Okay, it’s not that that’s causing this and it’s not that that’s causing this. So being able to piece out the layers. And I want to say, clearly, I grew this scale over the last 10 years. I have this skill a lot more now than I did when I started. When I started, it was all one big black box. And that’s okay. But it is a skill to work on it. It is a skill to grow into because it helps you solve problems. And one of the challenges of front end is that there are so many layers and so many different things that are integrated into each other and intermingled that it can be hard to tease them apart and figure out what’s going on.

[00:51:15] SY: Yeah.

[00:51:16] LB: And then I would say the last thing is communication. So as a front-end developer, you’re working with designers, you’re working with project managers, you’re working with your API implementers, if you’re specifically front end and not full stack, you are talking to everybody because you’re the combination of all of those different pieces. And when you create the UI and what shows up on screen and how these things interact, that’s often where you start to see who missed what or what’s not really coming together and what logic doesn’t really make sense in practice or we missed accessibility or we didn’t think about how we would deal with internationalization or this doesn’t really make sense because the workflow of this login is confusing, this isn’t a great user experience, you see all of those things when you build your pages, when you work on the front end. And the ability to figure out how to move forward and iterate and make recommendations or raise your hand and just say, “Hey, this just doesn’t look right to me,” is super valuable.

[00:52:27] SY: Where do people go wrong in their front-end careers and developing their skills? We mentioned kind of hopping around and jumping from one topic to another. Where else do people kind of get it wrong, some pitfalls they might watch out for?

[00:52:40] LB: Hyper-focus on JavaScript.

[00:52:43] SY: Oh, very interesting. You just say some controversial stuff. Tell me more about this one.

[00:52:47] LB: So my first job where I was the Java developer and I was learning front end, we had a unique setup that I’ve never seen before or since. We had designers and our designers were truly CSS implementers. So they made the design. I wrote the Angular code and I made the DOM structure and they styled the whole thing for me. They styled the whole thing for me. And it gave me the ability to focus on Java and hyper-focus on JavaScript. And it’s interesting that I had that experience because I know that’s not a pattern that exists at many companies, right? That’s just not a thing that people do. It was sort of a weird thing at that company. And when I see the way that people teach front end and talk about front end, I recognize that those developers are going to come with the same skills I had. And in the way most companies are structured, that’s not going to work. So it’s great to understand performance, one millisecond, five milliseconds, isn’t going to matter to the user if your hover state and what you’ve selected on the screen overlaps with a modal and they can’t click it. So it’s great to learn the functionality. It’s great to be cognizant of performance and care about the fact that you could use a for-loop versus a filter. I’m like joking about things that people argue about on Twitter, right? But that’s not going to make or break your success. You’d be better off understanding how to deal with state, understanding how to display the data and then figuring out how to style it and figuring out how to make sure that when you use keyboard navigation, all of your tab indexes are right and that your screen reader isn’t super screwy and that it shows up on IE because you have whatever the polyfills are that are necessary. And I want to put one giant caveat here, and it’s a depressing one. It is easier to interview for JavaScript skills than it is to interview for those other things. So the skills you’re going to need when you get to the job might not be the things you had to study for to pass the interview.

[00:55:01] SY: Yeah, that’s a good point. So let’s talk about where people can get started. If people hopefully are excited, interested in the front end world, what’s a good place to start? What’s a good first step for them?

[00:55:14] LB: It depends how you learn. I think that’s really important. So are you someone who likes to watch someone do something? You can do that for free on Twitch right now. There’s a bunch of developers who are constantly streaming as they’re coding.

[00:55:27] SY: Yes, bless their souls. I tried that once, I was exhausted. Oh my goodness! I don’t understand how people do it.

[00:55:33] LB: It’s super draining.

[00:55:35] SY: Oh, it’s so draining. And it was so slow. It was so slow.

[00:55:39] LB: Yeah, but it’s also great because you get to watch people you look up to who are super smart and talented and you think have all the answers rack their brains over the fact that they were missing a semi-colon for 20 minutes.

[00:55:52] SY: That’s why it’s the best.

[00:55:53] LB: So you can do that for free on Twitch. There are also really great subscription services. So Frontend Masters is one of them. That’s normally like battle courses that are on a specific deep dive in an area. There’s also Egghead. I’m an instructor for Egghead. There’s a lot of front-end focused stuff there as well. If you are a reader, there are tutorials abound, and it can be challenging to figure out sort of what’s worth your while to work through. And I recommend for those ask around, like ask your friends what they’ve used or see if you can find something that’s got a lot of reactions to it. Check the date. If you’re trying to look at something with the latest framework or current version of a framework, you may recognize that tutorial’s out of date. For example, hot tip, if you were searching for anything written in React and you are using React 16, React 17, add Hooks to your Google Search. If you don’t, you’re going to be very confused. Add Hooks to your Google Search.

[00:56:55] SY: Okay.

[00:56:56] LB: And then I’d say the last thing is look around GitHub. Are there projects that you use sites that you’re familiar with? Find examples of what technology they’re using and some small pet projects that someone’s working on. That’s the wonder of OSS code, because you can look around other people’s code and you can clone the whole thing, put it on your computer and say, “What makes this thing tick? I’m going to try and break it. I’m going to try and change it.”

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

[00:57:35] LB: Yes.

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

[00:57:42] LB: Don’t turn down a job because of the commute.

[00:57:44] SY: That’s the worst advice. Oh, that’s so interesting. Tell me more about that.

[00:57:48] LB: So I was told by someone I love and trust that it was silly for me to turn down a job and potentially halt my career because I didn’t want to drive 45 minutes to an hour in traffic every day. And they were wrong. They were wrong for two reasons. One is I am a grumpy human when I have to drive long distances. I'm far grumpier human when I have to do so in traffic. And if you want me to do that on my way to work and coming home from work, I’m not going to be a fun person to work with.

[00:58:17] SY: Yeah, that’s fair.

[00:58:18] LB: The second reason for that is my refusal to do such things is what led me to remote work, which is what has changed my life in numerous ways and sort of changed my presence on the internet and allowed me to do a bunch of other things.

[00:58:33] SY: Nice. Very cool. Number two, the best advice I’ve ever received is?

[00:58:39] LB: Write what you learned.

[00:58:41] SY: Oh, I love that. Tell me more about that.

[00:58:44] LB: So I had gotten into conference speaking and I was a little bit burnt out from all the travel. I loved it. I love meeting people in person. Obviously when we were in person, it was an incredible community to be a part of. I still consider myself a conference speaker, even though I’m sort of on a hiatus, but it didn’t scale. And I found that I would put so much time into a talk for an hour when I could put far less time into a blog post that could be consumed by a whole lot more people and would always be sitting there for me to refer back to when I inevitably forgot what I wrote about and what I learned. And I referenced my stuff all the time. Other people reference my stuff all the time and it has absolutely changed the opportunities that are available to me in my career.

[00:59:29] SY: That is awesome. Number three, my first coding project is about?

[00:59:34] LB: Okay. So there’s two. This is a little bit of an unfair question.

[00:59:37] SY: Okay.

[00:59:37] LB: So my first coding project that I didn’t realize was a coding project was when I was in high school and I was taking the mandatory computer class. It wasn’t like a computer science class. It was just a computer class. And they used this software called Jurtle and it’s this little turtle that goes around on like graph paper and you have to give it coordinates and my teacher for our final made us draw letters in the alphabet.

[01:00:00] SY: Okay.

[01:00:01] LB: So that was technically my first, but I’d say the first thing I considered as a project is I had to do the Game of Life in Java, and I thought it was going to be so complicated because it looks so cool rendered on the screen. And then I realized that the logic was all I had to write. And there were these really cool rendering libraries that made things appear animated on screen.

[01:00:23] SY: Very cool. Number four, one thing I wish I knew when I first started to code is?

[01:00:29] LB: I mean a lot of things, but I learned them over time. So I guess that’s probably what I wish I knew. I wish I knew that you can learn almost anything once you have a pattern you can match it to. So if you’ve learned one thing, you can figure out how that other thing is similar.

[01:00:49] SY: I like that a lot. Well, thank you again for joining us, Laurie.

[01:00:52] LB: Thanks for having me. This was awesome.

[01:01:01] SY: This show is produced and mixed by Levi Sharpe. You can reach out to us on Twitter at CodeNewbies or send me an email, hello@codenewbie.org. Join us for our weekly Twitter chats. We’ve got our Wednesday chats at 9 P.M. Eastern Time and our weekly coding check-in every Sunday at 2 P.M. Eastern Time. For more info on the podcast, check out www.codenewbie.org/podcast.