[00:00:05] SY: Welcome to the CodeNewbie Podcast where we talk to people on their coding journey in hopes of helping you on yours. I’m your host, Saron, and today, we’re talking about Auth with Sam Julien, Developer Advocate Engineer at Auth0.

[00:00:18] SJ: I just remember feeling like, “What have I done?” Like, I have no idea what I’m doing. I was like so overwhelmed by that.

[00:00:27] SY: Sam talks about how he got out of a rut and into development with a little help from his friends, what Auth is and what things you really need to know about it after this.

[MUSIC BREAK]

[AD]

[00:00:43] SY: TwilioQuest is a desktop roleplaying game for Mac, Windows, and Linux to teach you real world developer skills. Take up the tool of software development, become an operator, save the cloud. Download and play TwilioQuest for free at twilio.com/quest.

[00:01:00] Heroku is a platform that enables developers to build, run, and operate applications entirely in the cloud. It streamlines development, allowing you to focus on your code, not your infrastructure. Also, you’re not locked into the service. So why not start building your apps today with Heroku?

[00:01:18] Cloudinary is an end-to-end image and video management solution with a powerful API that lets developers upload, store, create, optimize, and deliver your media with ease. They have a generous free plan as well as advanced plans with enterprise configurations. So check out Cloudinary today at cloudinary.com.

[00:01:38] MongoDB is an intuitive, flexible document database that lets you get to building and MongoDB Atlas is the best way to use MongoDB. It’s a cloud global database service that gives you all of the developer productivity of MongoDB, plus the added simplicity of a fully managed database service. You can get started free with MongoDB Atlas at mongodb.com/atlas.

[AD END]

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

[00:02:09] SJ: Thank you so much for having me. It’s an honor.

[00:02:12] SY: How did your coding journey begin?

[00:02:15] SJ: A long, long time ago and technically my coding journey began when I was in about, I think seventh grade, a cousin of mine got me into learning very, very basic HTML. But at the time, there was no YouTube or Codecademy or CodeNewbie or anything like that in the ’90s. So I assumed that you needed to have a computer science degree to do it as a job. So eventually I kind of gave up on it and did other things.

[00:02:44] SY: Wait. Why not just get a computer science degree?

[00:02:46] SJ: Yeah. I didn’t know how long we wanted to delve into this part. Yeah. So I went to college and I started out as a computer science major.

[00:02:58] SY: Okay.

[00:02:59] SJ: But in planning out my classes, it turned out that the first four semesters of the computer science degree were all basically just math. There was no coding at all really. So I was sitting in Calc III, I think it was.

[00:03:15] SY: That’s a lot of calc.

[00:03:15] SJ: And I was looking at my classes for the next semester and it was like Differential Equations and Physics II. And I was like, “This is not what I want to do. I just want to learn how to write code.” And I had tried a lot of other ways of learning, mostly through library books and viewing source and copying and pasting and things like that. I really just had no interest in doing all that math and science. And so I switched to liberal arts and religion and philosophy and history and stuff like that. And I just sort of assumed at that point that that was the end of that. And I wasn’t going to be able to do anything more than just sort of like hobbyist coding with like HTML and CSS.

[00:03:58] SY: But you found your way back to coding somehow. How did that happen?

[00:04:01] SJ: After I graduated, I actually went into finance for several years. I did sales and operations and customer service and stuff like that in finance. Somewhere along the way, about my fifth year in that career, I was getting really burnt out and just unhappy for a variety of reasons. At the brokerage that I was working at, one of their kind of claims to fame was that they wrote their own trading software. So we had this department of software developers. And so I was just chatting with them and how I was sort of discontent with where I was at. And they were like, “Well, why don’t you become a developer?” And I was like, “That ship has sailed. I don’t have a computer science degree.” The most senior developer was like, “Oh, I never even went to college. There’s no reason you can’t become a developer.” And so they started this group of developers at my old job in Florida just started like sending me resources and giving me advice. And I started learning like JavaScript for real and started learning C#. And at that point, there was things like Treehouse and Codecademy and things like that. And so I had this whole world of online resources to learn and then also had these people who were kind of coaching me and giving me advice and things like that.

