[00:00:23] 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 good back-end options for front-end developers with Lee Robinson, Head of Developer Relations at Vercel.

[00:00:38] LR: They can get into a tricky point when they’re trying to move past, let’s say, the next level of growth or scale in their business.

[00:00:47] SY: If you have a question for Lee after listening, don’t miss The Ask Me Anything Session he’s hosting on the CodeNewbie Community Forum this Tuesday, June 1st. Just head to community.codenewbie.org, and you’ll find his thread on our homepage and he’ll answer you directly in the comments. That’s community.codenewbie.org. In this episode, Lee talks about the major differences between front-end and back-end development, how the back-end has developed over time and the array of back-end options that can be easier and work well for those who mostly code in front-end development after this.

[MUSIC BREAK]

[AD]

[00:01:33] 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 at cockroachlabs.com/codenewbie.

[00:02:03] Career Karma helps CodeNewbies 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 Career 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/codenewbie.

[AD ENDS]

[00:02:32] SY: Thank you so much for being here.

[00:02:33] LR: Thank you for having me.

[00:02:34] SY: So Lee, you currently help educate people through courses and you do some consulting on how they might want to build their apps. But what was coding and development for you? Is that something you always thought you were going to do? Tell me about your journey a little bit.

[00:02:48] LR: my journey is a little nontraditional. I definitely didn’t think I was always going to do coding. When I was about to go to college or university, I was between doing graphic design, coding, or doing music actually. So kind of all over the board and I chose to do coding because I thought it would have the best opportunities to get a job. As I got into college, university, I realized that it was a lot harder than I thought it was going to be. And a lot of other people were much more experienced with coding than myself. So it was a battle to figure out what I enjoyed, what worked for me, and I eventually stuck through it and made it to where I’m at today.

[00:03:29] SY: So you were interested in coding, graphic design, music. Did you ever have any ideas or thoughts on maybe putting all those things together?

[00:03:38] LR: So at the time, I would say not really, but it is interesting to see the intersection between creative fields. The more into my career I get, the more I realize the opportunities where these different paths intersect for some really, really interesting things. Like when I look at the intersection of design and development now, it’s amazing. There’s so much you can do here. Some of the most talented designers and engineers I know are so proficient in both of those areas. So without really realizing it, I was actually getting kind of a good crash course for what was to come later in my career.

[00:04:16] SY: Yeah, it’s incredible, the intersection now between code and so many other things that maybe don’t feel naturally connected. It’s really incredible to see the work that people do. So you have this interest in graphic design, and I’m wondering, did that lead you to kind of gravitate towards front end? Are those related to you in any way?

[00:04:35] LR: Absolutely. Yeah, 100%. I used to design T-shirts for a local company.

[00:04:41] SY: Oh, wow!

[00:04:41] LR: And that got me into like vector-based graphic design and learned Illustrator and Sketch and those tools and now eventually Figma, but it definitely made me appreciate pixel perfect designs and trying to get things looking exactly how you want it, which led me towards really getting more involved in the front end at the start of my career and having an affection for a really great design.

[00:05:07] SY: So tell us about how you got your first full-time software engineering job. How’d you get it? What kinds of things did you work on?

[00:05:14] LR: Yeah. So I had a few internships before I landed my first full-time job that kind of helped set me up to get that job. So the first internship I had, I was doing kind of automated testing and I kind of quickly ruled out that I didn’t really want to do a QA role or something more focused on just writing tests, which led me into my second internship, where I was using C++ and working on the front end and the back end, but in the aerospace industry, I didn’t totally love it. So then my third internship, which eventually turned into my full-time job, was at a SaaS company. It was in FinTech and I started to realize, “Oh, I really like this web development thing. I really like creating websites, whether it’s front end or back end and making these amazing dynamic experiences for folks.” And that internship then led to turning into a full-time job when I graduated.

[00:06:10] SY: And what did you do at that full-time job?

