 Hi, welcome. So this is cross-dimensional careers transitioning from front-end to back-end My name is Jen. I work on the Node.js platform team at Netflix And I spent about nine years specializing in front-end before switching to back-end and tooling Hi, and I'm Wes Also on the Node.js platform team at Netflix. I spent four years about learning just to absolutely hate browsers I basically spent the rest of my career learning to hate all the other computers And of course the reason that we mentioned our years in different specializations is because that's what this talk It's about transitioning from front-end to back-end and like kind of actually somewhere in the middle, which we'll talk about But to give you an idea of what we're covering today. We're going to be hitting on four major sections So why we switched? Did we accidentally end up in this new domain or was it a conscious choice and why? How that went for us transitions are really tricky And we're going to talk about what we found going into this how it actually happened and if our expectations met the realities And then what's the same? So what are the commonalities between front-end and back-end? What knowledge in front-end is also going to apply to back-end and then obviously what's different? What does not translate between the two areas that you would need to learn if you want to do the transition? But before we start a disclaimer Your mileage may vary. There is no one true way to transition from one domain to the next So Wes and I are going to be talking about our Individual experiences and we're going to hit on topics and points that we think like translate despite how you get from point A to point B But if you're looking to transition yourself We are actually not providing a roadmap Just an idea of what you might experience along the way and to that point We want to make sure to provide some definitions Because when we say front-end we are specifically talking about web based JavaScript and we are not talking about mobile or native applications And when we talk about back-end we're specifically again going to talk about JavaScript based servers run times Observability things like that We're not going to include things like database data pipelines batch jobs Back-end can mean a lot of different things So we want to make sure we're working with the narrow definition that we can speak to directly from our experience Okay, so with that said Why you might want to make the leap from front-end to back-end? And this is more from my perspective and these aren't going to be true of everyone But I know that when I started in software engineering and I was specializing in front-end I often thought that I needed to learn back-end to be a real engineer So to be clear a front-end engineer is an engineer But at the time that I was like teaching myself JavaScript I heard a lot of negative comments about front-end not being hard enough and That definitely influenced me Now that I've been in the field for longer I really feel like each domain has its easy parts and its hard parts and some engineers just prefer some domains And that's really like it. I don't really assign worth based off of what domain you work in So if this happens to be your motivation, I would really urge you to find a better one Or maybe One of those reasons is that you would like to make more money So there is a pay disparity between front-end and back-end You will be paid more for full stack and back-end roles I've heard from recruiters that the gap here is closing, but it does still exist And this is like a fine reason to switch in my opinion And another really good reason is boredom So you can start out in one domain really enjoying it everything is new and exciting and then years go by and You might notice that the problems that you're solving are actually they're not that new you've seen them before Making a domain switch is a really great way to combat boredom or stagnation in your career It's actually why I switched Though it took me a while to make the actual switch So I started working in software engineering in front-end in 2012 And then I just continued working in front-end for around eight years And in 2020 I started working in open source. I was joining the Apollo client team at Apollo GraphQL So that is not classic front-end. It's a little bit further away from it, but it still was not back-end And then in 2021 I joined the Node.js platform team at Netflix and this is when I officially switched domains I still work with JavaScript, but I do not write front-end code in this role and Looking at this timeline You might think that I decided to switch domains around 2020 maybe 2021 But I actually want to make the switch like way earlier than that So this is a more accurate timeline So about halfway through my career in classic front-end. I started getting like a bit bored And I wanted to learn more about back-end that seemed like a really accessible like domain for me to try out to see how I liked it But you can tell I didn't do that transition for a very long time and there were some very good reasons why Even if the switch is intentional it can take you a while to make the actual switch So one of the reasons is that the path forward is really not clear Even if you want to move in a certain direction Orienting yourself without a map is hard and there is no map for domain switching So you take steps forward you see if that's like the right path or not Maybe you have to go back and start and try again Like so many times I tried different things to switch I tried taking on roles in startups where I thought I could wear many different hats And maybe they'd allow me to do some more back-end and I'd learn back in there I Tried applying for full stack roles But like these didn't work out The startups that I worked for kind of inevitably needed me to stick with front-end They didn't have a lot of people and they need someone to do front-end They didn't want me taking time away from that to learn a new domain And then the full stack roles really ended up being back-end roles with like a little side of front-end And so I just wasn't a good fit for those at all Also front-end moves fast I could barely keep my head above water learning front-end and I worried that if I focused on back-end I would fall behind in front-end. I was not sure that I a hundred percent wanted to make this switch I wanted to try out back-end but in order to do that I would have had to stop the learning I was doing in front-end and I really worried about falling behind So I actually ended up deciding to stay in front-end but move around within that domain Around 2018 2019. I started moving towards front-end architecture. I really liked front-end systems I decided I really liked tooling. I liked working with making front-end systems easier to work with and Around that time. I also started exploring open source so I started learning a lot of the inner workings of react for instance and Other libraries and then in 2020 is when I joined the Apollo client team to actually work in open source Full-time again front-end, but not classic front-end and still JavaScript And of all the ways that I tried to switch into back-end staying in front-end But moving towards tooling is actually what worked for me It gave me a really good perspective. I was able to step away from UI and make sure that I liked that I actually I loved it. I loved not working with UI anymore When I left Apollo, I decided to make a really intentional switch into like tooling and productivity And I thankfully landed on the Node.js platform team at Netflix Where my tooling my work is like tooling and back-end. I really really love it The takeaway I think from like how I did the switch is that You can actually move around in the domain that you're in to decide if that's a good path forward for you And speaking of which now I'll share a little bit of my story, which is all about moving around within both domains front-end and back-end Drop this mic. I don't know if that's loud enough so When I got started it was mostly like freelance WordPress stuff. I was working alone There's not really a definition of front-end and back-end when you're working alone. You just solve the problems, right? It was a good start, but then in 2011. I went and found my first what I would call real job as a developer I was applying with just a portfolio and an art degree. That was pretty much instantly put me in a bucket a front-end engineer So like the job was really just like cutting up Photoshop stuff and HTML CSS email templates that kind of stuff What I learned from that was that I was in this bucket. I didn't know that it existed before And most of the actual like interactive UI stuff was working like these JavaScript widgets and stuff at the time lots of jQuery prototype stuff Was given to people with more traditional software engineering backgrounds, which I didn't have So then around 2013 I took a role at an agency The project's got assigned with a front-end and a back-end engineer I was very lucky that this company hired a ton of great people And so I was working with a lot of great back-end engineers partnering on projects And this is one of my first encounters with the concept of building your network I've made friends with these folks and the other thing that I learned there that is critical is Ask your co-workers and your friends at your job to help you learn. So I just asked them Hey, I'm we're working together help me walk me through what you're doing I also learned From that that I just liked the work So I did the other thing that I think I would recommend to everybody which is ask ask for the work So what I did is I went to the the leadership there and I said hey On the next project. It's kind of small. Maybe I can do both, right? So that was full stack From 2015 to 2018 is where I really solidified my full stack Skill set so I moved to a startup which did give me the opportunity to wear many hats as we were talking here There's quite a bit of different experiences here that we're sharing So for me it did actually give me that opportunity the startup had a pretty standard split between UI and API teams So I started on the UI They were in the process of doing a switch to an Angular app with a go server That served like the initial HTML It was pretty quick when I joined that team that the engineer who was the primary author of the go server left the team I took that role on and basically If you've ever worked on front-end teams you'll often find that those engineers probably are not super comfortable writing go So that turned out to be the case Go templates were pretty foreign to them Honestly, I would say probably pretty ill-suited for a UI team owning the server So what I did is I did the work. No one else wanted to do Any time there was a change that needed to happen in the go server I was the one that my team would come to and ask me to do it So if you're looking to learn these kind of things sometimes you just need to do the work No one else on your team wants to do similar to that you Can also try to do the work that nobody realized that needed to be done or asked you to do So at the same startup we had a local dev server Each team member when they were onboarded we had to build a new dev server. The process was owned by some other folks It was like a chef thing that was all complicated and it would take like a week because it was like a whole nother company So we were getting pretty sick of this. So I said, hey, maybe I can figure that out So I started figuring out how to build the local dev server and onboard new team members. I was now a dev ops engineer Okay So I've gotten us through quite a bit but I want to backtrack and I want to talk about how I built out a lot of this full stack skill set and The key was open source. So I started off back in about 2012 I had tons of little jQuery widgets and stuff like that And I made a whole ton of toy projects just to figure out what I liked doing So my first move into what I would call now productivity engineering was actually a yeoman generator Generated WordPress sites. I built it because I thought that my company might be able to use it So I was gonna hopefully convince them never worked left there But most of these toy projects really were mirroring my work and honestly, they're probably not worth talking about except for to Express being the first one if you're in this room, I hope you've probably heard of that project I got deeply invested and that was a great way for me to learn the HTTP stack JavaScript on the server Being having that experience in open source was really critical to me building out those skill sets And then a very small one on the opposite end called node apt get When I was doing that stuff provisioning the local dev server for the team. I was sick of the chef thing So I tried let's write it in node, right? Of course So I wrote this node apt get thing that turned out to be super fortuitous for me because a team at Netflix was Building IOT devices with node for testing TVs and other streaming devices And doing automation with that So a recruiter found that the team found that they were using that module found me reached out And here we are today. So I will go back a little bit to the main timeline here That team was not a good fit because I was not that low in the stack. It was absolutely you know Pretty low-level back-end engineering and at the time I was more of a full-stack engineer Luckily, there was a team adjacent team that was doing react and no JS I came in thinking I was more of a front-end person because that was my background I quickly got feedback from my team that they actually all thought of me as more of a back-end engineer So that was actually when I realized I was a back-end engineer Even though I didn't really intend it. So just to wrap it up and put a bow on it Then I joined the build team it lined a lot with my tooling and my productivity engineering you know enjoyment and Now I'm on the node just platform team So my wise and I'm following here on after sharing my my story because really honestly I didn't have a why it was just to solve a problem at the time I really wanted to understand the things that were going on in my applications and around the UI bits So I learned it and honestly in the end of the day Front-end got really hard at some point the tools that everybody was choosing all the different changes in front-end the speed of it just It became something. I didn't really care about continuing to learn with the you know the amount of effort that it was involved Okay, so Now that Wes and I are both working in this tooling back-end kind of hybrid space We're gonna talk about how our expectations Compared to the reality So when you move into a new domain you inevitably are going to find that some expectations actually match and some don't So I had the expectation that there would just be a large skill set jump Honestly, the reality was that I took a lot a little step. So for me starting new roles I had at least a partial coverage of the skill set that I needed And the nice thing for me was that I didn't actually have a lot of expectations going in I had written API's I had written some database schemas I had you know done these things just a little bit So I actually had some of that skill when I started the role where it was actually expected of me And I I did a different kind of leap Wes obviously did more small steps I did a bigger jump and so one of my Expectations was that I could learn back in the same way that I learned front-end which was mostly by myself with no mentorship watching materials like front-end masters and attending front-end conferences and There is a lot of material to learn front-end if you're a beginner intermediate advanced. There is tons of material I did not find that true to be like a back-end at all In particular, there are less resources for intermediate and advanced learners It's super easy to find resources for making your first API with node and then what a Lot of the advanced material assumes knowledge or vocabulary that I didn't have Or it's written in languages that I didn't know Also, I would ask people in back-end. How did you learn this and almost always the answer was on the job? So don't get me started on googling googling is kind of useless when you're trying to look up back-end terms that you don't really Understand and so I had a lot of trouble Learning on my own like I had done with front-end. I do want to share though two books that were actually really really useful for me Mastering API architecture this explained a lot of concepts to me that I was unfamiliar with like gateways and the history of them And then distributed systems with no JS This is one of the few resources that are really good for learning about Distributed systems in a language that you might be more familiar with these books were actually really helpful But other than this I really had to rely on my co-workers and learning on the job And so I expected back-end to mean writing API endpoints But the reality is back-end can mean a lot of things just like front-end can tech stacks are deep. They're varied For me that felt really freeing As I was making the transition, you know, the UI space was consolidating more on the react webpack tooling That felt pretty restricting making the switch fully more into the back-end realm really felt a lot more open-ended and Sometimes you don't know what to expect I knew from being a front-end engineer that back-end engineers were giving me APIs But I really did not have a good understanding of what their day-to-day looked like So I asked like a back-end engineer that I'm friends with like what are you doing like literally? What are you doing today? And he said I'm trying to make that line look like that other line So he made a change he deployed it and now he was watching the metrics to see if it matched What it was supposed to be doing and Yeah, this is true. I did this recently for my job. I had to roll out a change I had to watch the metrics and I had to make the line look like the other line So this one actually really did match I also had this expectation that a lot of my front-end skills weren't going to translate to back-end and The truth is actually that you have a lot more skills that will transfer than you think And that's because honestly software is software. It doesn't really matter what the code does what language it's in what the environment is Some things are pretty much always going to be the same. You're not going to be starting from square one on this So let's talk about some things that will help Nailing your fundamentals. This is key things like design principles security best practices general craftsperson ship things So one of the things I really loved was Audia's money's design principles in JS Seeing those patterns in a language that I was familiar with really helped me understand them And since I was not traditionally trained I hadn't been exposed to things like getting a four principles earlier in my career For security best practices. It's a little bit harder. I think Keeping up with things as they're ongoing can be tough I think my strongest recommendation for folks interested in this area is get in a little bit over your head Especially when it's non-critical issues You'll learn from that and that is learning on the job But I think if you try to do it in and work with team members Who have a little bit more experience in that area? You can you can pick up things as you go and lastly the crafts part is really just things like attention to detail Air handling formatting of your code consistency and how you design your applications stuff like that those spending time learning Those skills will definitely pay off so JavaScript obviously We have a wonderful node.js Server runtime learning JavaScript and anything about it is a critical technology bridge for you Across this gap Anything you learn about ECMAScript VMs they run in v8 spider monkey stuff that all will pay off Both on the front end and the back end and this is true Even if you're writing type script type script is JavaScript when it actually runs So and actually even that even broader Even if you're doing something that doesn't run on a JS virtual machine You'll find that there are parallels across these things with concepts that you can apply They're usually just like one step lower in the stack than you So these are things that you can understand and and transfer as you transfer the skill sets Also, I think this is just one of the most important skills. You can focus on that works Whether you're working in software or just talking about your general life Time spent working on how you communicate Especially communicate your technical work how you bring your friends colleagues bosses customers along on those journeys Especially when you're working on projects and I and I think how you write and speak will always be time well spent So let's talk a little bit more about some technical stuff All craft people need a good set of tools So what are those tools that are going to be transferable from your front end of back end experience get it's one of these Things we all rely on every day, but most of us barely scratch the surface As far as managing your source files go I promise you it can do anything you ask of it There's actually so much that you could probably spend the next year learning these things and you'll probably never use them So I would recommend taking it slow learn things as you need them when you find an issue Google around and your mileage may vary but Google around for get Help on on those kind of things because you will almost always find something And and similarly to how I mentioned learn take it slow learning get there are so many tools out there Less really is more don't feel the need to know them all and especially don't feel the need to use them all That's bad Start small work your way out The two things you're obviously going to need which you also needed on the front end were an editor in a terminal There might be extensions and things that you find that will help you as you as you jump across From the front end, but but actually most of them will also probably be the same And lastly here take notes and write scripts, especially when you're joining larger teams or companies that have really complicated things Learning deeply about each tool is is probably not going to be time well spent for you pick and choose And then what I always recommend is take notes If you hit a complicated task take your notes on it if you hit it again add to your notes if you hit a third time script it And so you're probably saying how is this a tool? bash Absolutely Learn some bash it's a tool you almost always need to get that last mile Even if you don't actually have to write it front end or back end There is always a load bearing bash script in your stack Everything I've ever worked on has one You also can transfer a lot of your knowledge about debugging seems like it might not be true between front end and back end But it absolutely is So up into the right. This is usually a bad thing Not always, but it usually is bad thing so things like memory leaks and CPU issues look pretty similar actually in the browser or the server and Debugging memory links in particular is a skill that I learned in the browser that has been Really valuable on the server You're also going to still use console.log a lot like you're going to log a lot of things So like log as much as you want on all your things when you hit a new issue like add logs debug them So on and so forth it's going to be really helpful for you Wes has a particular point about logging that If you want to know more about ask him during the QA it has to do with log levels and what he thinks you should Actually be using for a logger in everything Not console.log and there are good reasons for it, but ask him about it later And then lastly for debugging the best skill that I have ever picked up is Breaking down large problems into small ones. This will be true no matter your domain You will have a large problem and you will have to break it down You will think horses not zebras and you will work your way from one step and slowly Break down the problem. So this absolutely transfers if you're learning debugging in one thing You can take all of these skills and apply it to a new domain like no matter the domain Okay What connects the server in the client obviously HTTP bridge has two sides understanding from one side is absolutely going to help you On the other things like header status codes paths all that translates and understanding the user experience is a skill You absolutely want to keep sharp Knowing what your consumers of your APIs are gonna like and hate is something that you can bring from the front end into the back end Okay, and then talking about you know, we talked about what actually would transfer. What is different what actually won't transfer Performance performance is very different on front end and back end when I was working in front end I was very concerned with things like time to paint The size of my assets images bundle size and then optimising for a device It could be running in a browser on a laptop or it could be running in a mobile device. Those were my concerns and One of the largest differences you need to think about here is because of concurrency and parallelism In the browser It's likely that a bug might impact just the one user on the server That same type of bug could cause the server to crash and take out all the parallel requests that are happening at that time Additionally scaling is not really a thing at least not the way we think about it on the server side The more concurrent users your applications have the more your server side needs to scale So things like systems architecture distributed systems horizontal versus vertical vertical scaling auto scaling policies stuff like that all Becomes really important to understand And lastly here latency so similar to Time to paint having a response and with the having a responsive UI in the browser service Server side latency is is really a critical measurement here. It actually oftentimes ties directly into the UI responsiveness So it's likely you already have a bit of a familiarity with the concept But the details of how latency can affect system performance are quite different on the back end specifically because of the parallelism right two things going on at once some extra latency and one might back up the whole system and Also very very different is observability This is much more of a thing on the back end than the front end So the front end you get visual like clues if there's a bug you can screenshot it You can video it when customers report a UI bug in my experience of all the years I was in front end. They were mostly reproducible Without observability though on the back end you are flying blind And that's why we have metrics and yes the front end can collect metrics But those are usually product metrics and there's not as many of them for back end You're looking at system metrics and you're looking at a lot of them There's also tracing I have never worked with this concept in front end It wasn't a thing But because back end you're dealing with a system calling another system This is very helpful for you to trace what's going on And you're also going to have to learn all of the vocabulary for observability a span in front end and a span in Back end are not the same thing And then also on the observability side logging which you might be like wait But you just talked about console log. So this is the same thing, right? No So in the front end when you're logging You're using one user session and you know where the logs are coming from Logging on the back end is actually aggregate logging from multiple servers at one time And you're looking through those logs to try and figure out what happened But it's not as easy to look through them and say oh this happened sequentially and on one server The other thing is while you can log everything that you want In the back end and also with metrics and tracing there are performance costs to doing it So the observability itself could be a performance issue And so you have to learn about why that is on that side of things and Then you're like, oh, this is a lot to learn. It's cool You can forget some things which is my favorite part. So when you make this switch, there's like Spray space that you can like free up in your brain You don't have to think about these things anymore like UI frameworks. You can just forget about them. I Worked with react for a really long time. I loved working with it I kind of remember certain things about it, but I've mostly forgotten And if that appeals to you back end might be for you You don't have to worry about browser compatibility anymore So you can free up your brain on that you no longer have to check out what you were making in multiple different browsers or go check The documentation to see who implemented what feature and how or if it's different So that also frees up some space and then CSS Which I'm sure many of you will be happy to hear. I actually liked working with CSS, but I have forgotten so much of it So yeah, you can free up some space when you make this you don't have to like keep all these things in your head all at once So we covered a lot We're gonna hang out up here for Q&A if anybody wants to come up and talk with us We recognize this transition can be pretty hard and it can take a really long time So we wanted to leave you with a note from one of my daughter's books Vampirina ballerina and that is it doesn't matter if you take one giant leap or many tiny steps as long as you're Moving toward your goal So, thank you Come come talk to us if you have questions Otherwise you're free to go