[00:05:25] SY: That has to be the dream. I mean, just working alongside people who you aspire to be like and then they kind of mentor you all the way through until you learn how to code. I mean, that is just wonderful. What do you think motivated them? How did you get yourself in a situation where you have these people sending you homework and guiding you along?

[00:05:44] SJ: To be honest, I don’t really know why they were so helpful. I mean, one guy in particular that I’m still really close friends with put a lot of time into me. He would do code reviews for me and give me ideas for projects to work on and things like that. And that like really made a difference in my life and that really impacted my philosophy now of like when I’m trying to teach people to code and what kind of projects I take on I have this constant desire to pay that forward because it’s very rare to have that opportunity. And so it’s a huge motivator to me is to try to pay forward that gift that he gave me.

[00:06:27] SY: So how did you end up getting your first job?

[00:06:29] SJ: At the brokerage that I was working for, I had wanted to be able to switch from my finance job to the software department. And so I was trying to make that happen and eventually that just got squashed by the CEO basically. And so at that point, I started looking for other jobs and I had been in the same city in Florida for a long time and I had had a lot of things happen in my personal life that I sort of tired of being there. So I immediately started just applying for other jobs elsewhere. And I was looking in primarily New York and Portland, and I asked a lot of people well for a lot of advice on how to do that. I started building up a very tiny GitHub account and try to include on my resume anything that Josh and the other guys at the brokerage had taught me. And eventually, I found that the best path for me was the contract to hire route because it was kind of a low risk for a junior developer job to hire someone on a temporary contract basis, which was really scary for me at first.

[00:07:41] SY: That’s risky.

[00:07:42] SJ: Yeah, it was risky. And so I actually ended up moving to Portland, Oregon on the basis of a 90-day contract.

[00:07:52] SY: Wow!

[00:07:53] SJ: Basically just like picked up and…

[00:07:54] SY: That’s a big move.

[00:07:55] SJ: Yeah. Yeah. So I moved across the country and started working at a financial company in their software department as a junior developer, squashing very archaic bugs.

[00:08:08] SY: That’s a really big step. I’m wondering what gave you the confidence to take that leap? Did you have a backup plan, a safety net of some sort?

[00:08:17] SJ: Kind of, not really. Basically the way that the recruiter had described it was, “If this one doesn’t pan out, another one will come along.” And so, I mean, the way I calculated it was like, “Okay, if I get out here and this crashes and burns, I’ll just have to go back.” I mean, I basically had a couple months’ worth of savings, which at the time was not very much because I was sort of in the middle of a bunch of different things. And so the way I figured was like, “Well, if it crashes and burns, worst case, I just moved back to Florida then try something else.” But I didn’t have any sort of like backup or safety net other than just sort of taking a very calculated risk. You know?

[00:09:04] SY: Yeah. What was the hardest part of making that move?

[00:09:09] SJ: Going from Central Florida to Portland, Oregon is almost like going to a different country.

[00:09:16] SY: Really?

[00:09:17] SJ: It’s culturally very, very different. It’s also geographically just like as far away as you can possibly get.

[00:09:22] SY: Yeah.

[00:09:23] SJ: So there was a lot of cultural adjustment. I didn’t have any close friends or family in Portland. I had a couple of acquaintances or people that I knew that I had gone to college with or high school with or something, but I didn’t really have like a great support system at first. And so the first year was difficult of just like trying to be really purposeful about making friends and not just staying at home and wasting away alone and going out. So that first year, I’d say the hardest part was just like moving to a new place where you don’t really know a lot of people and you start making friendships and building relationships. Now a lot of those people who are acquaintances back then are good friends now and I’ve lived with some of them over the years.

[00:10:09] SY: Oh, wow!

[00:10:10] SJ: So it all worked out, but it was a big leap to go from somewhere I was like very established and had all of my doctors and dentists and like medical stuff lined up and friends and family and all that stuff and just like go as far away as possible to Portland.

[00:10:26] SY: Yeah. So when you got that first job, how did it compare to what you thought it would be like to be a developer?