[00:06:12] LR: I had a couple of different roles at that company, mostly working on helping with the reliability of our application and it was on the internal tooling side, making sure that when customers ran into issues, there was adequate tooling to monitor report and alert, not only our internal teams, but our external teams on those issues. So I worked with primarily Python, Flask, GCP on the back end and then React, JavaScript on the front end.

[00:06:43] SY: So tell us about what you do now. What is it like to be at Vercel and what’s your job?

[00:06:48] LR: It was an interesting journey because I kind of realized I’m not super fond of being put in a solely product-based engineering role. And I have been doing that for a lot of my career where you get a task and you complete the task, you check it off your list and you’re done. And what I started to realize over the course of now being a developer for 10 years was that I really thrive in environments where I have autonomy and I work cross-functionally across multiple different areas. And without really even realizing it, I figured out that this was really aligned with what I was looking for at a developer relations. So when I joined Vercel in September of 2020, I joined primarily to help out with not only DevRel, but also our pre-sales team and specifically as a solutions architect. So I was helping educate people on what is Next.js, how does that work, how does Vercel work, and what is the value that it provides for you as a customer or you as an organization.

[00:07:54] SY: So you wrote a really great blog post in 2020 called, “Which Back End Should I Use As A Front-End Developer?” And I want to dig into that a little bit. But before we dig into which back end you should use, let’s kind of make sure we’re all on the same page and establish the difference between front-end and back-end development. How would you describe those two?

[00:08:14] LR: So as we’ve kind of progressed into 2021 and into the future, the lines between front end and back end, we have a really nice separation now. Maybe in the past there was more monolithic applications where that logic was kind of, let’s say, merged together. Now we have this clear separation where your back end, you can kind of consider as an API that you might pull off a shelf. So something like Stripe for payments or Twilio, if you want to send a text message, or Auth0, if you need to do authentication. These APIs you can interact with or other “business logic” that you can have for storing information. That’s decoupled as one part of your application. And then you have your front end, which you can think of the HTML, CSS, JavaScript, allowing you to not only create a beautiful experience for people to use, but a functional accessible experience that works across all of your users, devices, and browsers.

[00:09:14] SY: And quickly let us know what a database and what an API are.

[00:09:18] LR: There are a bunch of different types of databases. The most common that most folks have used is probably a SQL database. And that is just the language that you’re using to query that data. You might also hear this referred to as a relational database. On the inverse of this, you have a NoSQL database, which is something more aligned to JSON, JavaScript Object Notation. I can’t remember exactly what it stands for, but you have a JSON onto that. And I would argue it’s a little more beginner friendly for those who aren’t as well-versed in the back end. Traditionally, I would say folks who want to do relational databases have content that is highly related to another. So if you have a list of users and then those users have a list of blog posts, there’s multiple authors for each blog post, et cetera, something like that. We can dive into that more later. So that’s kind of this database, regardless of how you want to store your data or whatever format it is, is a place that allows you to centralize and aggregate all the information related to your application.

[00:10:24] SY: So we establish what front end and back end are. Now I want to establish what it means to be a front-end and back-end developer. When it comes to the day-to-day, how does being a front-end developer look different from being a back-end developer?

[00:10:41] LR: Yeah. I think drawing these lines is really important at a certain scale of company because the larger your application gets and the larger your team grows too, it’s great to have these focus groups of people, these focus job titles, to allow people to understand their scope of influence and their understanding of work. So when I think of a back-end engineer, this is somebody who is not as focused on the presentational aspect of the application. Their interface into exposing the application to the world might be through an API. So all of the work that they do might end up just being some REST API that someone can consume and hit a URL and get back a list of users, for example. So they might be working on authentication or some sort of queuing system or sending emails, all sorts of things like that. And on the front end, on the inverse, the front end is tricky because as the front end has grown, especially as we’ve had more immersive and complex of applications, we kind of have a disjointed front end. We have what some people refer to as like your run in dev ops engineers and then your HTML, CSS style engineers on the front end. There’s a million different job titles that people use for these, but basically the moral of the story is that the infrastructure and the tooling around building modern front-end applications is actually pretty difficult and pretty complicated. And at a large enough scale, you have people that are dedicated just to doing that portion of the piece essentially.

