Brian: PodRocket is sponsored by LogRocket, a frontend monitoring and product analytics solution. Which is to say, it's not really sponsored by anyone, it's sponsored by us, LogRocket. And, we're giving it away for free. The podcast is free, the product is not free. There's a free trial we could split hairs about whether or not that's free to you, but anyway, that's it. There are no more ads. Brian: If you're interested and you want us to know that you came from the podcast, please go to Logrocket.com/podrocket. If you don't care, Logrocket.com works just fine. Thanks. Hello, welcome to PodRocket and this is the second episode of Rocket Surgery with me and Kaelan. I'm Brian, that's Kaelan. Hi, Kaelan. Kaelan: Hello. Brian: Kaelan is our front-end developer at LogRocket for those of you who missed episode one, which was, I want to say way back in January when we did a year in review for 2020. I think maybe we were a couple of weeks too late on that. So with this episode, I think we're going to be right on time. What we going to talk about today is two articles, and maybe one idea. They are written by Chris Coyier from CSS-Tricks and Brad Frost. Brian: Chris wrote The Great Divide, and Brad wrote, this is tough to say, so I hope I don't mess it up, Front-of-the-Front-End and Back-of-the-Front-End Web Development. That was actually easier than I thought. I know, so I don't want to say that these articles necessarily caused a stir, because at least from what I read, I don't think the discussion made anyone upset. It was just kind of a genuine- Kaelan: Self-reflection. Brian: Yeah, thank you, self-reflection. And, so Kaelan and I were talking about it, and it turns out that Kaelan has also spent some time reflecting on himself and his profession, and has some thoughts. So, I think probably the best place to start is let's kind of summarize what each of the articles say really quickly. Kaelan: Yeah, probably more meta topic than what we're used to at LogRocket, but it's important one. And, that's something that any front-end focused person, and I use those words very carefully, has asked themselves and their coworkers. Especially anyone looking for a job anytime in the last 10 years, which is probably everyone listening. But, basically the nature of front-end development, should front-end developers be required to both be very knowledgeable in CSS, and HTML, and bundle areas, and React, and Angular, and insert 20 other things. Kaelan: There's a good segment of people who come from the back end who are now doing frontend, and they tend to be more engineering focused. And, then you have a whole segment of people who came from design, and they tend to just stay with CSS and HTML, which worked pretty well for a long period of time. And, there's still a market for people that work in WordPress, for instance, and they don't need to know a ton of JavaScript. They don't build huge apps that require bundlers, and they don't use CSS and JS. Kaelan: And the question is, what is the frontend developer? Is it this or that? Whereas the term going, is it splitting into two, or is it just moving into something different? And, both of these articles basically claim that it's splitting in two. They different the terminology, of course, because everyone seems to. Kaelan: But Chris Coyier, in The Great Divide basically puts it that you have on one side an army of developers whose interests, responsibilities, and quote, and skillsets are heavily revolving around JavaScript. I think both of the articles put way too much focus on JavaScript. It's really the whole engineering shebang. And on the other side, you have people who focus on interaction, patterns, accessibility, design, HTML, and CSS. Brian: When you say the whole engineering shebang, I'm going to need more detail. What do you mean by that? Kaelan: Yeah, basically I wouldn't put too much emphasis on JavaScript itself. These engineers work with JavaScript now, but that could change in the future. What I'm really talking about here is the skillset that these people have. They come from an engineering background, they focus a lot on performance, complexity and that's a good thing. And, it works very well because the amount of tasks that they have increases all the time. Front-end focused application development, complexity is increasing, so having those kinds of engineering skillset is very important. Kaelan: What's less important for these people is to be extremely knowledgeable in CSS and HTML, especially since they're not crafting it themselves. They're using material design, or some other bootstrap, or something. Or, they work at companies who provide this for them, but the question is who builds those UI component libraries? The way that I think about it is you have core frontend people, and then you have product frontend people. And, I guess that's different than what both of these blog posts are holding it. Kaelan: The core of people, I guess, would be analogous to the front-of-the-front-end people, right. They make the component libraries, they handle the CSS, if you use CSS. I mean, this doesn't even have to be web technologies. Basically, they are the people that make the common library for the back-of-the-front-end people or, as I would put them, the product in frontend people. And I think that's a better split, because a small company of five people, you're not going to have a dedicated person that only does CSS and HTML. It's just not going to sell to management. Brian: So, if core front-end developers are front of the front end, and what you're calling product developers are kind of the back of the front end, what are they doing? Kaelan: They are turning the designs into parts of the product, essentially. They are doing the business logic, they are doing the routing, the caching, authentication, consuming APIs, or maybe even writing APIs. Essentially, I don't see these as two different roles. It's the same role, it's just in a different place. I see them as one job in two different places. Brian: Okay, so then by that logic, there is no great divide. If they're just one job, why are there two different functions? Kaelan: I don't think there's a great divide, and that we're splitting into two different professions. I think we're just evolving as a profession, and then you have a large group of people whose job is what the old definition was. And, they're understandably having trouble, because they don't have an engineering background and then suddenly that's a requirement. And I can empathize with that, because as a frontend developer, I know that there's like tons and tons of things you need to know. And it's daunting, but I don't see a way around it, you know? Brian: Yeah, that's true. Okay, so we've established, at least in Kaelan terminology, and I think you probably kind of agree at least a little bit. You were saying that there's two parts of the same job, and both Chris and Brad are saying, "Well, these are kind of different functions." But, I don't really see a big enough difference there, that feels like semantics. I think where maybe you might break a little bit is, is JavaScript a requirement to be a frontend developer? Is that something you'd need to know backwards and forwards? Kaelan: I think thinking like a programmer is a requirement for being a frontend developer. Today, that means learning JavaScript in some capacity. If you're just starting out and you don't know JavaScript, you're limiting yourself to a very small subset of the profession. But if you know all three, you have an excellent base to learn the rest. Kaelan: But, saying that you are not a JavaScript developer and that you should not learn JavaScript, just seems like you're sticking your head in the sand and you don't want to change with the times. But then again, some people aren't arguing that. Some people are just saying that they don't want to know a bundlers, they don't want to know React, but they're fine making a button do things when you click on it. Brian: What could be more fun? Kaelan: Right. Brian: I think what I'm struggling with is, okay, so JavaScript has been around for a long time. Kaelan: The stone ages. Brian: Stone ages, so how is it changing with the times just to learn JavaScript has an essential function of web development? How is that new? What am I missing? Kaelan: Well, it used to be that the role of JavaScript was pretty limited, and you could learn it relatively quickly because all you did was, okay, if you click on a button then send a request to this API end point. But, now we're building an entire humongous, gigantic apps, which you can argue as a good thing or a bad thing, but it's still a thing. So, even if you know a little bit of JavaScript, is that really enough? It's enough for some things, it's enough to get a WordPress template working. Is that enough? I guess, yeah for certain things. But, would I say that's the extent of the profession? No. It's alright to not know everything. Brian: Well, I don't know. It sounds like it's symptomatic of a bigger... If it's not a problem, it's certainly a trend and that most front-end developers feel like it's so hard to stay current and to keep up with everything. And, so when you ask the question, okay, I know X, I know Y, I know Z, is that enough? Is that enough? Is that enough? There's always this, you're chasing that dragon. Like, when can I go, "All right."? No one in any profession is supposed to stop learning, but it just feels like there's so much pressure on frontend developers to constantly... I mean, you're looking at me right now like, "Yes, that's why I never sleep." Kaelan: Yep, you know my secret now. That's true, there is no stopping ever in engineering, in general. There's no stopping. It changes too fast, and to some extent, that's a good thing. You should not be required to know everything, but you should be willing to learn all that is necessary to do your job, I think. That's how engineers approach it. Like, you can know Java, right, and that's the only language you know. And, then you get a job at a place and they don't use Java, and then you're expected to learn C#, and that's okay. Kaelan: But, I do think people used to say that, though. They used to say, "Oh, I'm just a Java developer." But, somewhere along the line and recently, I guess, it became expected that you should be become more flexible. And that, that was a bad thing that you're just limiting yourself to being just a Java developer, but I'm not a back-end developer, so- Brian: I mean, that is how you started, though, is not thinking like a programmer, is everything boils down to that. And, then what you learn on top of that depends on the job that you have, or the task you're looking to accomplish. Kaelan: Maybe this entire controversy it just boils down to the fact that you've have a bunch of people who don't have a programmers mindset, because they don't come from that base of experience. And, then they're unfamiliar with the expectations of that. And, related controversy to all of this is whether or not a full-stack developer is a thing at all. Because, are we hypocritical for saying that, "Well, frontend already split from back end 10 years ago or so." So, is it natural to say that frontend is good split? Brian: I don't know, is it? Kaelan: No, I would say. Brian: Well, my question is, okay so, I mean, you just happen to be the only kind of dedicated frontend person at LogRocket. But if we had a team of, I don't know, 10 frontend developers, I imagine that some portion will be working on either the front of the front end or the core, and some would be working on the back of the back end or the product side. I mean, it just seems like a distribution of labor would be natural. Kaelan: Yeah, it would be but I wouldn't want anyone to focus on that. Like- Brian: Forever. Kaelan: Forever, yeah. I've worked with tons of, quote-unquote, full-stack developers where the difference in skill between them and the front-end developer. When the back-end focused full-stack developer works on a frontend thing, it's just gigantic. Usually, the front-end developer can do it faster and better. Not saying that true full-stack developers do not exist, they're just extremely rare, because to balance your time perfectly is almost impossible between the frontend and the backend. [crosstalk 00:11:09]- Brian: Not me. Kaelan: Not you? Brian: No, my time is always perfectly balanced. Kaelan: You can do anything? Brian: Thank you, you're right. Kaelan: Like how it should be. Brian: For sure. I mean, yeah I don't think it's any secret that you kind of don't think that full-stack developers exist and if they do, they're pretty rare. It feels like the idea or the term full-stack developers coined, I don't know, it feels almost- Kaelan: Recent. Brian: For sure, recent, but either ego or economics, right. Like, "I can do everything or I want one developer to do everything." I don't really know which one's true, but that's how it feels. Kaelan: I think you're not the real politic here to use the term that should be used more. Essentially, you have the interests of two different parties and joining to create a new term. You have developers who want to market themselves and be competitive, and then you have companies that want to hire just one person instead of two people. But, I don't think the same existed in the nature of whether frontend is dividing. I think that controversy is coming mostly from front-end developers themselves. Brian: Okay, let's make things a little bit more, I don't know, tangible, right. Like, let's talk about how it works at LogRocket, anyway, because that might be helpful. Kaelan: Yeah, at LogRocket I am the only frontend focused developer, but all the rest of the developers are not termed full stack. They're just engineers. People have specialties and we understand that, but we also understand that if something in the frontend needs to get done, then it would be better for the frontend engineer to do greatly complicated things like overhauling the router. But, like all engineers should be empowered to get product features done, but that does not mean that we don't use the right tool for the job. At LogRocket you are an application engineer. You are an engineer. Technically, that's the official terms, but we don't really use them. Brian: Okay, so what happens when you need help? Because, how many engineers are we up to now? 20 to 25? I can't remember. Kaelan: What day is it? Brian: I know. Kaelan: That's a good question, and that's one of the reasons why we're hiring another frontend developer. Side note, if you are a front-end developer and you like a job, please apply at LogRocket. I need company. Brian: He does. Kaelan: Mostly, I just talk to myself, you know? Brian: Well, and me. Now- Kaelan: Yeah, same thing. Brian: Okay, so there's that solution, right. It's just add more frontend developers, and in the meantime, find some engineers that can kind of pitch in. Which it feels pretty typical, right, especially for a company our size. Kaelan: Yeah, but because I'm the only frontend developer, I essentially do the roles of the back of the front end and the front end of the back end to use this blog post's terminology. And, that's not necessarily a bad thing. At companies that I've worked for in the past, larger companies, they've had dedicated, quote-unquote, front-end-as-a-service teams. The frontend people, they also do tooling to, they handle Webpack. Kaelan: It's a different way to split the job of a front-end developer but it's not between the front and the back end of the front end. I don't like those terms, but it's spinning along like things that need to be centralized, and things that don't need to be centralized. The UI library is important part of that, because it's centralized. You don't want every team to make their own UI library, so you don't want every team to have their own front-of-the-front-end developer. Kaelan: You don't want every team to have their own Webpack build, you just want one Webpack build. And, you don't want all the other engineers to be bothered by it, just like you don't want people who mostly work in GraphQL land having to build a new button component or something when they do a product feature. It slows everyone down. Brian: What are the management implications? Because, okay so you have a director of engineering for a smaller teams, and they oversee everything. But, if you have all of these different types of frontend developers, do you have a director of front of the front end? How far does it go? Kaelan: This varies a lot across companies. Usually, the core front end is like, I just used that term because front end as a service is only using a couple of places. To me, it's the core of front ends, but it's usually put under the product team because by its nature that has to work with the product design teams. So, there's a leader of this team. Brian: But, that person usually isn't an engineer. Kaelan: Right, well, that's another conversation entirely. Brian: I know, I know. But, I've seen engineers who roll up into product managers and product directors. And I mean, that doesn't sound fun. Kaelan: To each his own, I guess. To a lot of engineers, no. But some people like that kind of challenge, I guess. I do think the best managers are engineers. When it comes to managing engineers, engineers are better at managing engineers. I think that's pretty much true for almost every profession. People who know what their underlings are doing, and how to do their job are better at managing, I think. Brian: Yeah, I mean, I'll take your word for it. I don't know how engineers like to be managed, but since you are one, I'll take your word for it. Kaelan: I would definitely say that's a trend too. At least the idea that the best managers are engineers. Maybe that's just the hacker news bubble talking. Brian: And what a bubble it is, and I'm not going to go on this tangent. That's a whole other episode. It was like, when you're actively writing code and then you basically stop, and become a full-time interviewer or traffic director. I mean, I feel the same way in content, right. Sometimes I feel like all I do is have opinions and subtle disputes, which makes me a lawyer, you know? Kaelan: It does. Brian: It's a- Kaelan: Content lawyer. Brian: I kind of like that. Kaelan: Content judge. Brian: Right, I'm sure that. Kaelan: Content magistrate. Brian: Magistrate is not quite as fancy. Anyway, I think we're probably losing people. Kaelan: To sum up my argument, I guess, I do think we need to be more clear when making job postings what the responsibilities are. But, I don't like the idea of my profession splitting in two, because I do both parts and that's fine. But, I also sympathize with people being overloaded with having trouble learning all the different parts of modern frontend development. But, I also don't really see any way around it. Kaelan: I mean, improving education, maybe. It does seem like everything's way too convoluted. And, I think we're trending in a positive direction in that side, but at the same time, siloing yourself and limiting your skillset to something that might not be required in the future is just a bad idea. Brian: But, how can you tell what will be required in the future? Kaelan: Focus on the results, essentially. You are not a CSS and HTML developer, you are an application developer, whatever that entails. Just like the Java developer no longer calls himself a Java developer, because suddenly they're asked to do something that's not Java related. Brian: I mean, it's certainly a better way to brand yourself, right. Like, I'm not just this one kind of, let's call it narrow, whether it is or it isn't, right. Let's just say it's narrow. Instead, I'm an application developer or I'm a programmer, and then someone can ask, "Well, what kind of programming? What type of programming?" And then you can kind of, you know. But, all of that is when you're looking for work or maybe introducing yourself at a conference. It's rare, I think, that at your job you'd have to be like, "I'm an application developer." That's cool, what are you going to do this week? This- Kaelan: Maybe this could be solved by just having better agreed upon terms for the different subspecialties in front of development. Although, I'm kind of worried though that if we make an entire new profession that all they do is accessibility, you're just going to get everyone else not to care about accessibility because, hey, that's not my job. If anything, the more back-end and frontend engineers should be focusing more on the frontend side. But, maybe that's just me. Brian: Sounds to me like there should be an annual summit where the representatives get together, and- Kaelan: A frontend congress. Brian: Frontend congress is even better than anything else we've come up with. Although, I honestly probably wouldn't work all that well. Kaelan: Hosted by LogRocket, of course. Brian: Yeah, hosted by LogRocket, sponsored by LogRocket. Please apply, work with Kaelan. Okay, so let's talk about two things, and then we can wrap this episode up. The first thing I want to talk about is how Google is talking about this. And, then maybe once we finish that and basically your thoughts on how Google has organized it, or at least thinks about it. Maybe you can give some career advice, right. Like if you were either just getting started or looking to change, given the great divide which we will assume is real, how would you start? So, Google first. Kaelan: Sure, so Google apparently, and this might be out of date, but from what I can gather, they do have two different titles. They have UX engineers, which from what I gather are the more frontend heavy. The engineers that work closely with design. And, then they have front-end software engineers that work more closely with product to create application logic and the more heavy parts. Kaelan: But, from what I can gather in comments and such, it seems that this split is not always actively enforced in Google. So, I really wonder this is out of date information or if they've changed it. It certainly seems like people have had a difference in quotes of how much they're getting paid. So, obviously people are going to want to choose the profession that pays more, especially since they're so similar. Basically, it seems like Google sees this problem, but they, too, are having trouble clearly defining it. Brian: Well, first of all, not everyone obviously is going to go for the job that pays the most. Some people might go for the thing that they like the most. You of all people should know that. Kaelan: True, but from my experience, the difference can be quite big. And, that's another point of contention, especially. Brian: Help me out, which one's which? Which one do you get paid more doing, usually? Kaelan: People underestimate the frontend, so it's usually the more front-endee positions that are underpaid, relatively. But again, that's the entire reason why this profession has inflated, it's becoming more necessary. The role of the frontend is increasing, so pay has gotten better, and has gotten better by recognizing the increased complexity. So, if you're looking to carve out a niche that lacks that complexity, then suddenly people want to pay you less, unfortunately. Brian: What could learn something that's never going to change, but then becomes obsolete, but kind of rare, right. Like say that you work at a defense contractor and you know, I won't name the languages specifically because I don't want to offend anyone. But, if you're one of like a hundred people who still works with Cobalt, you still get paid pretty well. Kaelan: Cobalt is a great example. That's true, I just don't think that's going to happen for HTML and CSS. It's not going to ever be so unused that people are going to pay you a ton. What's going to happen, though, is that it's just going to be not as important as it used to be, essentially. Kaelan: Not everyone even works with HTML anymore. Like react developers, you could argue that we should be caring more about Symantec, HTML and all that. Especially accessibility reasons, but it's like HTML plus, you're using angular, you're using tons of stuff on top of it, right. It's the same with CSS and JS, is CSS just enough anymore? Is HTML just enough anymore? Arguably, no. But, that doesn't mean that it's worthless. Brian: No, but longevity is, I've always wondered about that, right. Like, okay so let's look at CSS and JS for a second. In three or five years, how important is that going to be? Kaelan: Actually, some people think that JavaScript is going to be replaced first with WebAssembly. Brian: Okay, maybe I picked the wrong one because, again, I'm not an engineer. But, the idea was something will be replaced with, again X, Y, or Z. I don't know that we really answered anything, and I think that was kind of the point. Kaelan: Yeah, maybe. This is a conversation. Brian: I know, but we had the same kind of conversation that the internet had. I don't know that there are real clear answers. I mean, there's... What would you do? Like if you were just starting, if you go back to the beginning of your career and you read both of these articles and you've just kind of read the tea leaves. Would you just be like, "Okay, I'm going to think like a programmer and then read everything I could possibly read."? Kaelan: Well, in my example, I originally sought out web development to build games when I was a teenager. So, I approach it as a problem that needed solving, and then from that, I researched how to solve that problem which led me to programming. Web was easier than other ways of making games, so that's what originally led me to web development. But, I didn't set out to do design, for instance. Like I said earlier, there's two different ways of approaching it. From the design angle and from the engineering angle. But, I think eventually we meet in the center. Brian: Yeah, but none of that is really advice. Kaelan: True. For advice, I would say there are problems that need solving, so you need to be able to solve them. You need to be able to teach yourself to solve them, but you do not need to be able to solve all of them immediately. In the path to becoming a front end-developer, I honestly think breadth is better than depth. Dabble in everything, but don't think that you need to learn the entirety of CSS. I don't know the entirety of CSS, and I've been doing this for, Jesus, 12 years. If you think that, then you've been told incorrect information. I've certainly seen people that do think that. Brian: I actually have seen more and more, though, that maybe not in written form, but I have seen more than one... Oh, we'll call them DevRel person. Although, I was talking to somebody yesterday and I learned developer experience engineer. Which I thought was an amazing variation on developer advocate, developer evangelist. I don't know. Kaelan: Are those the people that work with Webpack and developer tooling stuff? Brian: No, I think it's a synonym for this- Kaelan: Oh, that's weird. Brian: And we're definitely off course here, but I believe the point there is to signify that this person is an engineer and should be treated accordingly, whatever that is. Either within the organization or externally, I don't know, but that's a whole separate conversation. Maybe we can have that some day. Kaelan: Yeah, it's ind of similar. I mean, you have a group of people who don't want to call themselves engineers. But some of them do, even more confusing. And, some people think there's a difference between developer and engineer, and I'm like, "Why?" Brian: Oh God, fortunately I've never been sucked into that conversation, but I don't think I'd have an opinion at all. The other thing that we really... And we're definitely not going to solve it here, but you mentioned a few minutes ago design. But, you almost never hear that in this conversation right, you know? Kaelan: Right, so earlier we mentioned what LogRocket does and that's probably is important. At LogRocket I was the, basically, the de facto designer along with the CEO, Matt. But, most of the mock-ups I did, I've heard a frontend engineer, though, not really designer. Of course, now we have a designer and we're trying to hire a second designer. So, if you're a designer and listening to this podcast, please apply. Kaelan: So still to this day, we approach design as like a collaborative effort, just like we approach product as a collaborative effort. Maybe that's because both co-founders were engineers, and so we're a very engineering led company. So, all the engineers have an input with product and all the engineers have an input with design. So, we kind of expect them to have an ounce of products thinking. And we expect the front-end engineers, even though I'm the only one, to have some sort of a design sense. Kaelan: So in that respect, that's like the front of the front end. I think of it Like I was wearing the design hat for a while, but that's still a separate job. And, now I'm wearing the front-end developer hat, and as part of that front-end developer hat, it means interfacing with the design. But, I still work with GraphQL and I still work with everything else, and that's okay. Brian: Let's say that we had a bigger design function than we do, right. Like we have one designer, and we'll have more, and someday we'll have a bigger function. But where does either product, I guess in this case, it's app, it's product design for LogRocket, where does that sit for front of the front end? The frontiest- Kaelan: Frontiest of the front end. Brian: Frontiest of the front end. Kaelan: Yeah, as soon as you add more designers, then suddenly you need maybe a full-time person whose job it is to interface the design. Right now, there is no full-time person who is doing interfacing with the design, but there is an expectation that in the future we will need it. That's kind of what I mentioned earlier where there's different flavors of front end, but they are not different careers. They're not different jobs, they're just different uses of the same job. Brian: Different problems, which is- Kaelan: Different problems that need to be solved, yeah. But, they're all front end. Brian: Yeah, I mean at no time is Docker involved. Kaelan: Yeah, I'm pretty useless when it comes to Docker. Brian: You and me, both, brother. Okay, I think that's a great place to end, actually, because I don't think we're going to get to the bottom of this. And, I don't know if there is a bottom. Kaelan: The conversation will continue, it seems. Brian: Yes, the conversation will continue, maybe we'll come back and do it again. I don't know. It's always fun to navel gaze with Kaelan on Rocket Surgery. Kaelan: My hot takes. Brian: Hot takes, deep thoughts. See you next time. Kaelan: Adios. Brian: Hey, it's Brian again. So, it turns out that running a podcast is maybe harder than we thought, and so I kind of want to hear from you. I'm genuinely interested in your feedback. We have to think about new topics, new guests, we have to find them. And don't get me wrong, we can do it, but it's a lot easier if everyone else who's listening helps. Brian: So, if you'd like to suggest the topic or volunteer to be on PodRocket, we'd like to hear from you. So, you can do that by going to PodRocket.logrocket.com/contact-us. The hyphen is next to the Delete key, if you're curious. If all of that is too long, you can just email me directly, Brian@logrocket.com. That'd be great. Also, if you're feeling magnanimous, be sure to like and subscribe to PodRocket. Thank you.