[00:10:34] SJ: Oh, man. It was so much more boring than I thought to be perfectly honest. The thing that they don’t teach you, and this is why I like shows like this and other resources where like you interview developers are so valuable because when you’re going through JavaScript tutorials online or whatever, you’re probably using the latest and greatest framework and you’re doing all this like cool new technology. Then you go in and you get your first job and it’s using tech from 10 years ago and nobody really teaches you how to read legacy code and how to deal with the fact that, I’ll just never forget, like my first couple of days there, they assigned me this bug that was somewhere in the stack. They basically just gave me the bug of the behavior that was happening and were like, “Okay, fix this.” And I just remember feeling like such a deer in the headlights because it was SQL Server and C# and jQuery and stuff like that and a lot of SQL dependency because it was a financial company. And it turned out the bug was in like a stored procedure in the database. And I just remember feeling like, “What have I done? I have no idea what I’m doing.” I was like so overwhelmed by that.

[00:12:02] SY: Yeah. Yeah.

[00:12:03] SJ: So it was a lot more researching and mulling things over and asking for a lot of help, just letting myself, like we threw a lot of legacy code and stuff, and I didn’t really feel like I had any way to prepare for that really because what tutorial out there is like, “Here’s how to deal with the random SQL bug that you’re going to get assigned on your first day.” You know?

[00:12:27] SY: Yeah. So you still stuck with coding. You’re still a developer now. So what made you stick with it?

[00:12:35] SJ: One of the things that was driving me crazy about finance among a lot of things was I felt like the longer I was in it, the more random facts and regulations I was supposed to memorize and the less creative it got. I was just really burnt out with not really solving problems and coming up with creative ideas. And that’s what really drew me to programming was that it was just like a constant learning process and creative process. So once I got over the initial deer in the headlights of my first job of having no idea what I was doing and all of that, then I started to have some fun with, “Oh, learning to debug and solving problems,” and that just really kept me going. The longer I stayed at that first job, I was able to bring in some new technologies. So I think I just slowly got addicted to that process of solving problems and creating new things and I just wanted to keep doing it.

[MUSIC BREAK]

[AD]

[00:13:57] SY: Explore the Mysteries of the Pythonic Temple, the OSS ElePHPant, and The Flame of Open Source all while learning the tools of software development with TwilioQuest. Become an operator, save the cloud. Download and play TwilioQuest for free at twilio.com/quest.

[00:14:15] No one wants to manage databases if they can avoid it. That’s why MongoDB made a MongoDB Atlas, a global cloud database service that runs on AWS, GCP, and Azure. You can deploy a fully managed MongoDB database in minutes with just a few clicks or API calls. MongoDB Atlas automates deployment, updates, scaling, and more so that you can focus on your application instead of taking care of your database. You can get started free at mongodb.com/atlas. If you’re already managing a MongoDB deployment, Atlas has a live migration service, so you can migrate it easily and with minimal downtime then get back to what matters. Stop managing your database and start using MongoDB Atlas.

[AD END]

[00:15:06] SY: So today we are getting into Auth. What is Auth?

[00:15:10] SJ: Auth can generally be broken down into two vocabulary words. There’s a lot of jargon around Auth and it can be really confusing for pretty much everyone, but especially for beginners, but not exclusively beginners. So we generally talk about authentication and authorization. And so authentication means proving that you are who you say you are, and that’s generally when you think of like logging in to an application, you’re getting authenticated basically where I am Sam and I can prove it with this set of credentials. And then authorization is basically, do you have the permission to access whatever you’re trying to access, WHETHER it’s data in a database or an API or something like that? It generally breaks down into those two sections.

[00:16:03] SY: So Auth feels like a very high level concept. Is it tied to a particular language or framework? Are there best practices around it? How do we make it more tangible and actionable?

[00:16:17] SJ: You’ll come across Auth in any language or any stack? Basically, any time you need a user that has a profile or a set of permissions or persisted preferences or anything like that, you’re going to run into needing to add Auth to your application. So that could be in JavaScript. It could be in Ruby. It could really be in anything. So there are a number of standards and best practices that have evolved over the years. Most folks don’t need to get too deep into like the specifics of them. The two most common that you’re going to hear a lot, there’s something called OAuth, which is one set of standards, and then there’s another related standard called OIDC or OpenID Connect. And so you’ll hear those a lot and we don’t need to like get too deep into what those are. But a lot of the login systems that you’re going to be implementing these days or using a lot are going to end up using those standards.