[00:12:25] SY: I’m curious to hear your thoughts on how it has developed over time, because from where I sit and I’ve never been like an exclusively front-end developer, but from where I sit, it feels like it’s just gotten more complicated over the years. I feel like the frameworks, one, there are frameworks, two, the frameworks are getting bigger and more complicated and it feels like we’re doing much more on the front end than we ever used to do. And it just feels like the job has just become just more complex. Is that right? Is that something that you’ve seen as well?

[00:12:57] LR: It’s interesting because, I agree, it does feel like certain aspects have got more complex, but then it’s almost paradoxical where at the same time, a lot of things have gotten a lot easier for people to get started or get spun up with things. And I think the important thing to talk about here is if you take it back to maybe the origins of building these applications. When the web started, you had just mostly web, what we’ll call websites. You’re serving up some HTML documents that really aren’t that complex. The client side or the interactive part of the application is pretty minimal. You’re mostly just rendering some text on the web. And as the web matured and the usage of JavaScript to make interactive applications grew and grew and grew, we started to realize that we can create these really immersive and interactive experiences on the web, allowing us to unlock all sorts of different use cases that just kind of weren’t possible in the past. Now when doing that, it also adds more complexity into the type of applications that you’re building such to where now some people refer to this as you have websites and you have web applications and both have somewhat different needs and wants. So when I think about some of that complexity that has entered over the years, if you think about something like the JavaScript ecosystem, a lot of people feel that it’s very complex and some of that complexity comes from the fact of people want to use the latest and greatest JavaScript features that are built into newer proposals for the language, but it also needs to be compatible with all these different browsers. So we have these tool chains that allow you to compile and transpile code to make it work for IE11 older versions of Chrome or Firefox, and still write code with the new hotness, essentially.

[00:14:55] SY: So if you’re a front-end developer and you want to build your own app, do you need to understand the back end that, well, is there kind of a minimal amount of back end I can get away with? Or what are your thoughts on that?

[00:15:08] LR: Yeah. One of the great things about, and this ties into the paradox I talked about where it’s easier for some folks to get started is because as the web has matured and we’ve seen this rise in this API economy, it’s easier than ever to hold these services off the shelf that allow you to do different segments of your application, whether that’s payments or authentication or sending emails or whatever it might be. And this ties in really, really well with no-code or low-code solutions that allow somebody to really only focus on the front end, and maybe they’re just using a Google Sheet and it’s populating some e-commerce store and they don’t have to really think about the back end. But the reality is when they’re plugging in that Stripe API, that’s their back end to go do that payment processing.

[00:15:58] SY: So when is the first question you should ask yourself when you’re thinking about back end and when back end comes into play?

[00:16:05] LR: It’s highly contextual on the type of application you’re wanting to build and also I would say the size of the organization. So whether you’re doing something on your own as a learning experience or you’re trying to build your own SaaS application or your own project, or if you’re inside of a company and you’re trying to pick a solution for the company, more often than not, I think what we’re seeing is people on the smaller side, whether they are building their own business, they’re starting their own ecommerce store, people on this scale are more and more opting for solutions that give them as little back end as possible and allow them to stitch together different services. The key thing here is you want to make sure that, ideally, you’re not picking things that don’t mesh well together, such that if you do reach a point where you want to, let’s say, object from these services and scale up to a larger amount because your business has found lots of success, you’ve thought through that escape hatch in the future. I think this is something that’s helpful to think about ahead of time. But then as we think maybe just a little bit larger, you’re already working at a company somewhere and you’re trying to figure out your next steps or you’re just learning to code, almost every large company is going to have their own back end, I mean, 98% of them are going to have their own back-end setups with some complex logic, a database somewhere, some API somewhere, and learning those fundamentals. Like you can’t go wrong learning about SQL because it’s been around for 40, 50 years at this point or something, and it’s still used all over the world. So those types of investments and learning that technology will really pay dividends into the future.

