[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 showing up in tech with Jason Lengstorf, host of Learn With Jason.

[00:00:19] JL: The way to build a network is to be present in the communities that you want to work in, and if you are a persistently active and friendly and helpful person in the community, people notice that and people are going to help.

[00:00:33] SY: Jason talks about how he found his way into tech after being in a band, his passion for code, and all things developer relations after this.


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

[00:00:51] JL: Thanks so much for having me.

[00:00:53] SY: So rumor has it that you started coding when you were in a band, which sounds like a very fascinating story. Tell us that story. How did you get started while being in a band?

[00:01:02] JL: So like many of my generation thought that I was going to find my fame and fortune as an emo band singer.

[00:01:09] SY: Makes sense.

[00:01:09] JL: And so I dropped out of college about halfway through my first year and jumped into an emo band and we weren’t great. So we didn’t…

[00:01:20] SY: I thought you were going to say we weren’t popular, but you said you weren’t great. That’s amazing.

[00:01:28] JL: So we were good enough to tour, but not good enough to make a bunch of money doing it. And so we needed tour posters. We needed merch. We needed to update our MySpace. We needed a tour blog and stuff like this, right? And so I didn’t have any money from the band to hire somebody to help. So I decided I would just figure it out and got my feet wet in design. First, I was doing merch and then tour posters and stuff like that, figured I could maybe figure out how to customize a MySpace page. Turned out that was a lot of fun.

[00:01:59] SY: Yeah.

[00:02:00] JL: So I built us a website and then I built it again. I think I redid that website 14 times because it was just something to do in between shows and that taught me a ton. I started out in just HTML and CSS. I started figuring out a little bit of JavaScript and then I wanted to let the bandmates update it, so I learned PHP so that I could give them a CMS, learned some Flash because I needed to put the music up to play on the site without people being able to easily download it. And just a whole bunch of stuff that really led to me kind of accidentally becoming a web dev.

[00:02:33] SY: That is amazing. So how long did you end up sticking it out with the band before you broke off and did something else?

[00:02:40] JL: I played music from about my freshman year in high school until 2007. So all things considered, that’s, what, eight years.

[00:02:48] SY: Okay. Wow! That’s dedication.

[00:02:51] JL: I was really sure we got close at the end. It was one of those things where like the last year that we were touring, we were in talks with record labels and stuff and then we found out that record deals, unless you’re really successful, are kind of like high interest loans. And that made us really nervous. So we decided to break up before we sign any paperwork.

[00:03:10] SY: So once the band broke up, what happened next?

[00:03:13] JL: So I started looking at, you know, “All right, what could I do next? What did I want to be when I grew up?” And I started thinking about what was going well with the band because my first instinct, of course, was start another band. And I looked at the spectrum of things that we were doing and realized that about the only thing that I wasn’t good at in terms of being a touring musician was music. I was good at booking. I was good at building community. I was good at the design stuff, good at the website stuff, and I was pretty organized. I would negotiate with the venues and make sure that we got paid, make sure that we got places on time, and I realized that almost all of those skills were transferable. And so I was like, “Well, what if I just wanted to make websites for a living?” Well, it turns out that I’d learned almost everything I needed about running a freelance web dev agency as the de facto manager of the band. And so I just kind of hung up my shingle. I found a friend who needed a website, so I built him a website and then his parents owned a karate school and they were my first paying customer. I think they paid me a couple hundred bucks to build them a website.

[00:04:16] SY: Nice.

[00:04:17] JL: And then that led to the next one and the next one. And before I knew it, I had kind of made enough that I was able to not get another job. Like I was still broke, but I was able to keep the bills paid. And that was when I became a professional full-time web developer. And then I’ve just built on it ever since.

[00:04:35] SY: And I know that you went from that agency to working at IBM as a front-end architect. I don’t think I’ve heard of a front-end architect before. I’m used to hearing a front-end developer. But What’s a front-end architect? What’s that about?

[00:04:47] JL: So this was sort of an accidental thing. I got hired as a staff level or one of the senior folks on the front-end team. And what happened when I showed up is I realized that IBM Cloud, which was the product that I worked on, was made up of a few dozen teams and each of those teams had a lot of shared code, but it wasn’t shared in a way that was particularly efficient or really scalable, which is troubling when you’ve got 30 something teams. So I started looking at what everybody was doing, and we had, for example, if you were a Day 1 developer joining IBM, you would get handed your laptop and they would say, “Okay, now install Nginx.” It’s like, “Well, hold on, that’s not front end.” And then after that you got to configure firewall and then you got to set up the mock databases and it’s like, “Hold on, this is too much.”-[00:05:41] SY: “Is that what I signed up for?”

[00:05:42] JL: Yeah. Right? I’ve been doing this for a long time and it was still a lot for me and we had IBM Design ran a front-end bootcamp where people were coming out of 12 weeks of like, “I just started coding 12 weeks ago,” and their first day when they came out of bootcamp was this. And I was like, “This is not okay. We got to make this better.” So I started looking into what are the common pieces? What are the things that are important? Why do we set it up the way that we set it up? And so there were considerations around staging and security and general compliance. And we had a design system and all of these different pieces. So I started looking at how can we build the right pieces into the front end of our app so that all of these microservices that run the IBM Cloud front-end can be spun up by somebody on day one, regardless of experience level, so that they’re actively contributing. And also, so that when we have updates in the future, it doesn’t require somebody to go around and manually copy-paste code between these 30 something teams to get compliance solved whenever we get a new requirement. And so in doing that, when I started doing that work, I just started de facto acting as an architect there and ended up rebuilding a lot of internal tooling to simplify and work on the developer experience, work on the normalization of our development workflow so that people could actually follow it so people weren’t having to DM environment variables back and forth on Slack and all these other things that that kind of happen as a code base gets big and unwieldy. Through some thoughtful design, you can eliminate the need for how that works. I called it a front-end architect at the time, and what I realized was it was an internal tooling team before I realized that internal tooling was a thing that you could be.

[00:07:21] SY: A title. Yeah. Yeah. Very cool. Wow! So your next job was at Gatsby as their head of DevRel, as I understand it, and that seems like a pretty big jump going from front front-end architect, internal tools to DevRel. Tell us more about DevRel. What was that job like?

[00:07:37] JL: So the thing about Gatsby is I joined when they were seven or ten people. I was one of the very first hires. And they hired me as an engineer. And it was because I was actually trying to adopt Gatsby in IBM as part of this front-end architecture work. And what I had been finding was two things. One, I found the ultra-scale of a company like IBM, which has over 400,000 employees. It’s huge and a lot of people have to agree before you can make big, sweeping changes, and I wanted to work somewhere smaller. And I’d also realized that doing this sort of internal tooling work meant that I was spending a lot of time doing education internally. So I held a lot of lunch and learns. I would go in bed with other teams and like try to explain not just that they should use the software, but like why this stuff was important and what best practices were and how to make things a little bit better and all of that I realized was basically DevRel. It was just internal DevRel. So when I went over to Gatsby, they were trying to figure out where I fit in. Like should I be an open source engineer? Should I be an engineering manager? Should I be an individual contributor? And the joke became that I was human duct tape. They just kind of stuck me wherever there was a problem, because that’s sort of where I thrive is a little bit of chaos and a little bit of just let’s figure out what’s going on and try to make it better. And the biggest area that Gatsby needed help in was community building. And so I sort of took over that function and I built out the swag store and I built out some automations in GitHub so that anybody who contributed would get a coupon code for a T-shirt and would get invited to the GitHub contributor’s group. And there was just a whole bunch of little things that we wanted to do to make people feel actively included when they were part of the project. And I don’t think I was thinking of it as DevRel when I started doing it. I was just kind of thinking, “This is a thing that we want to solve. It’s important to the business, so let’s make it work.” But over time, it became pretty clear that that was the job I was doing was DevRel or dev experience, whatever you want to call it.

[00:09:41] SY: And then you took a role at Netlify as their principal engineer, which again seems like a pretty different job from dev to principal engineer. Tell us more about what Netlify is. I feel like that’s been the cool kid on the block for quite some time now. The hot new-ish thing, new-ish. Tell us more about Netlify and what it was like to be a principal engineer there.

[00:10:00] JL: So Netlify is a platform for building for the web, and the easiest part of it is there’s a lot of boiler plate that you have to do to set up a website. So it’s not just building a website. You got to find a server. You got to figure out how to get it online. You got to point your domain to it. You got to figure out how to keep it scaling and not pay a bunch of money to have to, like, if you get popular, it goes to the front page of whatever website, Product Hunt, and you get a bunch of traffic. You don’t want your site to go down. And so Netlify allows you to build in a GitHub repo and then connect that to Netlify. And anytime you push changes, it’ll pull those changes and automatically build and deploy your site on a CDN and all the things that you want. And it does that. We’ve got a great free tier. So you’re able to do quite a bit on Netlify without having to pay for it, and it just opens the door for a lot of expiration. You spend all of your time building the features that you want in your app instead of figuring out how to get those features onto the internet. And they’ve got a bunch of stuff, like you can buy a domain name there. They’ve got serverless functions if you need an API or any kind of server-like processing. They’ve got edge functions if you want to do personalization. They’ve got automated form handling, so you can just take any HTML form and add like data-Netlify=true as an attribute, and it’ll automatically pick up those form submissions and you can put a contact form on your site without having to mess with any of the server stuff that you would’ve to do otherwise. And a whole bunch of little things like that that just make it much nicer as a developer to be able to have an idea and get that idea on the internet without having to think about what’s the foundation of this, the infrastructure of this, what’s the deployment story. It all just works, and that’s really nice. So when I left Gatsby, I was actually intending to not have a job anymore.

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

[00:11:46] JL: That was the whole intention. I had been doing a lot in the community. I had started Learn With Jason. I was really kind of burned out on the idea of working for companies in general. It’s very difficult as you get further up the reporting chain because you spend less of your time doing things that you want to do and more of your time trying to sort of steer the rest of the leadership team so that you’re not hurting the team or causing problems or stepping into a PR disaster, whatever these things are that happen in in tech, they seem to happen at an alarmingly high frequency. So when I stepped away from Gatsby, I was like, “I just don’t want to do that anymore.” But then Sarah Drasner, who is of all the people in the world, one of maybe five, that I would drop anything to go help. She hit me up and she was like, “Hey, I’m building out a team. Do you want to come and be on it?” And I was like, “No.” And then she called me and she pitched me on what she was building, and she said she’s building out a developer experience team, which is very similar to developer relations. But if you think about the spectrum of like marketing to engineering that DevRels do, the developer experience model is much closer to engineering. So it sits with product. It’s like user zero, testing any new things, giving feedback on new product APIs, a lot of engineering work, and then also taking that to the community and teaching them how to use it and building the demos and doing the workshops. And so she said, “Hey, come be a principal engineer on this developer experience team.” And the opportunity to learn from Sarah, the opportunity to be on a team, because when I was at Gatsby, I was effectively a team of one, and the growth opportunity of being surrounded by people like Phil Hawksworth was on the team and later on like Cassidy Williams joined. And I got these opportunities to work with these absolutely brilliant people. It’s kind of hard to say no to that. In retrospect, I am really, really grateful that I did it because I can’t imagine where I would be without the experience and community and lessons that I’ve learned from being on that team. It was definitely like a right place, right time kind of thing because I think if she would’ve asked me six months later, I would’ve already been set up solo and probably would’ve said like, “Oh, it’s too late. I’m already doing this thing.” But she hit me at exactly the right moment.

[00:14:03] SY: So let’s talk about the thing that you are doing now full-time, officially full-time, and exclusively full-time, Learn With Jason. Tell us a little bit about what Learn With Jason.

[00:14:15] JL: Learn With Jason started as a live stream where I pair program with somebody to learn something new in 90 minutes. I do the show twice a week. I started it back in 2018 and I’ve made over 300 episodes at this point.

[00:14:30] SY: Wow! Oh my goodness! That’s so many episodes. Good for you.

[00:14:34] JL: It has been so amazing because it lets me just talk to somebody who I think is brilliant and say, “Hey, you know a thing I don’t know. Do you want to come teach me how to do it?” And then I know enough about engineering that we’re talking about their thing. They’re not like explaining syntax or anything like that to me.

[00:14:51] SY: Right.

[00:14:52] JL: And instead, we’re talking about the concepts. Why is this thing cool? Why would I use it? When is it the right thing to use? When is it the wrong thing to use? And it’s the only way that I can imagine that I’d be able to keep up with front-end trends because there’s so much happening and typically what I’ve had to do is if I don’t have an active problem, I just have to kind of let the community keep moving, and when I have a new problem, I’ll go do research about where we are. And so this has given me an opportunity to really stay stuck in and learn about what’s going on in a way that doesn’t take a huge time commitment. So it’s sort of drinking from the fire hose in a way that is manageable and doesn’t make me feel like I’m not missing out, I’m not overcommitting. I’m just kind of able to stay in my Goldilocks zone of, “I’m aware of what’s going on, I know what the benefits. And when I have a problem, I’m now more equipped to say, ‘Ah, I remember I talked to so and so about this, and there’s a solution that will help me solve this problem.’” And so over the years through, it started when I was at Gatsby. It stayed through Netlify and now I’ve been lucky enough to have the opportunity to do it full time. The show’s going to continue. I’m going to do a little more of solo stuff, kind of build, Learn With Jason on Learn With Jason. So work on the website, the different automations and things that I do, as well as do a little consulting, like teaching companies how to do better DevRel and how to grow healthy communities in a way that’s sustainable and welcoming and makes people feel like they want to be there and not like they’re being sold to. And then I’m also helping companies make more ambitious video. At Netlify, I was very fortunate to get a chance to put together some projects where we worked with a full production crew and we made like a short film and then we worked on some 15 to 32nd pre-roll ads that we can put on YouTube to promote the service and help people understand what it does and why it’s cool. And I want to go help more companies do this kind of stuff, do more ambitious, like almost infotainment, like the idea of being able to go and watch something because it’s pleasant to watch. And while you’re doing that, you do learn things that will be beneficial in the future when the time is right, but like you’re not watching it because you have to or because you’re trying to learn this exact thing right now, but rather because it’s nice to go see what’s out there. And this is the reason that I used to watch stuff like The Great British Baking Show or Dirty Jobs with Mike Rowe, or the Chef Show with Jon Favreau and Roy Choi. Like you watch these shows because it’s somebody doing something that they’re clearly passionate about and maybe later I’ll like want to cook something that I saw on Chef Show, and then I’ll go back and use it as a reference to get a recipe. But I didn’t watch it for the recipe. I watched it for the show and learned something kind of as a byproduct.

[00:17:27] SY: And that’s the way you kind of see your content is it’s not necessarily, “Here’s a course, break out your text editor, let’s do it together,” but more of entertainment value, but you’re also learning and kind of getting a lot of value for that time spent watching.

[00:17:41] JL: Exactly. And the hope is that people feel like they are gaining awareness without necessarily gaining skill, if that makes sense. Like you’re seeing that the world is bigger.

[00:17:51] SY: Oh, I love that. Yeah.

[00:17:52] JL: And that there are things out there, but you don’t watch Learn With Jason to like hardcore level up on a skill. You’re watching Learn With Jason to get a sense of what’s possible, and then you would use that as the jump off point to go into a workshop or a more specific course or something like that, because now you’ve got enough context to understand that yes, this is the choice that I needed to make.

[00:18:13] SY: That makes a lot of sense. Okay. So how do you come up with the curriculum? Like how do you figure out what you want to talk about? I feel like to your point, technology’s changing all the time. There’s so many new tools and new ways we can approach things, things we can learn. How do you decide what to put on your show?

[00:18:29] JL: I mean, the short answer is I’m extremely online.

[00:18:33] SY: Okay. Cool.

[00:18:34] JL: And so I’m watching. If I see a lot of people getting excited about something or having questions about something, I’m pretty likely to go reach out to somebody who’s really close to that subject and say, “Hey, a lot of people are asking questions about React performance. Can you come on the show?” So I just had Shaundai Person came on and taught React performance earlier today actually. And that was very much a result of like, “We know that people are talking about that. React is a hot topic. People are talking about its performance implications. Shaundai’s an expert. She works at Netflix.” So I hit her up, I was like, “Hey, do you want to teach that?” And she was like, “Absolutely yes.” Sometimes it’s that. Sometimes it’s that I’m in the right place at the right time, having a conversation and somebody brings up a thing they’re working on. I’m like, “That’s amazing. Do you want to teach that on the show?” And then we get cool things like people teaching how to do SVG animations, or there’s this person that I’m so excited to have on the show, his name’s George, and he’s going to teach us how to do generative art in HTML and CSS and SVG and I’m like, “I cannot wait.” Or like Char Stiles came on and taught me how to make shaders that are reactive to audio. You just get these really incredible things that are sort a friend of a friend tells me about this thing that’s happening, I’m like, “That’s super cool. I want to learn that.” And then I’ll just send somebody a message and say, “Hey, I know you don’t know who I am, but would you be interested in teaching this thing?” And sometimes they say yes.


[00:20:08] SY: So I think one of the problems that we face as new developers, early career developers, people learning to code is the problem of shiny new objects. There are so many shiny new objects, so many different tools we could learn. So many things popping up all over the place. As a person who seems to focus on those shiny new objects, how do you recommend balancing staying up to date with not being overwhelmed with all the possibilities and all the things that you could possibly study that you probably don’t have time for?

[00:20:43] JL: There are a few points of consideration when you start looking at this because the first thing is just really accepting and being okay with the fact that we’ll never learn everything. Too much is happening too fast. You’re only ever going to know some things, and that’s okay. The point of this career isn’t to be a complete encyclopedia of everything that’s possible on the web. Your job is to learn how to solve problems. And you’ll hear the joke made that senior developers aren’t necessarily any better than early career developers. They just know how to Google more effectively. It’s tongue in cheek, but it is true, like a lot of what’s happening is you learn as a developer as you grow in maturity that solving problems doesn’t require you to just know things. It’s not in my brain when somebody says, “Hey, can you make X to Y?” I don’t go, “Oh, yes, of course. I studied that before and now I know how to make X to Y.” So I’ll just type this code from memory. No, but I know exactly what to Google and I know exactly how to discern between good advice and bad advice because of my experience and make better choices for the things that I do. That’s part of it is just being okay with the fact that we’re not going to learn everything so we don’t have to try. The other piece of it is taking a moment to recognize what you’re optimizing for because what I would choose to learn if I was optimizing for a new job is very different from what I would optimize to learn if I was in a job and trying to level something up or get transferred to another department or get to the next rung of the career ladder. And so once you know what you’re optimizing for, then making choices that are based on not like, “Is this thing new? Should I go study it?” But this thing is new. Would learning this help me achieve the goal that I have right now?” And if the answer is no, then being okay with saying, “Okay, I’m going to put that on my list of someday ideas, and I’ll come back to it if I can.” But I need to learn things that’ll help me achieve the thing that I’m optimizing for now. And then the third piece of this, and this is the one that I think has made the biggest difference for me, is find ways to have long running ideas that give you room to play. So a really great example of this is Lynn Fisher. Lynn Fisher every year rebuilds her personal website. And every year it’s an event. When it’s Lynn Fisher Website Day, the whole internet is talking about it. And it’s incredible because she always does something fun and playful. And if you talk to her about it, “Where do you get these ideas?” She’s like, “Well, I’ve been thinking about this thing since like 2017, and the CSS spec got updated last year and it finally made it possible. So I wanted to try out this idea.” And if you look at her site today, it’s this sort of, as you scroll, you zoom in or out of this world where you’re going through a room and then you go through the TV. It’s just very cool and very creative. And you can tell very much that Lynn is learning a lot as she does each of these revisions. But it’s also her site. It is one project that she revisits every year, and so it’s got parameters and it’s got goals, and it’s got a well-defined outcome, and it sets expectations. People know what Lynn is doing when she says, “I launched a new website.” It’s because they’ve seen it every year. And what I love about that is that it lets her learn and play, but are well-defined enough that she doesn’t look frantic, right? Like I’ve seen people who look frantic where they’re trying to learn things and they’ve got these abandoned projects and half-finished things all over the place, and nothing really ever gets published. You can see a lot of activity, but not a lot of progress. By building on one project, it’s an evolving and continuous effort as opposed to a lot of disparate efforts, if that makes sense.

[00:24:25] SY: Yeah, that makes a lot of sense. And I love this idea of asking yourself, “What are you optimizing for?” And assessing is it just activity or is it progress? Because a lot of times we can be fooled into thinking that our activity is progress, but when we look back on what we did, like you said, it’s frantic, it’s all over the place. There’s no cohesive story. We haven’t really moved forward. We’ve just kind danced around in circles. And so I love the idea of asking ourselves, “Are we making progress or are we just doing a lot of stuff?” And if it feels like we’re just doing a lot of stuff, maybe it’s time to take a step back, refocus, reprioritize, and try again. So tell me a little bit about why you started Learn With Jason. This format, this edutainment angle is very different from the way I’ve heard other content creators talk about their content. So I’m curious, how did you kind of land on that and what inspired it to begin with?

[00:25:21] JL: It was partially happy accident and partially looking outside of tech. The happy accident part is when I was at Gatsby, I was trying to figure out ways to make the community more transparent. It’s an open source project. I wanted to make sure that it didn’t lose that as the company grew. And so I was just like, I don’t know, maybe live streaming is a way to connect with people and give them visibility into what’s going on. I was looking for ways that were lower effort because there’s only one of me. I didn’t have time to produce like a news show to give updates or something. And that’s not really transparent. That’s like curated news. So what’s the unadorned way to do this? And so I was like, “I don’t know. What if I live stream meetings?” So I started live streaming meetings and it was terrible. It was so boring. Nobody cared at all. But then people would ask me questions, they’d be like, “Hey, I’m trying to build a Gatsby site and I’m trying to do X, Y, Z. How would you do that?” And so I’d hit him up. I’d say, “Hey, would you be willing to do this on a live stream so that we can record this and share the outcome with other people?” And a few folks said yes, and it was better. But what I didn’t like about it is it was me as an expert putting somebody who was already having to like be uncomfortable enough to put themselves out there and ask me for help and admit they didn’t know something, and then I was putting them on the spot to be not knowledgeable and to be in a student capacity in public. I didn’t like that power dynamic. I thought that was like Jason, the Genius, and all the people coming to me for my knowledge.

[00:26:51] SY: Jason, the Genius, new show idea. I like that title. Learn With Jason, the Genius, rebrand. That’d be very good. You’re welcome.

[00:27:04] JL: Thank you. Thank you. But yeah, so I didn’t like that power dynamic of somebody having to like come to me and not know things in public. So then I realized, “What if I just flip that dynamic because I have my career behind me. I’ve got my credentials. I’ve got all my other privilege stacked up where I can ask beginner questions. I can represent not knowing things.” In a lot of cases on the show, I pretend not to know things because I want to ask those beginner questions and make sure that we’re really explaining why does this matter, why is this important. And when I made that shift on the show, it immediately started to feel like the right thing. I was taking somebody from the community and making them the expert, and I’m asking them questions that let them show off their knowledge. And by me being the ones with my hands on keyboard, then they aren’t on the spot to live code. If something goes wrong, I have to recover from it. They just have to stay with me. Right? And so it put the pressure in the right place. It put the focus on the right place and it felt good. Like I felt like it was the right dynamic for the show. So I started going that way. And then as I got in with Gatsby a little bit more, I realized I didn’t really want it to be the Gatsby show. And I’d always been pretty certain that I didn’t want this to be like a show about Gatsby. I wanted it to be about modern front end and the community itself. So I started framing it that way, which is how it became something that survived my departure from Gatsby and now my departure from Netlify and it’s its own thing. And then the other piece of it that was big for me was thinking about like, “What do I like when I watch TV? Who are the people that I get really excited when I see their show?” And it put me in mind of like Jon Favreau. I brought him up, Chef Show earlier, and he made the Marvel movies and he’s done a lot of directorial work. He’s an actor. He’s a writer, producer. He does all this different stuff. And so there’s a part of me that just loves this idea of sort of being a person who does whatever is the most interesting at the moment and just kind of having the means to do that. But the other thing that I saw was he made this movie called Chef.

[00:29:11] SY: Such a great movie.

[00:29:12] JL: The stated goal behind Chef was to make a film about food that when actual food industry people watched it, they would not cringe at the cooking scenes. He hired Roy Choi to be his consultant, and during the filming of Chef, they just worked together all the time so that Jon Favreau could learn enough about cooking and enough good technique that when they filmed the seams of him cooking, it was convincing that he was a chef. Then the movie ended, right? They wrapped and Jon Favreau was like, “You know what? I don’t want this to end. Roy, you want to just keep doing this?” And so they just started filming, like Roy and Jon go to their friends’ kitchens and cook. It’s sort of a cooking show, but they don’t have recipes and it’s sort of an interview show, but it’s not really that either. And it was very clear that it was just, “We enjoy being together and having food as a driving theme. Let’s continue to make entertainment.” Right? And so I really like this idea of the humanity that comes in when you find something that’s enough of a shared interest that it can spark the conversation. But it’s not the only thing you talk about. And to me, this is the most valuable part of the tech community is that a lot of people that you meet in tech are so interesting beyond their technical expertise, but because we have that overlap in our Venn diagrams of being technical professionals, it starts the conversation, but it quickly veers off and you’ve got somebody talking about how they like make their own yarn or somebody’s talking about how they hiked the whole Pacific Coast Trail. Or I’m in a blood feud with Sarah Drasner over who makes a better burger. These are all these sort of like little things that emerge when you start talking about tech and then realize that there’s a whole person underneath, you build much more interesting conversations and much more interesting relationships. And I really like the idea of making media that is educational in part, but that’s also really highlighting that there are people under all this tech. And the best part of it is the community.

[00:31:13] SY: Absolutely. So there are a couple things that you really believe in and you advocate for on your show. One of them is this idea of sticking to a routine. You mentioned how important it is to stick to a routine. Where does a routine come into play when someone is learning to code, leveling up, trying to get that first job.

[00:31:34] JL: When I talk about routines, I mean it in the sense of try to make things that aren’t a big factor in the learning itself or the creation itself, try to take them out of the pool of things that requires mental energy. So thinking about it as if every day I wake up and I’ve got a blank slate and no plans and the first thing that I have to do is I have to sit down and make a list of the things that I want to accomplish and then I have to strategize how to accomplish them, and then I have to prioritize that list, and then I have to figure out where I’m going to do that work and all of these things that require just a little bit of mental effort, I am almost certainly going to get less done than if I didn’t have to make any of those decisions. Like I’m using so much of my mental energy for the meta work of starting to work than I would for the working itself. So getting a routine where you know roughly how things are going to go. Like my show is a good example of this because I know, with every show, it’s 90 minutes long. I have a guest. We’re going to learn something together. The first 15 to 30 minutes is discussion, and then I’m going to shout out to the captions and the sponsors, and then I’m going to live code for the remainder of the show. There’s a formula that we follow and it’s the same for every show. So I don’t have to waste any cycles figuring out how to make the show work. I spend all of my mental energy on engaging with the guest on writing the code. And I do the same thing with, if I am working on a project, for example, I will try to figure out what do I need to get this project done, and then I’ll try to do it in a way that’s repeatable. So if I know that I need two hours of quiet, focused time a day, and I’m going to need that for like two weeks, can I just set up a routine where every morning I wake up, I make my coffee, I grab my computer, I go into my room, put on my headphones, I’ve got a focus playlist, and I just leave my phone and do not disturb with an alarm set for those two hours, and then I know I’m not going to look at email, I’m not going to look at Twitter, I’m not going to look at Slack until my alarm goes off. So I get two hours of focused work. So that routine helps me not have to fight distractions, not have to think about how I’m going to create space. I already did, and now I can follow those steps over and over again. And I think routine has a tendency to become so prescriptive that there’s no room left to be a person anymore. You’re kind of like this robot. There’s the t-shirts that drive me up a wall that are like, eat, sleep, work, repeat. I really don’t mean it like that.

[00:33:59] SY: Yeah. Yeah.

[00:34:00] JL: It’s thinking about the things that drain your mental energy and seeing if there’s a way that you can sort of make those decisions once in a repeatable way so that you don’t have to dedicate a lot of effort to getting to the point that you can work. You get to use all of your energy for actually the stuff that’s going to help you progress.

[00:34:17] SY: I love that. For me, I feel like one of the biggest routine, solutions that I came up with that helped me be more productive and just make the most out of my time was around food and around meal prep. I feel like I hear so many people go like, “Oh, it’s lunchtime, I’m hungry. What do I eat? I got to figure out what I have in the fridge.” And it’s like this whole thing. And it doesn’t have to be that way. And if you do meal prep and you know every lunch this is going to be my go-to meal, I have a choice of one of three things that I can have today for lunch, at dinnertime is at 6:00 PM and this is what I have to… You know what I mean? If you just kind of put a little bit of upfront thought into something as simple as meal planning, you can get that out of your way for the whole day and focus your time on the things that are probably more valuable to you, whether it’s coding, family time, whatever it may be. So yeah, there’s all these little everyday things that you can just get out of your way so you can spend time and mental energy on the things that matter more. Coming up next, Jason talks about what the importance of showing up in tech means.


[00:35:33] SY: The other thing that I know you say is the importance of showing up, 85% of success is just showing up, and I’ve heard similar sentiments, similar numbers in other places as well. What does showing up look like as a person learning to code as an early career developer?

[00:35:51] JL: So there’s two kinds of showing up, and I think both of them are important. I think the first kind is you really do have to put the practice in, and this is like learning an instrument. It’s like learning a language. It cannot happen without practice over time. You can’t cram learning to code into a weekend. It’s the sort of thing that you’re changing your mental models, you’re building in instincts, and you don’t get instincts overnight. There’s no way to really do that. Right? So you got to keep showing up and writing the code and it’s going to be frustrating and it’s not going to feel comprehensible, and it’s going to feel like you’re not getting anywhere, but you got to keep doing a little bit constantly. And then the other part of showing up is especially when you’re looking for jobs. This industry is so network based and the way to build a network is to be present in the communities that you want to work in. And if you never show up until you need something, you’re not going to get the support that you would hope for. If you are a persistently active and friendly and helpful person in the community and you are constantly sharing what you’re learning, you’re giving away help whenever you can, you’re trying to be useful to the folks around you, people notice that. And when you say like, “Hey, I’m looking for my next job,” if 80% of what you’re doing is helping people and 20% is asking for stuff, people are going to help. They’re going to offer you, “Oh, I know somebody who’s hiring. Let me do an intro.” Or, “I just heard this company’s doing a thing.” But if you’ve never spoken before and then you go, “How do I get a job?” People aren’t going to respond to that. You’re not going to get that same welcome. So showing up in the community and recognizing that this industry is very small and this industry is very network driven. And so the people that you’re meeting, the people that you’re interacting with, you will continue to be in circles with a lot of these folks for the rest of your career in tech. And so you’re not just building a relationship for this job now. You’re building a relationship for your first job, for the job after that, for your next speaking opportunity, if you want to get into that, for an intro to somebody who is running a podcast and you want to speak on it, like the network is such a critical piece of this and continuing to show up and be a friendly and welcoming and positive addition to the community is, I would say, the biggest thing that you can do.

[00:38:19] SY: Absolutely. Now the end of every episode, we ask our guests to fill in the blanks of some very important questions. Jason, are you ready to fill in the blanks?

[00:38:33] JL: I’m ready.

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

[00:38:37] JL: Grind.

[00:38:38] SY: Oh, tell me about that.

[00:38:40] JL: I think there is a misconception and a glorification of the idea of working without breaks, without rest, and kind of pushing through pain as a way of getting what you want. And it is both unpleasant and through many research papers proven to be detrimental. If you are running on less than seven hours of sleep, your brain is as impaired as if you are over the legal limit for alcohol. If you are working over 50 hours a week for more than like a month or two, you’re more exhausted and you start making more errors, which means that you’re actually negative productive because you need to spend more time fixing the errors that you created that never would have otherwise happened. And there’s so much science behind this. So grinding is this insidious piece of advice where people say like, “Work harder and you’ll get there. You have to do this like a marathon. This is a decades long career.” And you’re not going to go from zero to principal engineer in a year and a half. And it does not matter how many hours you put in. You could put in all of the hours and you’re still going to have to put in time. It takes years to advance on this career ladder. And driving yourself into the ground is just going to hurt you physically. It’s going to hurt you mentally. It’s going to hurt your relationships. And I think that’s why people burn out and leave this industry is because they get this advice that they should just put everything into it and ignore everything else, and grind, grind, grind. And then they’re like, “This sucks. I hate my life as a grinder.”-[00:40:09] SY: Yeah. Yeah. Absolutely. Number two, best advice I’ve ever received is?

[00:40:14] JL: The best advice that I have ever received is that you can die of exposure.

[00:40:21] SY: Huh?

[00:40:21] JL: And what this means is a lot of times people will get asked to do work and they’ll ask to do it for free because it’s good exposure. And every single thing that we do has to come with compensation, and that compensation can be monetary. And often it should be because if you’re doing something valuable that somebody’s going to go make money from, you should get paid for it. But there’s other kinds of compensation. You can get compensated in your networking connections. You can get compensated with visibility. You can get compensated with recommendations on LinkedIn. There are lots of ways to get compensated and doing work for somebody else who’s going to profit from that work in some way for no compensation, like strictly for exposure, is almost always a waste of your time. The favor economy is real and it’s useful. You can kind of barter. But again, you are getting compensated for that work. But you have to make sure that you’re thinking through what is the compensation that I’m going to receive for this and is it something that is going to actually be beneficial to me, to the community, to whatever it is, and make sure that you are accepting these things for an understood reason. Like doing it for exposure is not well defined enough. And so make sure that you’re making choices about how you spend your time and making sure that you’re getting something back for that effort that you put in.

[00:41:46] SY: Very good. Number three, my first coding project was about?

[00:41:50] JL: My first coding project was about my band. I built us a… oh, this was so long ago. I built us a table-based, no-CSS iframe website back in the early 2000s, late ’90s, somewhere in there.

[00:42:08] SY: Yeah. Yeah.

[00:42:09] JL: It was wonderful. I mean, it was atrocious, but I had so much fun doing it.

[00:42:13] SY: How many colors and special effects did it come with?

[00:42:17] JL: I had learned how to use what was being called DHTML at the time.

[00:42:24] SY: Yeah.

[00:42:26] JL: Anybody who’s an accessibility specialist is about to send me a nasty message. I had learned that in older browsers like Internet Explorer and Netscape, there was this status bar at the bottom. And through the wonders of DHTML, which was like the early, early days of JavaScript, you could put messages in the status bar. And so I, being my teenage genius self, thought that it would be great to put the news in the status bar, scrolling like a marquee. So I was putting like a hundred words of news in a side scroller in the status bar.

[00:43:10] SY: Wow!

[00:43:10] JL: So if you missed part of it, you had to wait for it to rotate around again so that you could read the rest of the news.

[00:43:18] SY: You were Twitter Trends before Twitter Trends. That’s what you were. Number four, one thing I wish I knew when I first started to code is?

[00:43:30] JL: Oh, there’s so many. There’s so many things that I wish I knew. Okay. The one thing I wish I would’ve known when I started coding is patience. Patience and perseverance, I think. I have to make it two. I’m so sorry.

[00:43:43] SY: I’ll let it slide. It’s fine.

[00:43:44] JL: I spent a lot of time feeling very frustrated because I would build things and they wouldn’t be as good as what I was seeing online, and it took me an embarrassingly long time to come to terms with the fact that, one, your taste is always informed by seeing the best of everybody around you. And typically your talent is informed by the amount of practice you’ve done. So in most areas, your taste is going to outstrip your talent.

[00:44:15] SY: Yes.

[00:44:16] JL: And that’s not a bad thing. That means that you can see how to improve. When you run out of things to improve on, you’ve stopped growing. So part of it is realizing that your patience has to be that you need to make things that you’re not quite proud of so that you can see what gets better and build them again and build them again and build them again. And that’s where the perseverance comes in because once you build something and you see that it’s not as good as it could be, the instinct can be, “Well, clearly this isn’t my thing. I should like move on and, and find another industry and see which thing I’m instantly perfect at.” And that can lead to a lot of hopping from thing to thing to thing, waiting for the one that just kind of magically works. So being persistent and continuing to show up. So being patient enough to wait for your talent to develop as you practice and being persistent enough to continue to practice.

[00:45:07] SY: Yes. Yes. I love that. Well, thank you again so much, Jason, for joining us.

[00:45:12] JL: Yeah, thank you so much for having me. This was a blast.

[00:45:22] SY: You can reach out to us on Twitter at CodeNewbies or send me an email, hello@codenewbie.org. For more info on the podcast, check out www.codenewbie.org/podcast. Thanks for listening. See you next week.

Copyright © Dev Community Inc.