[00:17:25] SY: I feel like another way that I’ve encountered Auth is to authenticate using a system that already has my account, right? So I can authenticate via GitHub, via Twitter, via Google, which I don’t know, to me kind of feel, and I don’t mean this in a bad way, but it kind of feels like it’s the developer’s way of kind of skipping that whole thing and just kind of allocating that to a third party. Is that still the same authentication that we’re talking about?

[00:17:49] SJ: Yeah, that’s actually an example of OpenID Connect. So back in the day, which in developer land is something like, I don’t know, five or six years ago, but it used to be, let’s say that your calendar wanted access to your LinkedIn contacts for some reason, and it used to be that your calendar app would say, “Hey, give me your login and password for LinkedIn and I’ll go on your behalf and go get that data and bring it in,” which is like terribly insecure, right? Because you’re just giving your password away to this software and who knows what’s going to happen? You don’t know that they’ve stored it in a secure way. You don’t know what they’re going to do with it. That’s why OpenID Connect came along so that we’d be able to instead use this kind of single sign on process where we can log in, like sort of as a pass through using these artifacts called tokens behind the scenes.

[00:18:49] SY: Tell me about tokens. What are those about?

[00:18:51] SJ: Yeah. So a token is basically, it’s just sort of a generic name for an artifact, basically just like a thing, and a token needs basically to be able to store some useful information and it needs to be able to be like proven where it came from so that we know that this server created this token and we can prove it by verifying it. And then when we verify it and decode it, then we get some useful information from it, like claims or permissions or something like that.

[00:19:25] SY: How is it related to a password? Because a lot of aspects of that sound like it’s a password.

[00:19:30] SJ: A password is what you would use when you’re actually logging in. And then once you’re authenticated, then you would basically in exchange for that, you get this token back that then basically is the proof for you to be able to be authorized to go get whatever resources you’re getting. So the password is prior to the token basically.

[00:19:55] SY: Okay. So is it basically like I’m logging in, I use my password, I hit the server or the database that has all my password information, it matches, and so in response, I get this thing called a token? And then now if I want to go do other things on the web app that I just logged into, that token says, “Look, I’m still who I say I am and I’m authorized to do these activities.”

[00:20:22] SJ: Yeah. Yeah, pretty much. So like a common scenario would be that, like, let’s say you’ve got a front end and it’s written in React or Angular or Vue or something like that and then you’ve got an API and that API has some sort of information that you’ve got protected that you wouldn’t want the general public to have. And so when you log in through your front end, then your front end goes out and calls something called an authorization server, which then is basically there to help you deal with these permissions issues by issuing these tokens. So the authorization server checks your credentials and says like, “Okay, you’re good to go,” and sends you this token back. And then that token in the front end gets sent back to the API that has the data that you’re trying to do. And so the front end says, “Hey, API, here’s the token.” The API says, “Okay, let me make sure that it’s valid. It came from the right place.” And then I can use that information to determine what this user has access to.

[00:21:29] SY: Okay. You mentioned that Auth has to do with authentication, but it also has to do with authorization. So are there tools, frameworks? Is there an OpenID type of equivalent for authorizing?

[00:21:41] SJ: So that’s kind of what we were talking about. So for example, OAuth is actually protocol for authorization. I know that’s confusing and I don’t want to delve too deep into like the standards and best practices, because the reason that something like Auth0 or anything like that exists, which is basically what we’d say is like identity as a service is that there’s so much to keep track of with this stuff that you can dig yourself into a hole really quickly by trying to do everything yourself. So rather than digging too deep into the standards, I would say sort of at a high level, what you want to know is sort of like the authentication side being when you send in your credentials and then the authorization side verifying those claims through the token, and then using that to drive whatever permissions you need for that protected data in the database.

[00:22:40] SY: So I’m trying to think about what the implementation of that would look like. So if I’m a developer, I’m building a web app and I know I need some login and I might have some different permissions, levels, I might have like an admin level. I might have a user level. So if I wanted to have someone log in as an admin, what are the steps of that? I assume we don’t want to like roll our own Auth system because it sounds like that’d be really complicated. What would I do? What’s the first step in that?