[MUSIC BREAK]

[AD]

[00:18:10] Career Karma helps CodeNewbies 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 Career 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/codenewbie.

[AD ENDS]

[00:18:39] SY: One of the things that we need to think about as front-end engineers is the issue of what to do with data. We talked about APIs a bunch already, and there’s the idea of using someone else’s database, right? Because when you have an API, you’re usually pinging another app and accessing their information held on their servers and their databases so you don’t only have to worry about that. But then there are other situations where you kind of need to hold your own data and you do need to have a database. How do you decide, how do you determine when you need to hold your own data and when you can kind of rely on someone else’s?

[00:19:15] LR: Yeah, a good example of this, I think, is when you’re dealing with some of the low-code tools without owning your own data or at least having a centralized data location. It can be difficult to maintain or sync, for example, users or profiles across four or five, six different services. So when you own that portion of the data, your central user database, and you have processes that sync that data to your Stripe customers or to your authenticated accounts in off zero or similar, owning that portion of the stack is really important because then when you decide it’s time to export and roll my own payments or roll my own authentication or whatever you necessarily want to do, you still have ownership over the centralized portion of your users.

[00:20:10] SY: So you mentioned low-code tools. What are some of those low-code tools?

[00:20:13] LR: Oh, man. There’s so many great ones and it seems like a new one pops up every day. I think in broadly speaking categories, you have things like spreadsheets/pseudo databases. So Airtable, Notions of the world where you can actually do a surprising amount of things with those as the back end, essentially to your front end somewhere, going a step further towards like the completely managed solutions. So the Squarespace, Wix, Webflows of the world, those are still allowing you to kind of dip into the code, throw in an embed script or throw in a Google Analytics script somewhere and stitch together services if you need to, but you’re still getting this really nice UI allowing you to kind of drag and drop elements and move things around. And then there’s also amazing tools like Zapier, which allow you to essentially expose an API endpoint and yet build these amazing complex workflows that can send emails and save to databases and put in a Google Sheet and have a really complex form and integrate with all these different services. Those tools are incredible and incredibly powerful for people who are trying to stitch together things in the back end.

[00:21:36] SY: That’s a great point. I remember, I don’t remember when it was, maybe years ago when I first saw an example of Google Sheets being used as a back end and it just blew my mind. It totally blew my mind. And it made a lot of sense, right? Because Google Sheets is a spreadsheet, spreadsheet is a whole data. You can do calculations and you can manipulate it. You can do a bunch of stuff with that data. So it logically made a lot of sense, but it just never occurred to me that a basic, plain, old spreadsheet could be an entire database. When you hear a database, it sounds like this huge, big, complex thing on server. It just seems so large and sheet seems so accessible and putting those two together, it blew my mind.

[00:22:17] LR: Yeah. I think it reminds me a lot of when I first discovered key value based data storage because it’s so simple. It’s like, “Oh, the key is username. The value is Lee.” That’s it. That’s the only mental model I have to think about, which really simplifies that down a lot.

[00:22:36] SY: So I’m wondering, what is the reputation of these low code solutions? I feel like some back-end developers might kind of, I don’t know, talk badly about them, kind of look down on them. It was like not real code and that sort of thing. But on the other hand, as you said, we want to do more things, more complex things, and these tools make it easier. So I’m wondering, is that a thing? Are low-code tools kind of looked down on? Or are they worth all the ease and accessibility they bring?

[00:23:05] LR: I think fear or uncertainty or doubt that comes from people talking about low-code or no-code solutions comes from a place of a repeating fear of, “Is this going to automate me out of my job? Did this tool just come in and replace everything I was going to do?” I think I’ve even seen this from front-end engineers who they see something like Webflow and they’re like, “Am I not going to need to design these parties and all HTML, CSS layouts in the future? Is an AI going to spit this out for me?” And I think the answer there is no. I think there’s always going to be a demand for this going further. There’s always going to need to be people who actually build those tools. The thing that I try to drive home is that it’s not that we’re excluding folks, it’s that we’re including a whole new subset or a whole new group of people who wouldn’t necessarily have the opportunity to maybe dive into these types of solutions or build out their own ecommerce site. But now that we’ve given them just one more layer of abstraction, now they’re able to stitch together their Google Sheets and put their products in there and launch their e-commerce site. So lowering those layers of abstraction and helping more people just get online in general and get their code in general is amazing to me. I think we should encourage it.

[00:24:31] SY: So what are the downsides of low-code tools? They can’t be all good. Right? What are some things that maybe we should watch out for?

[00:24:37] LR: Yeah. And that’s a great point. With every solution comes a trade-off. And I think it comes from not thinking about the end goal at the start. And obviously, hindsight is 2020, but having a little foresight into how you want to grow and how you want to handle your applications architecture, if you did end up being successful, I’ve seen a few instances where folks might stitch together eight to ten different low-code solutions without ever really owning their data and then they can get into a tricky point when they’re trying to move past, let’s say, the next level of growth or scale in their business. It’s funny too because then the common argument back against that is like, “Well, they should be happy that they made it to that next level of scale and now they can invest in re-architecturing again.” But it’s not feasible to have to completely ditch the infrastructure that you’ve chosen or the tooling that you’ve chosen every time you reach a new level of scale. And that’s one of the things that I talked to people a lot about with Next.js, which we can talk more about later, but it’s a great obstruction in a framework. It allows you to start small, just on a personal hobby project, but still include a lot of the things that you would need in case your application gets really large and is used by millions of users. And it adds things that hopefully prevent you from having to escape the bounds of that solution.

[00:26:12] SY: Yeah. Let’s dig into Next.js. What is that?

[00:26:14] LR: So Next.js is a framework that was created by the team at Vercel where I work. And it is a framework for using React. React is a composable component-based solution for building user interfaces on the front end. And Next.js is an all in one solution that allows you to build React applications that are not only very performant, but also can scale up to millions and millions of users. And it does this by really building on years of experience for the people on the Next.js team who have built web applications at the largest scale, they built React applications at the largest scale, and try to include all of these best practices on how to build these performant, accessible experiences across the web and give them to people, whether they’re building their blog with 10 users or they’re building the next big e-commerce site.

[00:27:11] SY: So next, what I’d love to do is something a little different. I don’t think we’ve done this on the show, but I want to just go through a bunch of terms and see if you can kind of define them for us. These are all terms that are related, that are relevant to back-end development that might be new for front-end developers as they kind of navigate that side of the equation, that side of the world. So I’m just going to go through a bunch of them. And if you don’t mind, just tell us a really beginner-friendly definition of what they are. Is that okay?

[00:27:37] LR: Absolutely.

[00:27:38] SY: So we mentioned SQL at the very beginning earlier in this interview. Tell us about SQL and then the opposite, I guess, of that, which is NoSQL.

[00:27:48] LR: So the most beginner-friendly way I can summarize SQL is a structured, predictable way for you to access your data and connect the dots between different pieces of data. In contrast with NoSQL, NoSQL is designed for ideally a certain structure of data and millions and millions and millions of different entries of that type of data. So less about connecting the dots between different pieces of data and more about very fast retrieval and storage of a single type of data. And it’s based around JSON objects.

[00:28:34] SY: And what about REST?

[00:28:36] LR: Yeah. So REST is a type of API that you can build, and it would typically be found with different HTTP methods. So GET, HOST, PUT, DELETE are a few common ones. So if you go to your browser and you type in for Vercel.com, you’re doing a GET request to fetch more information about that browser. If I submit a form, I’m going to do a post request to send some information over to the server. A PUT would be updating some information and then obviously deleting some. And REST is this interface that allows you to structure your API, such that you expose data in a predictable manner in contrast to a GraphQL API, which is a related way of fetching data from the server. The main difference with GraphQL, being that it allows you to connect different services into one graph, allowing you to more easily query across a bunch of different locations in one request.