[00:23:10] SJ: When it comes to permissions or roles, there’s kind of two different approaches. So you’re going to end up using some sort of service, like whether it’s Auth0 or some other service to handle your checking the credentials and sending the tokens and controlling that kind of thing. So you can either keep your permissions in that service basically. You can define your roles there or another way of doing it is you have them in a database somewhere tied to the user ID. So you have like a permission’s table or series of tables. So then when you get the user ID back in the token, your API can then go get whatever permissions or claims are associated with that user ID. To sum up, you could either have the claims in the token itself that’ll come from the service or you can go grab them from a database yourself. Whether you implement it in either direction, kind of depends on what the use case is.

[00:24:13] SY: So when I’m picking, let’s say I want to have a service that does this for me, that handles this for me, how would I decide which service to use? What features am I comparing?

[00:24:24] SJ: So most of the big contenders out there are pretty similar in their level of security. They’re in the business of being secure. So they’re looking to adhere to standards like OAuth and OpenID Connect and things like that. So you’ll find that pretty much across the board. I mean, if you don’t find that, then you shouldn’t use it. But most of the time, the type of features that you’re looking for are going to be things like whether you can integrate with different social providers like Facebook or GitHub or Twitch or whatever else that you want be able to have your users be able to log in with, you might want to look for being able to use something like multifactor authentication, whether it’s like a text message or like a code generation kind of thing. You’ll also probably want to check out what options they have for your database of users, whether you can store it with them or integrate with what you already have. There’s a lot of different options out there. So I’d say most of the features revolve around sort of like integrations with other providers and sort of like ease of use, like developer experience, things like that. A lot of the services have a lot of similar features, but they vary widely and like how easy they are to implement or maybe the number of features kind of right out of the gate that don’t require you to upgrade to other things.

[00:25:55] SY: So it sounds like I can offload a lot of the work of thinking about Auth to the services. So I’m wondering what about Auth do I actually need to know?

[00:26:07] SJ: So what you’d end up implementing in your application would be probably integrating some sort of SDK, which is just a library that the service will have for your particular language. So what you would end up doing is you’d build out like maybe the login button or something like that, and kind of the mechanics of what do I do when I come back from the server, come back with that token, how do I process that. And usually the service will have helpers for you to do that. it’ll have methods for like handling that. And then from there, a lot of it is sort of UI driven. So on the front end, you’ll be controlling the UI based on whether somebody is logged in or not logged in. And then on the backend, you’ll be doing things like checking for permissions or whether they have the credentials to do something so everything before and after the login is what you’ll be responsible for and then everything in the actual middle is what you would kind of offload or outsource to a service to do that for you.

[00:27:18] SY: Is it important maybe on a high level to know how that service works and how it operates?

[00:27:25] SJ: I think it’s a great idea for developers, if they’re interested to learn how to kind of do basic authentication and authorization themselves, there’s a lot of tutorials out there on building it out yourself and that’s a really educational process because that’ll teach you how these things work because basically what happens is if you start to build it yourself using different libraries that are out there to create the token and decode it and do it yourself, like you can do all of that. Where the services come in is that they sort are 10 steps ahead of you in thinking about security and protection. So I think it’s a great idea to go through those tutorials and learn the basics of what’s happening when you send in credentials and create a token and all of that. Just knowing that in the real world, if you go to like something that needs to be deployed to thousands or hundreds of thousands of users, then what’s happening there is the identity platform is going to be taken into account a lot of things that are kind of way outside your scope. Like what happens if I get like a brute force attack on somebody trying to break all of my user’s passwords? That’s something that kind of the average developer, that’s a lot for them to take on.

[00:28:46] SY: Yeah. That sounds huge.

[00:28:48] SJ: Yeah. And that’s only one of like a bunch of different potential problems. So. If you want to understand how the authorization server is sort of working or how like an identity service is kind of working, then you can kind of experiment with creating your own as an educational experiment and that’ll teach you a lot of the basics.

[MUSIC BREAK]

[00:29:11] SY: Coming up next, Sam talks about if there’s such a thing as an Auth engineer and what his developer advocate engineer job looks like after this.

[AD]

[00:29:30] Images and videos are the heaviest resources users have to download when they use your site or app. Achieving great experience with media was a complex and tedious task. But with Cloudinary, there’s a powerful API that employs sophisticated algorithms, machine learning, and automation to deliver great media experience on any device for any framework in web or mobile app. At Dev.to, we’ve been impressed with Cloudinary serverless API platform and recommend it to developers as the one and only solution they can use to solve all their media problems.

[00:30:05] Over nine million apps have been created and ran on Heroku’s cloud service. It scales and grows with you from free apps to enterprise apps, supporting things at enterprise scale. It also manages over two million data stores and makes over 175 add-on services available. Not only that, it allows you to use the most popular open source languages to build web apps. And while you’re checking out their services, make sure to check out their podcast, Code[ish], that explores code, technology, tools, tips, and the life of the developer. Find it at heroku.com/podcast.

[AD END]

[00:30:44] SY: Is there such a thing if I want to really go deep and really learn about Auth? Is there such a thing as an Auth developer or an engineer?

[00:30:53] SJ: There is sort of an idea of like an identity expert.

[00:30:58] SY: Okay.

[00:30:58] SJ: Identity is sort of like the broad category for all of this stuff. Whether it’s the different standards or building out this kind of software, there’s actually a position that people are creating called “Director of Identity and Access Management”, which is sort of like a very high level, almost like kind of architecture level. If you get really into this stuff, there is a career path there for sure, because it’s such a specialized area that if this stuff really interests you and you start geeking out over it, you can definitely specialize in it and you’ll have a lot of options there.

[00:31:35] SY: I’m thinking about some of the titles that you use, it reminds me of security. Does it fall under the security umbrella or is it still a part of development?

[00:31:44] SJ: Yeah. So I would say this idea of like identity and access management, you can’t see my air quotes, but that I think is sort of the developer like umbrella, which I think would be nested under the big, broad category of security, because this is a part of security and it’s sort of like software security as opposed to like network security or like hardware security. You’re dealing specifically when it comes to like access and identity stuff, most of the time you’re still in like the software world, the developer world of like, “How do I implement a login system? How do I manage my users? How do I make them have a seamless experience on different devices?” And that’s all sort of under this umbrella of identity and access management.

[00:32:39] SY: So what kind of stuff do you do at Auth0?

[00:32:43] SJ: I’m what’s called a developer advocate engineer, which is what we call is under the developer relations category. So developer relations is kind of half teaching people about these things in Auth0 and all of that, which some people call evangelism, and then the other half of it is called advocacy, which is basically like seeing how developers are using the product in the real world, what kind of problems they’re running into, what kinds of things they’re stuck on with implementing Auth0 in different languages or different technologies, and then trying to take that back to the different teams. So we have like an SDK team. We have a lot of different teams in the company build out this product because it’s a big surface area. So when we go to conferences or meetups or just like chatting with people, we’re trying to listen for what we could do better, what we’re already doing well, and bring that back to the rest of the teams at the company.

[00:33:49] SY: That sounds like a lot of fun. It sounds like you get to maybe speak and travel a bunch.

[00:33:54] SJ: Yeah. I mean, it is a fun job. There’s a lot of travel. I do speak at a lot of conferences and do a lot of remote stuff and meetups and Twitch streams and all of that stuff. It’s sort of a balance of not wanting to travel constantly, but then also wanting to create things at home, either writing or videos or things like that. So it is a really cool job. It’s a lot variety and a lot of autonomy, which is really cool, but there are things to consider with it. I think there’s kind of a wide trend now of trying to determine what’s the best way of tracking the return on these things. And so there’s a lot of figuring out what metrics to use and how do we know if we’re doing a good job, how do we know if the money we’re spending on sending someone to a conference is paying off. So there’s a little bit more science to it now. It sounds really glamorous, when you first hear about it, but actually, there’s a lot more to it than just sort of like you don’t really have carte blanche to just like do whatever you want. Somebody’s got to track like what you’re doing, and now there’s almost an entire industry around determining what the value of developer relations is and how to track it and things like that. But it’s a cool career for sure. It definitely keeps me on my toes and interested.

[00:35:16] SY: How did you get into it?