[00:29:42] SY: Next, let’s do authentication and authorization, which sound very similar, but are actually different. Tell us about those two.

[00:29:49] LR: Yeah. So authentication, a great example would just be I am trying to log into some application and I need to verify that this user is logged in. Authorization is verifying specific properties about that user. So I’m authorizing that the user, Lee, has access to fetch information about this project, for example.

[00:30:16] SY: Yeah. The way I think about it is one is about identity and the other is about permission. That’s kind of the way I differentiate the two. That’s fair.

[00:30:23] LR: Yeah.

[00:30:25] SY: Hosted and self-hosted.

[00:30:27] LR: So hosted, a great example is I don’t want to manage the infrastructure of my application. And instead, I would like to offload some of that responsibility to a third party. And when you’re saying self-hosted, you’re saying I’m going to manage scale and own the infrastructure that runs my application.

[00:30:50] SY: Very nice. Serverless. That’s when I feel like we hear all the time and feel like this nebulous word that might feel very confusing, if you need a server and then all of a sudden you’re serverless. So tell me about that. What does that word mean?

[00:31:03] LR: It is a confusing word. So serverless is not a lack of servers, but instead someone else managing those servers for you where you don’t need to worry about provisioning a server or scaling a server or dealing with that infrastructure. Similar parallels to the hosted versus self-hosted, serverless allows you to write your code and then pay for your usage rather than having a server that’s running all the time. You can just pay for what you use.

[00:31:38] SY: And then last one up, data modeling. What is that about?

[00:31:41] LR: Yeah. So you have different types of data in your application, and each object has to be modeled in some way where you define the properties of that data and how you want to represent each one of those properties. So if I have a person as an object in my database or user, I want to set up the data models that express the contract between my database and my APIs and how we want to store, fetch in and modify that information.

[00:32:22] SY: Coming up next, Lee talks about questions we should ask ourselves when we’re looking at all of the different back-end services after this.

[MUSIC BREAK]

[AD]

[00:32:43] Hey CodeNewbies! Did you know that all apps need databases? Take a look at your phone and see what apps you have. Instagram, DoorDash, 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 database. The experts at Cockroach Labs, the company behind the leading database solution, CockroachDB, 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 cockroachlabs.com/codenewbie to take your coding skills to the next level and get one step closer to becoming a software developer.

[AD ENDS]

[00:33:36] SY: So what are some of the major back-end services out there that people might want to consider when they think about going into back end and kind of plugging out together? We talked about some low-code tools. I’m wondering what are some of the other big ones that we might want to take a look at.

[00:33:51] LR: So if you are interested in self hosting your own back-end infrastructure, you can’t go wrong doing either SQL or PostgreS, PostgreSQL, which is another variation. On any of the major cloud providers, whether that’s Amazon, AWS, or Google Cloud, or even to some of the other providers like a DigitalOcean, Heroku is another one, that allow you to easily kind of set up these databases, give you a URL and credentials for you to connect to, and then you’re kind of off to the races to actually query and store information in your database. That’s probably the lowest level of abstraction, just having access to some database somewhere. Taking it up another level might be a completely managed PostgreS or SQL server that also includes APIs or auto-generated code on top. So an example of this might be something like Supabase or Hasura where they give you another level of abstraction to make it easier to store and update that data. And then there’s also NoSQL type tools like Firebase and related that allow you to have the different data structure. And a lot of these have tools around real-time built-in as well.

[00:35:11] SY: What are some questions we should ask ourselves when we’re kind of looking at the different options and trying to pick what’s best for us?