[00:35:18] SJ: It’s funny. A few years ago I had started to build my first video course based on this really difficult problem that was happening in the Angular community. So I built this video course. I had zero experience doing that. But in order to promote the course, I started writing articles about basically the content. And so I was starting to do guest posts on other blogs and things like that. So a friend of mine, that I had known from the Angular community, messaged me eventually and was like, “Hey, we have a full time writing job here at Auth0 and I think you should apply for it.” Had that had never occurred to me, I didn’t know that was an option to write technical tutorials full time. That’s what I did. I applied and I started at Auth0, it’s called the content team and it’s basically responsible for the Auth0 blog. So I started writing for that. And then throughout that process, I started applying to speak at meetups and conferences. So I started to build up that side of things. And that was really kind of on the side as a side thing. I mean, Auth0 was supportive of it, but it wasn’t like my job. And then eventually we reorganized some things internally and it just sort of became apparent that I would be a better fit moving over to developer relations so that all of my speaking and videos and stuff like that, which is sort of become my day job and I wouldn’t have to do things as a side hobby.

[00:36:55] SY: Yeah.

[00:36:56] SJ: I sort of meandered my way into it because I didn’t know what my options were. You know?

[00:37:02] SY: Yeah. That was fair.

[00:37:04] SJ: I kept falling what interested me and eventually kind of the path opened up.

[00:37:09] SY: So I feel like that’s the story I’ve heard from many developer advocates and developer evangelists. They kind of like stumbled into that career. Now that you’ve been doing that career, I’m wondering for folks who might be interested in being where you are today, what advice do you have for them? What should they do?

[00:37:24] SJ: Really to just do this kind of thing on the side, if that’s what you like. If you want to write, then write. If you want to make videos, then make them If you want to speak, then start trying to get speaking engagements at even just meetups or online. I mean, the nice thing now is that there are so many platforms out there that lower the barrier to entry to building that kind of content. You can obviously write for like Dev.to or stream on Twitch or make videos on YouTube. You kind of have all the tools available to you now to start building your own like little audience and building out content and things like that. Then once you sort of got that going, I think it’s just a matter of continue needing to find those jobs and apply for them as much as you can. I think we’re sort of right now in a surge of developer advocacy jobs. And so I think you’ll see more and more of them with startups or even up to really establish companies. So I think the barrier to entry is going to start lowering just because it’s becoming such a major career track in tech.

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

[00:38:50] SJ: Yeah, I can do it.

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

[00:38:55] SJ: Somewhere along the line, I started to believe that in order to get anything done, I needed to make perfect decisions and just like wait until I had all the facts before acting. I can’t think of a way to like succinctly say that as a piece of advice, but it clearly became like a core tenant of my life until probably my late 20s. It wasn’t until probably the end of my 20s that I realized that it was actually better to just act and make a mistake and improve on it and learn from it than to just wait and wait and wait until you make the absolute perfect decision based on all of your data.

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

[00:39:36] SJ: So the best advice I’ve ever received is not to self-identify with negative things about myself. So for example, we tend to find ourselves saying things like, “Oh, I’m just a messy person.” And I didn’t realize that when you say those kinds of things about yourself, you’re actually inherently preventing yourself from being able to change. That really made a huge transformational difference in my life over the last maybe five or six years.

[00:40:03] SY: Yeah. Oh, I love that. That’s a really good one. Number three, my first coding project was about?

[00:40:09] SJ: My first coding project ever was when I was like 12. And back before things like YouTube existed, people used to replace their system sounds with clips from movies or TVs. Like I replaced my error sound with Han Solo saying like, “I’ve got a bad feeling about this.” So my first project ever was like downloading a million of these audio clips and making a website of like Star Wars sounds and like Star Trek sounds and things like that where people could download them and use them on their computers, which is like simultaneously like the nerdiest and most lately ’90s thing you could imagine. I really wish that website still existed. There’s no way for me to like recover it, but that was my first one ever.

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

[00:41:03] SJ: When I was very first starting to learn to code, I had mentioned this earlier, but I thought that I needed a degree in computer science in order to do it. So that was one thing. And then when I was first starting to learn to code professionally, I’d say that I wish I had known that I didn’t need to worry too much about learning, like the exact right thing, like the exact right framework that was going to get me a job or the exact like language. I was really stressed about picking the right language or picking the right framework. Like I said, when I got to my first job, like none of that really mattered. And so I guess to say all of your learning is counting for something. Even if you end up getting a job that’s in a different language or something like that, you’re still learning these coding concepts and learning to be a programmer no matter what. So I wish I had known that and not stress so much.

[00:41:54] SY: Well, thank you so much for joining us, Sam.

[00:41:57] SJ: Yeah. Thank you so much. It was an honor.

[00:42:05] 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.