[00:35:18] LR: Yeah. First and foremost, what I always tell folks is with the back end, I think it’s really important to use what you know. It’s easy to get distracted by the new hotness or what the Apple, Google, Netflix, Facebooks of the world are using, but you have to recognize at the scale that they’re using, they’re solving really unique engineering problems. And more often than not, the best tool for the job, for what you’re trying to build is a tool that you or your team has lots of experience with. Now you can obviously venture out and learn new tools for specific use cases or specific problems you’re trying to solve. But if you’re proficient at SQL, it’s something that works well, it’s established, and it’s been proven to solve many solutions.

[00:36:08] SY: So one of the things that I think we’re always tempted to do as engineers, whether you’re new or you’re senior, is this kind of need to build it yourself. I feel like you want to prove that you can do it. You know what I mean? And it feels like real engineering if you build your own stuff. And so I’m wondering, how much do you want to build in this type of situation? When do you want to maybe roll your own and when do you want to rely on an existing service or application to do the heavy lifting for you?

[00:36:35] LR: Yeah. I think at some point in every front-end or back-end engineers’ journey in coding, they fight this battle between, “Should I build this myself? Should I buy a solution? Should I use something that’s more self-hosted or off the shelf?” And it’s really hard to give advice for this because it’s so contextual based on what you’re trying to build and the problem you’re trying to solve. But I will say that in general, at a smaller scale, I always err on the side of something that is hosted, something that is going to allow me to iterate more quickly and focus on building my product and delivering value to customers. At a larger scale, when dealing with more complex problems, I’m probably opting to more of the self-hosted options as I’m going to run into unique use cases that might require custom code or custom configuration. And it’s nice to have that flexibility.

[00:37:40] SY: So we talked about using different databases like SQL or NoSQL. We talked about low-code solutions. Another thing that we might want to consider, which I guess is kind of a low-code solution, is a CMS, a Content Management System, as a way to create and manage and modify our data. And of course CMS uses its own database to manage it, but you don’t usually have to deal with that database directly. And so I’m wondering, when is that a good option? When might we want to consider a CMS versus using a database more directly?

[00:38:10] LR: Absolutely. So a CMS is a great option when maybe you’re dealing with image storage or other documents storage or you’re trying to work with people other than just developers who are managing this content or editing and updating this content. And even going further, if the content that you’re trying to serve needs to be localized for the specific user’s language or country, if you need to do different variations, experiments, or previews of that content like a blog or are similar, then it’s a great option to use a content management system because it simplifies that workflow and it makes it more accessible for folks.

[00:38:54] SY: So you said earlier that there’s this fear among back-end developers and front-end developers, too, of being automated away. Right? There’s so many no-code tools and low-code tools out there that it’s getting easier and easier for people with no technical skills at all to get started building their app and building their product and you said that you don’t feel like it will be automated away that there will be a job for us, but I’m wondering, do you have any sense of what that job might look like? Once these no-code, low-code tools become even more popular and kind of spread and become more used, I’m wondering what your thoughts are on five years from now, ten years from now. What does it look like to be a front-end developer and what does it look like to be a back-end developer?

[00:39:38] LR: Yeah. It’s interesting because as we automate more of these back-end services into highly specialized APIs that you can purchase or use off the shelf, the differentiator really becomes that front-end experience and it becomes providing not only a great product, but a great product experience. And I think we’re seeing a new wave of really investing into what that experience looks like on the web. So for me in five years, I think that’s overemphasizing on user experience and design driving more of the interactions on the web and making more performance interactive front-end experiences that then consume these APIs or back ends that are more accessible now for people to build because that front-end experience is really going to be the differentiator between you and your competitors.

[00:40:36] SY: I think that’s a great point. It’s almost like there’s this divide between everyday use, maybe I’ve got like a little app idea, doing my thing, maybe it’s a side project versus huge companies with, as you said, very specialized needs, very particular requirements who need more custom software. I have seen a lot of low-code tools positioned themselves as great enterprise products. We’ll see if that ends up being true and if they get really picked up by these big companies. But it seems like for the more complex tools, I feel like there’s just always going to be a place for developers.

[00:41:10] LR: Absolutely. And even in those large organizations too, the breadth of the different projects that they’re building is so vast that there’s still a place for something like a Zapier when they have a one-off workflow somewhere, and there’s still a place for saving to a Google Sheet or saving to an Airtable database somewhere. It might not run their dot-com, but there’s still so many opportunities for all the different areas and the scope of that organization to use some of these tools.

[00:41:40] SY: One thing I’m wondering also is how you see the roles in the future. Again, given that low-code tools are probably going to continue to exist and probably continue to grow and given that we have more of the back end moving to the front end and the front-end role being more complex, I feel like there was a time, not that long ago where everyone was kind of a full stack developer and now things are becoming a little bit more specialized. You had mentioned, there’s like a DevOps front-end engineer, which I hadn’t heard of before. And I was like, “Whoa!” And so I’m thinking, do you see those roles being further specialized or do you think we’ll maybe go back to a world where people know enough about all the different components to consider themselves full stack engineers?

[00:42:24] LR: I think at a smaller scale, we’ll get back to more full stack because the tools will be more accessible. But then as you get larger and larger, I think the specialization is just continuing to be more niched and more focused. And what I was kind of referring to with like front-end dev ops is getting deep into the weeds of compilers and transpilers and performance optimizations, and the intricacies of making things work cross browser and making something that’s accessible across all the different browser quirks that exist. And those types of things are a different level of complexity than maybe just building out a front-end experience with HTML, CSS, JavaScript that allows you to build the marketing pages of your website, something like that.

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

[00:43:31] LR: Yeah, let’s give it a shot.

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

[00:43:36] LR: I think the worst advice was actually when I began my career and there was a focus I heard from a lot of other people, my peers, around what’s that next step, like how do I get towards a senior engineer or how do I progress in my career. And I got so fixated on this idea of the next step or the next goal and the next check mark. I think once I became a senior engineer, I realized that chasing promotions wasn’t really the goal in this whole process. It was almost a distraction because I was really trying to find the opportunity for me to do great work and excel at that work. Now learning about the process of how you get promoted and how you grow through companies is good. But the key thing to remember is to not get too fixated on a job title or responsibility and instead just try to love what you’re doing.

[00:44:38] SY: Number two, best advice I’ve ever received is?

[00:44:41] LR: I have two for this, one is related to my prior answer, but I don’t know who made this up. Maybe it’s just a common saying, but I really like it. Work to live and not live to work. I like that saying because it helps me stay grounded around work-life balance and making sure that I can still enjoy what I do. But at the end of the day, this job is a means to allow me to live my life. The second one is a quote from the Naval and it is, “Find something that seems like work to others, but it feels like play to you.”

[00:45:16] SY: I love that. That’s great.

[00:45:17] LR: And I love it because if I’m working on something around design or music and I’m like, “Oh, I really enjoy this,” or I’m coding something up, someone else might see that and think, “Oh, wow! They’re working like crazy.” But really I’m just enjoying what I’m doing and I’m just messing around and having fun.

[00:45:33] SY: Number three, my first coding project was about?

[00:45:36] LR: My first project, my first like successful project I guess, I made a clone of the classic arcade game Space Invaders. I made it with Python and it was fun. I used to love gaming all the time. I don’t do it as much anymore, but it bridged those worlds for me and it allowed me to actually see something tangible out of programming, which was fun.

[00:46:00] SY: Number four, one thing I wish I knew when I first started to code is?

[00:46:04] LR: I wish a traditional college or university education taught you more broadly about all the different types of areas of engineering and types of programming, like different languages, tools before just kind of jumping straight into, in my case, C and Java. I definitely prefer the coding bootcamp style here where it allows you to figure out, “Okay, I think web development is the thing I want to do. Let’s just jump right to that.” I didn’t get as much value out of “learning the fundamentals”, I guess.

[00:46:42] SY: Yup. I’ve definitely heard that from quite a few developers who studied CS in school. So I believe that. Well, thank you so much again for joining us, Lee.

[00:46:51] LR: It’s been really fun.

[00:46:59] 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. Thanks for listening. See you next week.