#167 From drop-out to software architect with Jason Lengstorf
01:20:55 Share

I mean, the biggest one is build, right? And the easiest way to build is to pick things that you...

care enough to complete. If you build an app that is useful to you and solves a real problem, you've just built your portfolio and you're proving that you can solve real problems with code, which is exactly what a company like IBM wants to see. Welcome back to the Free Code Camp podcast, your source for raw, unedited interviews with developers. Today, we're talking with Jason Langsdorf. He learned how to program out of necessity by building websites for local emo bands.

He dropped out of college but eventually worked as an engineer at IBM and has gone on to roles at many other companies, including software architecture, management, and everything in between. He now runs CodeTV, a Bravo-style reality TV channel for developers.

Support for this podcast comes from a grant from Wix Studio. Wix Studio provides developers tools to rapidly build websites with everything out of the box, then extend, replace, and break boundaries with code. Learn more at wixstudio.com. Support also comes from the 11,384 kind folks who support Free Code Camp through a monthly donation. You can join these chill human beings and help our charity's mission by going to donate.freecodecamp.org.

For this week's musical intro, with yours truly on drums, guitar, bass, and keys, we're going back to 1990 with the Game Boy classic, The Amazing Spider-Man. ♪

♪♪♪ ♪♪♪

Jason Langsdorf, welcome to the show. Thank you so much for having me. I'm so excited to be here.

Awesome. I've really enjoyed watching Code TV recently, your kind of like Bravo-style reality TV show for developers. And I wanted to ask you, like I heard a rumor that you had written a whole lot of custom software to produce that so you could kind of like have this like elaborate producer-type room.

Yeah. You watch these TV shows about network television and there's this giant room and there are all these people staring at monitors and pressing buttons on a big control panel. And my understanding is you automated a lot of that for your channel. Yeah, automated and also made it...

made it so that I could kind of multitask and control a lot of it at the same time. So if you watch any of the episodes of Elite Heat that have come out on Code TV, you'll see that I'm kind of sitting at a desk and I've got a couple of computers open. And the way that that's working is it's a, it is a multi-screen real-time state machine that I've put together where Mark, the host, is holding a tablet in his hand. And then we've got the TV behind him, which is showing the questions to the contestants.

And then each of the podiums for the contestants have a little screen in them that has their name and what their score is, what their current spice level is. And then I need to be able to control who's got points, what's the spice level. I need to be able to choose questions and categories and all that stuff.

And so it's all of that is connected as one big app that's running as a, a kind of a multi-screen thing that I built using it's a convex is my database because it's got a real time piece built into it. And then I use X state, which is a state machine library, which, um,

State machines are kind of a way of turning flow charts into logic and code, which is really, really nice when you've got something that complex. But that allows me, as the game show is running, when somebody spins the wheel, I hit the button for the category, and that updates everything at once. And when somebody's got a question right, I get to hit the button that they got it right, and that updates their score and changes the question and updates what Mark sees on his tablet so he knows what the line is or what the answer is. So it helps us kind of keep everything flowing without having –

cue cards or a lot of automation. It, uh, it's just enough automation to, to allow us to be flexible. That's awesome. So like how many people are actually like in the proverbial control room when the show is going on? Is it for the, for the score part? It's just me. Um, but we have a crew of 12 people that keep the show running, um,

In addition to the on-screen folks. Okay. So that might be producers that are getting the guests, coordinating all that? Yeah. So we have Annie Sexton as the producer who is in charge of – she's the one running food out and making sure people are taking their spicy bites. And then we've got our camera operators. We've got our sound person. We've got somebody doing makeup. We've got somebody who – they're called the gaffer. They run the lights.

We've got somebody who's kind of on stage doing whatever needs to be done. They're called the production assistant. So there's people running all over, making sure that the wheels stay on as we go. Awesome. And the name of the show is Leet Heat, like Leet being like a short form of elite. Like Leet Code, kind of. Yeah, like L-E-E-T, heat. So the goal, the original idea was like the joke that we made was let's put these developers through the worst tech interview of their lives. Oh, yeah.

So if they get answers wrong, they have to eat spicy bites. And every time it's wrong, the spice level gets higher. So it's very, um, it's, you know, web dev trivia, a lot of, a lot of knowledge, a lot of fun because we, we jump between a bunch of categories and also you get to see, you know, whether or not a developer you've seen on Twitter can handle a very, very spicy hot sauce. Yeah. Yeah. Well, uh, I mean like hot sauce is no joke. Uh, my brother made the mistake. Uh, we call it a mistake cause if you do it more than once, it's,

If you do it once, it's a mistake. But if you do it twice, it's a tradition. And my brother decided to get like this hot ones box with all the sauce. And some of them tasted really good. And once you get really high, you can't really taste anything. You just – once you get to the 10th one. So I have a little bit of experience with hot sauce and, of course, like –

I can only imagine how that changes that enemy because it's like getting slapped in the face or something. It's just like, whoa, what's going on? It is pretty funny when somebody gets a high enough spice level, you can sort of see they start to dissociate. And so you can see that they think they have an internal monologue, but they're just sort of chattering it.

And then we start asking them tech questions. So it's a lot of fun. Yeah, and a lot of questions about databases, a lot of questions about accessibility. Yeah. A lot of front-end development, and then also a lot of architecture, like DevOps-type questions. We wanted to hit real full-stack, right? And the goal for that is that...

Nobody knows all of this stuff, right? And it's not fun to watch a show where everybody gets every answer right. So we wanted to put the devs in a position where if you are a CSS accessibility front-end specialist, you're going to have a great time in those categories. And then when we get to authentication, maybe you're cooked.

And vice versa for somebody who's very strong in the back end. When we get into the accessibility questions, they probably don't know a lot of those answers. So it's a good reminder that no matter how much of an expert you are, web dev is a big place, and there's probably a lot of stuff still to learn. And we've got folks who are accessibility leads at Google and...

And, you know, like some of the folks were the senior engineers at Netflix and they're still, you know, they're killing it in the categories that they're experts in. And then they end up eating a lot of hot sauce in the categories.

Nice. Yeah. I mean, I guess that's always been the case with like Jeopardy and stuff like that. Like there's always been like the historian on there, the history professor who's got like this great knowledge of like world history and stuff like that. But the moment that it's like sports, they're just like, oh, yeah. Yeah. You can't know everything. So it's fun to find out where the edges of your knowledge are.

Yeah. Well, I want to talk about those edges of knowledge a little bit because you have a very non-traditional path into tech. My understanding is you did not

finish college. You like dropped out after like a semester or something like that. I did. Yeah. And yet you've worked in like hardcore, you know, engineering type roles at like big tech companies like IBM. Uh, you, you worked in a lot of different roles at Netlify, which is one of the big kind of like tech infrastructure startups, uh, to emerge over the past 10, 12 years. Uh, so, so you've kind of like run the gamut and, and you've worked like a ton of different types of roles, right? Tech.

Yeah. So I mean, I got my start out of necessity. I was a musician and we didn't have any money. We weren't a very good band, but we were touring constantly. So we needed merch. We needed tour posters. We needed a website. We needed to be able to post our music online. We had a MySpace page that we wanted to customize.

we didn't have money to hire somebody. So I just decided I'd figure it out. And I sat down and I started kind of tinkering and started to get my, get a feel for how it worked. And it was fun for me. So I just, I was like, well, maybe I could make it so that the band could make tour updates. And I learned PHP in my sequel. And then I was like, maybe I could figure out how to like post our music in a way nobody could download. So I learned flash and action, action script.

And then I, I just kind of kept going and I probably rebuilt that band website 14, 15 times because it gave me something to do. And, but you know, we had eight hour drives between shows. So I just sit and tinker on the, in the van. And, um, when the band broke up, uh,

I just, I kind of looked around. I was like, oh my God, wait, I built an entire skillset. I was basically running an agency with a single client, which was my band. I'd learned how to design. I'd learned how to book tours. I learned how to haggle and negotiate and do sales. I was like, oh wait, I think I actually learned a skillset here. Um, and so then I was able to, to take that and I ran an agency for a really long time. I burned out super hard there. And then I ended up working at IBM. I worked at Netlify, worked at Gatsby, and now I'm out on my own doing my, my thing at CodeTV. Yeah.

Talk about agency life a little bit because a lot of people may not understand what exactly that entails and how the skill sets from being like in a band and basically also being kind of like the de facto touring manager just because like, you know, lack of money is the mother of all in this industry.

Right. Yeah. I mean, I, so I, when the band broke up, I started taking some client work. I had a friend who was a personal trainer and I built him a website and that kind of got me on the map with some other folks who are personal trainers. She was like, Hey, could you do one of those for me? And so I was able to do a little bit of work and I, what I thought was I was going to do this a little bit and then I was going to take a full time job.

And then I started talking to a company in Montana where I was living at the time. And they were like, yeah, we'll hire you as a web designer. The max salary – or we'll hire you at $30,000 a year. And this was in 2007. So it wasn't like –

It wasn't nothing Montana. The cost of living in Montana is pretty low, but it also wasn't very high. It felt like a, it felt like a, not a lot of money. And I was like, okay, can I, can I do better than that? I asked him, I was like, what's the ceiling? Like if I stay here and I get raises, like what's the highest I could go? And they said 36. I was like, that just doesn't feel like a lot of room to grow.

And then I, I, at the same time, serendipitously, one of my initial clients came back and they said, Hey, we've got this idea where we want to build a lot of websites for our clientele. They were a talent management company and we'll put you on $3,000 a month retainer. If you will build the websites for these, for our talent. And I said, okay, that's $36,000 a year.

And it was only a three-month contract. But I was like, you know what? I bet I can figure this out. And so I decided to take a bet on myself. And what it ended up being is when you do agency work, there's the part that I knew about. I knew I was going to be building websites.

But the part that I wasn't thinking about is that you're also managing your own time. You're also managing client expectations. You're defining project scopes. You're figuring out how to make sure everybody's aligned on deliverables. And then you're also in charge of things like communication. You've got to send check-in emails and stuff.

set deadlines and make sure that communication goes out if you're going to miss a deadline or if you're ahead of schedule. And I had to go get new clients. So now I'm in sales and I'm doing all of these different things. And what was really similar between being in a band and doing this agency work was the same thing is true if you're in a band. You have to go get shows. You have to talk to

like the high schoolers in that town to see if they'll hang up posters so that the kids will come to your show. You have to make sure that the local radio gets a copy of your demo in case they want to play, like here's a band coming to town. And all of this was the same, you know, it's outreach, it's organization, it's setting deadlines. I had to make sure the band showed up on time. I had to work back from when we had to be loading in at the venue to like what time we had to leave in the morning and make sure that the van was fueled up and ready to go on the road. And so all of these logistical skills, um,

weren't one-to-one translations, but they were pretty dang close to what I ended up doing when I was in the agency. And so it felt like a pretty natural thing. But the unfortunate side of running an agency is that if you're not good at hiring or delegating, you end up doing everything and you end up not having time to do the things that you enjoy. So the only thing I knew how to hire for was other developers because that was the thing I was good at.

And so I ended up hiring great contractor developers to do the dev and design work. And then the only thing I got to do was sales and admin and management and invoicing and all the stuff that I didn't really like because I didn't know how to hire help for those things. And as a result, I ended up really like hating that job. I didn't enjoy, I didn't get to do the parts I enjoyed. I just got to watch other people have fun. And then I was doing all this work that was really not, not,

what gives me energy, right? Like it's not the kind of work that when I do it, I'm like, yeah, let's do more. Um, so I kind of found myself just, you know, almost 10 years in just so burned out because I had been doing stuff that I didn't enjoy for the last six years. And, and yeah, I was working 90 hour weeks, um,

Still hadn't figured out how to charge properly. So I was, you know, I was maybe making 60 grand a year, which was way better than the 36 I would have been kept at in that web agency job. But for the amount of work I was doing, I was actually making less. Like if I'd been working a 40 hour week and making the equivalent amount of money, I would have been making about 30 grand a year. So the trade-offs didn't feel right. I felt like I was off kilter and it led to, at one point I was so stressed out that like my beard started falling out in clumps. Like it turned white, fell out. I had bald patches for a few years.

Um, and I had to, to sort of work through that. But, um, yeah, like agency life is one of those things that it, it will teach you how to delegate or it will get you out of agency life really, really fast. Yeah.

Yeah. Well, I mean, I can relate to a lot of the stuff because I do like our invoicing and like all our HR and like all that stuff. Just because like I'm very proud. Yeah. You know, we run a charity, a 501c3, and we have to report like what proportion are we spending on like fundraising and administrative and stuff like that. And it's really just me doing the fundraising and administrative and then everything else is programs. Right. And I'm very proud of that efficiency, but it does come with the cost of

Me having to sit down like yesterday was the first day of the month and do like payroll and go through and like make sure all the different transactions cleared and double check all the amounts and everything. And yeah, like and a whole bunch of other stuff like sending invoices like we're working with different organizations on courses that they provide grants to create Linux Foundation and stuff like that. And we have to, you know, like.

Track, set deadlines, do all those things you mentioned. I mean, that kind of comes with being an entrepreneur, and I guess it also comes with running an agency, which is really just an entrepreneurship. Yeah, a different flavor of entrepreneurship. Yeah, because you're basically, the way I understand agency life is it's like being a freelance developer, but you've scaled up. Exactly. And now you have a layer beneath you of developers who are working, and you're helping delegate. You're like the load balancer. Yeah.

Exactly. And, and you know, what I had thought I was doing was, Oh, I'm going to have lots of clients and that means I'm going to be building all the time. And, and because I didn't know what I was getting into and because I didn't proactively find people to handle the stuff that, that I didn't want to do, all the things I thought I would enjoy, like the building ended up being the only things I knew how to delegate. So I kind of accidentally built myself out of a job and ended up having a job I didn't want. Yeah.

Yeah. Suffering from success is another way to think about it. Like you're, you're, you're just so efficient at delegating that like, and you, and finding good devs, it's a good problem to have, but at the same time, I'm not trying to trivialize the burnout that you felt. Well, yeah. And it's, it's definitely one of those things. It's like, it, it teaches you as you're, as you're trying to build and grow something that, you know, the, the hard, like it's easy to delegate things you understand. And, you know, I know how to check the work of a developer because I could do that job.

I don't really know how to do accounting. And so if I hire someone to do that work, I don't have a good way of verifying whether or not they've done a good job, which makes me really nervous, which makes me want to like, well, if I'm not going to know how to do it, I might as well try to do it myself, which is absolutely the wrong instinct. But that's the instinct I have as somebody who's always just figured things out myself. And, and it just led to me being in this position of always being out of my depth and

And I think that Sarah Drasner, who is a former boss of mine, good friend, and now is the executive – like senior director of web at Google, like oversees a whole lot of the infrastructure of the web. She once said about burnout that burnout isn't because you work too many hours. It's because you spent too much time in opposition of what your goals are.

And I think about work like that a lot. And it's why I burned out when I was in management. It's why I burned out in the agency. It's because what my heart wants is to be out there building stuff and sharing it. That's what really gives me energy. It's the thing that I get most excited about. And when I get myself into management or admin or owner roles,

If I'm not careful, the thing that ends up happening is I get to tell people about fun projects, but I don't get to do the fun project. I'm not a builder anymore. I'm a, as you said, like a kind of a flight controller, a load balancer. And that isn't a bad job, but it's not the right job for me. And because I wasn't proactively seeking the person who could be the load balancer so that I could be the builder, I found myself constantly doing work that I was wishing I was doing other work. And I think that's the formula for burnout.

Yeah. Well, I'm thrilled that you didn't burn out and that you recognize the signs. I mean, like physically manifesting and having a patchy beard and stuff like that and probably feeling terrible all the time. I'm glad that you were able to recover because I've met lots of people who've gone into kind of like a perma-burn scenario where they just go farm goats. Essentially, that's the old joke about a software engineer. What do you call a software engineer who just gets one too many vague –

stack traces. There's no like that. Uh, server errors. They just go phone codes. Um, and yeah, like I'm glad you're hanging in there and still fighting a good fight. So at what point, like, so agency life, uh,

Not working out for you. Like, obviously, as a lifestyle. But it's working out. It's successful. But you want to do something else. Walk us through, like, the progression from there. I mean, you mentioned Sarah Drasner. She's a huge hero of mine. And I'm hoping to have her on the podcast in the future. Yeah. Yeah. So I, in the agency, this was 2005.

2013, something like that. I had started, you know, I was losing my hair. I was, I was barely sleeping. I was working way too many hours and I realized that something needed to change. So I told, uh, my partners, I had, I'd brought in this one developer that I've been working with constantly. And I was like, listen,

I think it's time. I think I got to get out of this and I want to sell the agency. And he was willing to purchase my interest. And when I say sell, I did not have an exit. I was basically able to walk away from bills. And that was what I wanted. I wanted to not owe anything to

on this company. And so that was what I ended up doing. I mean, a lot of people would still list that as an exit. To me, that was a win. Like it was a huge win because it acquired 20. Yeah. Well, right. It was through some creative LinkedIn listing. I probably could have said that, but,

But to me, the win was that I got my time back. And so I had one client that I really liked and they wanted me to be their in-house R&D branch. And so they offered me at the time the best contract I'd ever seen. It was $100,000 a year.

for me to go and be like internal R and D on contract for this company. And it was also remote. So I, I was super burned out. I'd actually like the way that I dealt with this at first is I just went to Alaska. There was no phone service. There was no internet. Like it took me 45 minutes to download a fishing license. Like that's how good the connectivity was there. And I just was like off the grid. I was on an Island called, uh,

It was off Thorn Bay, which is – it's not even accessible by road. You have to take a seaplane to get there, right? I was out in the middle of nowhere. And –

That disconnect helped me realize that what I really wanted was to reconnect with this idea of just building stuff. And so when I came back, I talked to this company and they put me on this contract and I was able to go spend a couple years. At the time, everybody was calling it digital nomadism. I really don't like that term because I feel like it got co-opted by a certain variety of people.

content creator that is not the type that I want to be associated with, but I...

Yeah, yeah. But I spent a couple years living out of a suitcase. My now wife, then partner, she and I were going around just kind of living in a place for as long as a visa would allow us. So we were in Thailand. We were in Croatia. We were in Slovenia. It was fabulous. What a great two years of my life. And while we were doing that, I was working for this company doing their internal R&D. And it was amazing.

And also I started to have a crisis in the opposite direction because this contract didn't ask very much of me. And it was like champagne problems. I fully acknowledge that, but I wasn't busy enough. Like they didn't have enough for me to do. So I had a lot of idle time and that idle time. Yeah. Like when, when you lucky my, my brain is not the kind of brain that should sit idle because I, I started to think about it as like, okay, well,

What is my purpose? I got real existential. I was like, if I'm here and I am working this job that pays me more than enough money, that gives me, has virtually zero expectations. I'm, I'm doing interesting work, probably takes me 10 to 15 to maybe 30 hours a week max to do this job. And they are not, I'm asking for more work and they're saying, Hey, don't worry about it. Just chill out. Right. It was a dream job. It was perfect.

But if that's that, and I'm, I think I was 27 at the time. It's like, why am I here? Why do I exist? Like, what is the point if this is what I'm doing?

And I started to really spin out on like, okay, well, what's the meaning of life if like this is it? Am I just going to coast for 60 more years as this? And like I could have, but I needed to find something to care about, something that was important to me. And I just found myself kind of sitting in this position of like I need to find that thing. What's that thing? And –

I was doing a little bit of teaching. I had like made a course on like how I was doing all the work to try to find out what my thing was. And my friend and I were both had educational backgrounds. So we were like, Hey, let's, let's make a course about how we're doing this. And so we kind of put together the materials that we were using as something that other people could use, did that launch. That was good, but I didn't want to be like a course seller. I didn't want that to be my job. So I was like, okay, what? So I liked that, but how can I take the elements that I liked of that and like bring back some of the building stuff that I liked and,

And eventually what I landed on is I just want to build stuff. And I want to build stuff in a way that is challenging but not all-consuming so that I still have time for hobbies but not so much time that I feel like my job is effectively – if they stopped – if they fired me, they would not even notice, which is how I felt about this contract that I was on. Yeah. I mean it's important to point out that the first version of The Matrix was a utopia and the human brains couldn't take it. So they had to introduce this – Yeah. The office –

Style existence. We have to have a reason to exist, right? And I think that if we're not striving towards something, it feels too unmoored. Like it's untethered. We got to have something to care about. And so I realized that the thing I cared about was I really like being able to pursue things that are hard. Yeah.

And I needed something to be challenging for me to feel satisfied. So what I landed on was I wanted to go in and see how far I could go in a direction I'd never been in, which was big companies. So I started shopping around. I was like, okay, I want to go work at a company that I'm not in charge of. This was sort of the dream. And I...

I knew a guy from a conference. This is actually something we can talk about in a minute. Oh yeah. I'm all about talking about conferences. I met this guy at a conference. We were just like conference buddies and every year we'd see each other, we'd hang out and he had ended up being a manager at IBM. Like he'd, he'd kind of gotten that job years later. And so I emailed him, I was like, Hey, I'm kind of starting to look around for, for companies. Do you know anybody who's hiring anybody that I should reach out to? And he was like, as luck would have it, I'm hiring.

what are you looking for? And it turned out he was hiring for like a senior front end person. And I was like, oh, that's actually my job. And he was like, great. Why don't you come interview? So I ended up getting a job at IBM on his team. Robin Cannon is his name. He's great. And we sort of accidentally put me in this perfect role for me where I walked into a very mature JavaScript app company.

at IBM that was across like 30 teams. And they had just shifted from a monolithic Java app to a microservices architecture, but they hadn't finished it, right? They'd done the micro monolith where they basically create 32 instances of the monolithic app and each team gets their own instance of the monolith. And they're like, okay, now you can do whatever you want with it. But what most teams had done is just keep the monolith. So they were just running...

lots and lots and lots of parallel software and duplicate implementations and things were drifting, getting weird. And this is the problem I love. I love these types of problems. So I immediately got stuck in and I was like, okay, let's find the worst piece of UI in the app. And we found this billing dashboard that took like over a minute to load. And I was like, let's do this. Let's dig in. And so we started a re-architecture project. We cleaned out some of the old stuff because they had like...

loading JQuery, loading React. So there was like three levels of loading spinners and stuff that wasn't hard to fix. But if your job isn't to fix it, you just sort of solve the immediate problem and move on, which is what I think a lot of folks end up doing through no fault of their own. It's just that's how the tickets get handed out.

And so my ticket was fix this dashboard. So I got the permission to dig in and really clean this out. So I stripped out jQuery. I stripped out Backbone. I actually stripped out the whole monolith. And we built this thin SPA layer on top, which is what they were trying to build. But nobody had ever had the time to really re-architect it. And I – SPA is single-page application. Single-page application, yeah. So kind of like a client-side only that talked to the monolith through API – like an API contract. Yeah.

And this is where most people talk – like a monolith is like all the code is in one box, right? Right. And then microservices, what will often end up happening is they slice that monolith vertically. Right.

And what I started advocating for was the APIs were really the brains of this application. So let's slice those into microservices, but the UI shouldn't be part of those microservices. The UI should actually be a thin layer on top that spans the entire app that talks to these APIs through the API contract. This later got popularized as Jamstack. I didn't realize that's what I was doing at the time, but that was the concept that I was working on.

Yeah, spontaneous independent innovation. Exactly, right? Yeah, that probably happened a lot of places, but... It did, yeah. Yeah, Netlify, I guess, they coined the term Jamstack. They coined the term, yeah. Matt Billman coined the term. JavaScript APIs and markup. Yeah, that was the original idea. It was like JavaScript APIs and markdown. And the ultimate concept was like decouple your front end from the logic of your apps through an API contract. And so your front ends don't have authentication, don't have...

They don't have business logic. You're just shipping something that says, hey, API, give me the thing I need. And it does the auth and the business logic. It's so common now that like it doesn't even make sense to advocate for JAMstack anymore. It's just kind of the way we build. Yeah, exactly. But at the time, this was pretty revolutionary. So I remember I shipped like this prehistoric JAMstack version inside of IBM. And this page went from loading in 60 seconds to loading in like a second and a half.

And it was one of those moments where the leadership part of this particular corner of leadership at IBM kind of screeched to a halt and they were like, what is this? How did you do this? What is this? And I started going on these internal educational tours to show people what we had done, why it was interesting, how it could help, how we could adopt this across the company. And that was where I really realized that I love this sharing and the educational and the storytelling part. Because you're not going to change somebody's mind by saying,

Here is good code, right? You have to tell them how they fit into that story, how this good code will impact their lives. What do they get? Do they get to go home early? Do they get to get page less often? Do they get to work on more interesting stuff because they're not putting out fires? Those types of stories are what gets somebody to adopt code. So I was doing that internally at IBM and eventually the, the IBM is a very large company. There's over 400,000 people working in the company.

And as you can imagine, there's a certain layer that you hit where it just gets very, very bureaucratic. And so I went from building to mostly talking about building again. I was in a lot of meetings. A lot of stuff that I was doing was discussion. Suffering from success. You're too good at writing. So what my wife always says, you would be just fine in any of these companies if you could just let a problem be somebody else's problem. And I was like, no, but that's what I can't do. Yeah.

Well, like I, I think it's admirable that you have that compulsion to go and improve things. And, uh, I think a lot of developers, probably a lot of people listening to this, like they, they're not content to just like, you know, keep their head down and right. Busy or, or get good at something and just be like, cool. This is like, I am the, you know, uh,

I manage this endpoint and that's what I do. And like anything outside of the scope, you'll have to go talk to a different department. Right. Naturally kind of like they're like trees shooting out tons of roots and just trying to like get more and more robust. And I feel like that is a tree would be like probably a good analogy for you because I mean like trees can't help but grow. Right. Biological imperative. Yeah. Yeah.

No, I agree. And so, you know, a lot of what I was working on was, was, you know, teaching people, but it was all internal. It was all, um, an internal tour of meeting with other teams and, and trying to do some, uh, internal education stuff. And so when I, I started to get frustrated with the bureaucracy and, and kind of realized that I'd gone as far as I could go without becoming a politician. Um,

I started looking around. And a politician in this context, not a literal politician, but basically somebody who politics within a giant organization. Yeah, exactly. Like, yeah, I guess I should rephrase that. So what I found myself having to do was like I'd run into a couple teams that were really, really concerned about the impact that my changes would have on their relevance in the company. They'd built a lot of internal systems and they'd done all of this stuff to sort of –

control the chaos of everybody working on, on subpar repos. And the changes that I was proposing would remove a lot of what they had built in favor of, of,

just automated checks. And they were, they were worried that I was trying to get rid of them. And, and so I was doing, I realized that my job was about to become, I have to go and sit down with these people and convince them that I don't want to take their jobs, that I want to work with them, that I'm trying to, you know, give them opportunities to work on things that they're interested in instead of getting paged every three hours, which was happening. Um,

And they, for some reason, just— By the way, getting paged is basically having somebody say, hey, we need you to come and do this. It's not like a literal pager in Twitter. Yeah. Well, at that time, you did have to carry the pager. Oh, you actually carried a physical pager? Like there's that company, PagerDuty, and I always felt like, oh, that's a cute anachronism. So originally, PagerDuty was like you would pass around a physical pager.

Later, PagerDuty became a company that handles notifying people based on who's on call for out-of-hours fixes. And now companies typically do it through something like Slack. But at IBM, it was very much like the people that worked on those teams, they just had a pager with them and it would go off. They'd be like, oh, I got to go fix this. Yeah.

Um, but so when I, when I realized that, you know, I, I was getting more into a sort of management or, or almost like a business consultant role inside of IBM where I was talking to other teams that I had no influence over. I, well, I only hope to have influence. I had no authority, no control, no, no real sway. And I had to, I was like, you know, this isn't,

Like, I feel like I'm convincing somebody to do something that I think is good, but they think I'm out to get them. And it's very adversarial. It's very like...

I don't feel happy at the end of the day. I feel like I'm like fighting this very weird political battle where they, they think I'm trying to take something. I'm trying to give something. I don't know how to get them to understand. They think I'm trying to, you know, be some young hotshot who just wants to touch stuff because I, because I came in and it's not my code, which is also, you know, fair. Like there's, I'm sure there were things I was doing that were, that were part of the problem here. But my, my decision ultimately was I wanted to go somewhere that,

With fewer people. So being individual, being in the agency with a small network of contractors felt too small. IBM felt too big. I was kind of looking for the Goldilocks situation of just right. I want to go big. It's not that big. Yeah. So yeah, exactly. Goldilocks. You're trying to find the Goldilocks zone where it's just the right size. The soup is not too hot. It's not too cold. It's perfect. Exactly. And so I joined Gatsby, which Gatsby was a...

Front-end framework, it was React-based. It was really early on the GraphQL trend, and GraphQL was a way of accessing data. It's still reasonably popular today, but not nearly like it was 10 years ago. And the way that Gatsby worked was it basically everything loaded into a GraphQL layer, which meant that everywhere in your site you had access to your data. Stuff that feels pretty common in modern frameworks today, but at the time was pretty revolutionary.

They had just gotten funding. They were one of the frameworks that got funded early on, the venture capital game, when dev tools getting venture funding was still somewhat novel. Yeah, or anybody getting venture funding that doesn't have like .ai. Well, yeah, that whole shift.

But so before the AI shift, there was a huge shift to fund web dev tooling, basically. Business for developers, like B2D was the acronym. Yes. You were trying to get people to do your SaaS model, like we mentioned PagerDuty. I mean, you buy seats, essentially, like...

how many people are going to be on your team. Okay. That's 30 bucks a month. Right. And if you're a giant organization like IBM, you just maybe have your own internal tool, but if you're millions of millions of dollars, yeah. Yeah. So, so I joined IBM very, or sorry, I joined Gatsby very early. I think I was employee number somewhere between five and 10. I don't remember the exact number. Um, but they hired me without a job title, which was in retrospect should have been a warning, but, uh,

At the time, it just seemed really exciting. They were like, yeah, you're obviously very good at this. We want you to come in and do the thing that you think is most important for the company. And I came in and I realized that the thing that really needed to be done was taking care of the community because Gatsby was completely built on open source, on open source contributions, on people in the community telling stories about Gatsby, using it, building demos. And we didn't really have any mechanisms inside the company for like

nurturing that, taking care of the people in the community. So I came in and I built out some GitHub automation so that people could get a t-shirt when they submitted a PR. We invited them to be part of the maintainers org so they'd have access to private discussions on GitHub and have a little extra access. Started organizing some meetings and different ways to try to make people feel included. And that ultimately led to me creating what would become Learn with Jason, where I was like, well, maybe I can live stream stuff to like

multiply my effect. And, um, the, the live streaming stuff ended up being a pair programming show that I still run to this day. We're like 400 and something episodes into it. And that was the seed of me realizing that video was, was super high potential. What is pair programming for those who are unfamiliar with the concept pair program? So the, the way that I'm doing pair programming is I, I basically have, um,

remotely i'm on my computer and then i've got somebody on zoom who's looking at my screen and and we i'll say like hey i want to build a thing you're an expert in that thing can you kind of talk me through how we would do that and then i will build while they sort of explain and coach how things are building um traditionally pair programming would be two people sitting at the same computer kind of solving a problem together and i really really love that style of pair programming

At the time, I was limited. I could only do remote, and remote is just as good. I love remote pair programming. It's a great way to have somebody articulate the way that they think, the things that they understand, and you as the learner have access to directly ask questions as you're learning to get clarification in a way that you can't do if you're reading a text.

like reading the documentation, if you don't get how it works, you kind of have to find somebody to ask. You have to go find the forum or something like that. You can still do it, but it's really nice to have that instant feedback loop. Okay. Why did that just happen though? And then somebody goes, Oh yeah, let's look here. And then you can see how this thing fits together. And it's like, Oh, okay. All right. You just added context. It would have taken me 30 minutes to find in 10 seconds. Yeah. And by the way, this is one of the reasons why I like a lot of people will spend like huge amounts of money going to like different programming programs.

or buying courses or something like that. I think it's a very good use of your money to just pay some computer science student or some dev, pay them a little bit of money to pair program with you and just answer your questions in real time. 100%. I think if you can create opportunities to build with other people,

There's this concept that I love that's – it's called tacit knowledge. Yes. And tacit knowledge is this idea that there are a bunch of things that we do that we don't like consciously know. They're just skills that we picked up. Like when you walk, when you breathe, you're not thinking like, okay, how do I keep my feet underneath me, right? You just sort of learned it so well that you do it without thinking.

But to somebody who doesn't, you know, like to a baby that's learning how to walk, it's a very active experience and they have to watch people doing it to sort of get their, get the idea of how they should be doing it and build up this knowledge. And so the same thing applies with any skill. It's just, it feels different when you're an adult because when you're a baby, you, you expect babies not to know things. But as an adult, you, you're like, well, I'm, I'm smart. I should be able to figure this out. But you still have to like build instincts and understanding. Yeah.

And the best way to do that is to be around someone. This is why the journeyman model, apprenticeship model was such a big thing is you would basically have somebody who wanted to become an expert, follow the expert around and watch them.

And then after weeks or months or even years in certain cases, they would finally have observed enough of what the expert was doing that the expert would say, okay, now you do this. And then they would do it and they would have some understanding of what should happen and they could get coached in what would have been a pair programming way. So if you're a plumber, an electrician, a woodworker, whatever. I mean, this is a huge part of medical education here in the United States. Right. Observation. Residency and like you're going to go and you're going to spend like,

three or four weeks doing pediatric care and basically just shadowing a physician who's already been doing it for a long time and seeing how they interact with the patients, seeing what they look for, you know, like all that stuff, right? Because there's so much tacit knowledge involved in being a physician. And I would imagine the case with like, you know, being an electrician or a plumber and with the software engineer, it's the same thing. And one of the things that I've... Yeah, go ahead. One of the things that I've really noticed with software engineering is that you...

you have like the hard skill. I've, I've read the manual. I understand what the names of the APIs are and I can build a thing. But where the tacit knowledge comes in is when you sit next to somebody who's built this thing a thousand times and you watch them write it and they reach for a for loop versus mapping, or they write it as a like functionally versus class-based or they, you know, they'll, they'll do a, they always do a thing and you go, wait a minute,

I was always told that it was supposed to be like this, or I've never seen anybody do it like this. Why did you, why did you make that choice? And then they'll pull out some story like, Oh, when I was working on this project, this thing happened that had a weird memory leak. And so that's why we don't use this approach because there's this weird edge case that you'll never know unless you've experienced it or somebody like me tells you.

Or they'll show you something like an alias or a shortcut or just some little trick that they do, the way they organize their editor. Like one of the ones that I learned is I organized the file tree in my code editor on the right-hand side of the screen.

Which when people see it at first, they go, why would you do that? That's terrible. But the reason I do it is because then when you open it and collapse it, the code on your screen doesn't jump because it's always left aligned. Right. A little thing that at the time when I first saw it, I was like, oh, why would you do that? And then they explained and then I tried it and I was like, oh, this is better. And now it's just like a tiny little quality of life thing that improved the way that things work. And it's all tacit knowledge exchange. I learned that by watching somebody else work.

I have an anecdote about task. Yeah, please. Uh, so, so like that, that kind of exchange, he said, like just asking about why people are doing certain things and we're going to talk about conferences in a little bit. That's something you and me are really big on encouraging people to go to events and, and just spend a lot of time talking to other devs. Uh, and I mean, you could definitely argue that's like one of the raison d'etre for code TV, right? The reason for being, uh, is, is to see people in like, uh,

the proverbial meta of who like people like learning, uh, working as devs and like watching them work and hearing kind of the thoughts that occur to them and watching them choose their tools and solve problems and stuff. Right. So this is an anecdote I was talking with this pilot, uh, and I don't know anything about aviation and I'm not really that interested in like dying young in an airplane crash, like, you know, while you post or something like that. But, um,

This pilot, he was an amateur pilot, just somebody learning how to fly, working as an accountant or something like that. And he said that one day he was flying and something just started going wrong and the plane started moving in a very weird way and he was losing control of the plane. And he was freaking out because he was about to die. And all these thoughts were racing through his head. And then...

One of those thoughts was this conversation that he'd had like several years before just drinking like, you know, office burner coffee with some other person at his company who was also a pilot talking about how like, well, if you ever get in this type of situation, this might be the cause. And this is what you need to do. And like,

That random encounter from years ago, a seemingly casual just swapping stories about flying and stuff. People love sharing stories. I think it's an integral part of the human experience. We have this instinct, just like trees have the instinct to continue growing and absorbing more water and nutrients from the soil and stuff. Humans do the same thing with knowledge because I think we do, at a subconscious level, realize that it is important to our survival and the survival of our…

you know, families and stuff to be doing this. But, but he thought back to that moment and then he realized from that conversation, like he remembered enough about it that he was like, Oh, maybe I should try that. He was able to get himself out of the spin and survive. So it was literally a matter of life or death. And you were to look back at that. They just felt like a throwaway conversation. Just, just killing time in between, uh, you know, like going back, back to work during your break. This is one of those things that, you know, it's so hard to communicate the value of,

of the casual discussion, the casual observation of other people in your space. But when I was at IBM, we solved massive problems in the company by getting a few people from different teams to have lunch together.

Because through the course of conversation, naturally over the day, they would bring up, oh man, we're just really struggling with this thing. And somebody go, wait a minute, we just, we were just looking at that and we kind of tried this thing and they would, they suddenly dot start connecting. And the next thing you know, this thing that would have required a massive cross-functional effort and buy-in from all these VPs and it just never would have happened.

These few engineers sitting around solved their problem. They'd send each other a couple Slack messages. They would implement the fixes, and it just went away, right? Because they were in the right place having casual conversations, observing how each other were working. Similarly, that's, you know, like you said, that's the whole point behind CodeTV is I know that not everybody has access to go sit with a senior engineer. And I know that a lot of senior engineers are the most senior person on their team.

If you're in that situation, how do you get more exposure to more stuff? And so my goal with originally Learn with Jason and now with Web Dev Challenge and Elite Heat and everything else we're making on Code TV is can we create a space where senior engineers are going to do things differently?

senior and junior engineers, people have all experienced levels on the show, but can we, can we have them do things and sort of talk through their thought process? So anybody can be the person who is just sitting in the room and observing with them. And hopefully they walk away having learned something, having thought differently about how they could approach a problem. Maybe they understand a new, a new avenue that's open to them when they're using a tool. Like, is it as good as being in person? No, but is it pretty close? I think so. And, and

For folks who don't have the option of going and hanging out in an office, I think it's the best option out there. Yeah. Awesome. 100% agreed. I've really enjoyed watching and kind of like steeping in the meta of software development. It's kind of like...

being part of like a, a mini hackathon. And yeah, you're just like watching it transpire in front of you. But, uh, you're, you're like, kind of like, it's weird. Like the way your brain process. Okay. They've encountered this sort of problem. They're probably going to do this. You like start jumping to like what predicting what's going to happen. It's like, Oh, it's different. And one of the things I love about code TV is, uh,

Everywhere I go, if there's a TV on, it's on home improvement type channels. It's like contractors that are like fixer uppers, like fixing houses, or it's food. Food seems to be huge. It's chefs competing in these reality style TV shows or like kitchen nightmares type stuff, stuff like that. And it's just like so much...

anecdotal kind of like input that you just, you're kind of like basking in it. Right. You're, you're, what's the, what's the word you're marinating in it. Yeah. Since I'm using cooking or you're, you're just steeping yourself in all these different things that could transpire and all. And it's building up to this kind of like,

of things that can happen in software development and stuff like that. So it's really great for kind of contextualizing a lot of that. And if you go on free code camp, you work through the curriculum. It's just like the raw skills. Yeah. Like we're explaining concepts and we're, we're giving you tons of programming practice and all that stuff, but we don't really provide any sort of like actual, uh, I guess kind of like war stories type experience. I mean, the closest you're going to get to that on free cooking is probably just listening to this podcast. Um,

And I do think podcasts are an excellent source. But when you have video and you have people actually interacting and you've got this unscripted show where you kind of contrive these scenarios, like you have four hours to build this project. And it's got to do X and it's got to do Y and it's got to do Z. And at the end of that, we're going to see who did the best job. You're on the spot. People have to work quickly. They have to make trade-offs.

Yeah, I think that's awesome. I think, I mean, you bring it up in a good way where I think there's this cliche that we hear all the time that you become the sum of the five people you spend the most time with. And I think that that is true to an extent, but I would say that the underlying meaning behind that is you become whatever you bury yourself in.

If you spend all of your time looking at a certain subject, you are going to start to shift in that direction. And the thing that's tricky is that you can't just do one of these things. You couldn't just –

hang out with other developers and never build anything and become a developer. You can't just build things and never share it or never show anybody or never deliver it and expect to become a great developer. And you can't just read documentation and expect to suddenly become great, right? You have to do a combination of, of,

active study, like what I would call deliberate practice. You have to do the sort of environmental immersion and you have to do the application of it, the practical application. And in any situation, if you're going to be the world-class musician, you need to do

practice, deliberate practice, sit down, read the notes, really go through your scales, but you also have to perform. You have to get comfortable on stage. You have to be able to bring some emotion into that performance. And you probably want to hang out with other musicians who are going to help you get connections and figure out where you, you know, where you can improve. You can see things that they're good at that you weren't thinking about. Um,

Software is exactly the same. Like if you only go out and read tutorials, you're going to have a lot of like potential knowledge but then you're never applying it. You're never testing it by having conversations about this stuff. If you only talk about this stuff, you never build up the knowledge and you haven't built up the practice. So you kind of have to –

And if you only build, you kind of end up at this local maximum of what you can figure out on your own and then you can't like expand beyond that. And the way that I think about it is that, you know, you ideally what you do is you're in a perfect situation where you can find a bunch of developers who are super talented and ready to hang out and you just go be part of that community. The absolute best place you could be is just go hang out in a room full of developers and build stuff and good things are going to happen.

That's how I learned music. I found great musicians who were ready to play and they let me hang out with them. And I got so much better at music in such a short time because I, it was all I did. It was my whole life was like, wake up in a room full of musicians, play music all day, go to sleep in a room full of musicians. Like that was it. Right. Um,

I didn't have that with software. Like when I, when I wanted to learn software, I was the only person that I knew other than my dad, who was like a C engineer and it was not interested in teaching me anything. He, you know, he was working on embedded systems, things I didn't care about. I wanted to work on the web. So I had me and some books and like the W three schools forum. That was what existed at the time that I started learning code.

And like every time I found another developer, I was kind of like getting gatekept out of it. I remember I was talking to a guy who was building websites at the – I was working a pre-press job at a printing press. And I was like, hey, I had a question about Flash. And he just looked at me. He goes, can you tell me what the difference is between cell spacing and cell padding? And I was like, what? That's not – he's like, then you're not ready for Flash.

Like it was just this really bizarre like, you know, testing culture. So that happened to you multiple times? I mean I've had weird situations where people just try to get you to pass some kind of knowledge test before they'll engage with you, right? I mean like that was part of like if you watch the 1990s movie Hackers, which is a very accurate portrayal of software development in the 90s. They would always be like –

You know, they were always trying to like out leap one another. Yeah. Like you're trying to assert your nerd credentials. Yeah. It is absurd. It really is.

Don't do that, pro tip. We don't do that around here. It doesn't make any sense. It's silly. The chest beating. And it may serve some sort of weird tribalism purpose on Savannah. But it doesn't have any real obvious use in the actual contemporary developer ecosystem. That was a big thing that I realized was that, for me at least, it just –

Anytime that I felt myself wanting to test somebody's credentials, I was like, what do I gain from

by making somebody prove what they know. Like it's going to become very obvious whether they do or don't know this stuff within a few minutes of regular conversation. So I should just engage with them like they know, and they're going to out themselves if they're faking it. Right. Charitable. Yeah. Right. Like assume, assume that people are there because they want to be part of the community and assume that even somebody who doesn't know everything is probably still a valuable addition to a community. Cause like I said, when I first went to my first conference,

I made my group of conference friends who at the time we were all early career, no real connections, no real network. We were like the odd people out sitting on the edge of the room saying like, Hey, did you come here alone? Like, what's up? I'm Jason. And you know, 10 years later, all of those people who are my conference friends are now in senior positions, their managers, their directors, their like, these are now people with influence and network. And, and,

Like these careers are really long. And if you're just coming in and you're 20 years old, like you've got 40 years of career ahead of you. And the, the, it takes five to 10 years for somebody to go from junior to senior. And it takes like 15 years for somebody to get to a director level. So if you're making friends today, you can assume that literally everybody you meet today, as long as they don't quit is going to end up being in charge of something.

And that's if you're only going utilitarian. Also just consider it's kind of nice to have a lot of friends. Like one of my favorite things about going to events today is that people I met 20 years ago when I first started out in my career still show up at these events and we see each other once every three years at an event. And when we do, it's like Christmas. It's this person that I came up with. We like each other's posts on LinkedIn and that's about it.

but when we see each other, it's like, Oh my, we got to catch up. Like, let's sit down. We go, you know, we go find a beverage. We sit down somewhere. We talk for three hours about what's, what's new in our lives over the last few years. And it's always a great story, you know, and it's always really fun. And that, you know, that leads to just this incredible amount of career resilience. And it, it like opens up all these doors. I know so many people in this industry, um,

And all of them are people that I would consider somewhere between acquaintance and friend. Because when we see each other, we're friendly, we hang out, we high five, you know, we'll get a coffee together. And then when we part ways, some of them I'll text. You know, I've got friends who I've got a group chat going with that's been going for years and years. And then I've got people who I will only talk to when we see each other in the same place because we, you know, we like each other, but we don't have that much in common.

And that is perfectly acceptable. Like what a great place to be where everywhere you go, you got somebody you can talk to. Right. And every single one of them, if they ask me for something, I'll pass it along. If it's not too big and ask, like if they're like, Hey, I'm looking for my next job. You know, anybody who's looking for this type of person, if I know I'm going to pass them along. And if it's somebody that I ask, like, Hey, I'm working on this new project, would you mind, you know, sharing this around? They do. Right. And it's, it means so much to me to have that sort of network and it's,

No matter how you do this, whether it's through social media, whether it's through your Discord groups, whether it's through groups like Free Code Camp or whatever group you're part of.

If you can get in person, even better. If you can find a local meetup group, if you can find developers, if it's the folks that you work with at your company, whatever it is, but like really finding that opportunity to connect with other people and realizing that like you're going to pick up the tacit knowledge. You're going to pick up friendships. You're going to build resilience in your career. You're going to build these extra connections, get these new perspectives. And all of that leads to you having...

You know, more capabilities, more lateral thinking about how problems can be solved, more connections, more opportunities. Like you kind of can't lose by taking a make as many friends as possible strategy. Yeah. I mean –

You can't have too many friends. You can't have too much tacit knowledge. You can't have too much kind of like secondhand experience. And that's what you're getting when you're having conversations with people. You're broadening your own perspective. Maybe you wouldn't have encountered that sort of thing because you're in a different line of work or you have a different lived experience. But it is very beneficial to be able to empathize with people and understand.

why they're doing what they're doing. And yeah, like you can learn a lot. So tell me a little bit of advice you would give. I'm going to do some role playing. I just have a few quick questions toward the end that I really want to make sure everybody walks away from this, not just understanding, you know, tacit knowledge in the role of that, the role of building relationships, the role of steeping yourself in what I call the meta of software development.

But also I want them to have like some actionable advice that they can walk away with from somebody who's been there and who's gone through kind of the trials and tribulations, the slings and arrows of being a self-taught dev. So first, let's say hypothetically, I'm just going to throw out a scenario. You are working at a grocery store.

And you're checking people out and, uh, or maybe you're bagging groceries or stocking shelves or something like that. I did a lot of that when I was younger. Um, and, uh, you have maybe 20 hours a week that is not accounted for through work, sleep, taking care of your family, all that stuff. Like you had the luxury of 20 hours a week, like, and maybe you have $500 a month. I don't even know if you, let's say $200 a month, $200 a month budget. Uh, what are some things you would do?

to try to, over the next two or three years, put yourself in a position where you could get a job at IBM or get a job at an agency? I mean, the biggest one is build, right? And the easiest way to build is to pick things that you will care enough to complete. So for me, it was I had a band. I needed to finish the band's website. And through building those projects, I was getting practice and I was establishing credibility.

So if I was in a situation where I didn't have that – so like what I do now, for example, is if I've got a thing that I need like the – I wanted to make this game show. Well, the game show needed to run and I didn't have the money to buy production software. So it's like, well, OK, what does it really need to do? And I built the software to make that function.

I needed a way for people to get, uh, to like become supporters of code TV because our model is five bucks a month for, for early access. Okay. Well, I need to be able to collect that five bucks. So I built a subscription thing through Stripe that lets people pay five bucks a month. And, and that I needed to use as a way to, to signify that they had access to watch the videos. Um,

each of those things is a little project in itself. Like figuring out how to take money through Stripe is a couple of weeks of, of like reading docs, practicing, building that thing, figuring out how to do, um, controlled access is, you know, maybe a couple of weeks of, of reading docs and figuring out how those things are figuring out how to fit those two things together, how to like check the subscription to determine the access is maybe another couple of weeks. Right. And each one of those tasks,

is a thing that you can now go show in a job and say, look, I built this thing.

I don't know, this calendar app for my local, you know, I've got kids, they play soccer. I built an app that helps the parents schedule whose turn it is to bring snacks to the soccer games, right? That's a real app that's like actually beneficial. You figured out how to send text messages to the parents to remind them that, hey, today's your day to bring the orange slices, whatever that thing is, right? If you build an app that is useful to you and solves a real problem, you're going to

you've just built your portfolio and you're proving that you can solve real problems with code, which is exactly what a company like IBM wants to see. Like,

When I'm interviewing, when I was a VP at Netlify, I had to hire people all the time. And what I was really curious about wasn't whether or not somebody could recite documentation to me or whether they could solve the algorithm challenges. What I was really interested in was could they talk through how the code that they're writing is getting to an outcome that helps people?

Because that's what like really at the bottom of everything engineering is. It's being told here's the problem and here's the desired outcome. I need you to turn this desired outcome into functioning code. And if you can articulate that through something that you've built, you have proven to me that you can do this job.

Yeah. So to some extent you're creating actual portfolio pieces. Yes. Natively. And it's just easier to follow through on a portfolio piece if you've got a problem you're actually solving. Building a hypothetical is weird because who's your customer? You need to have a customer in order to build something useful. So building another to-do list is good for understanding how a framework works. It's not a good portfolio piece because there's no customer. It's

If you are building something that allows you and your kids to track who's on chore duty, now you have a customer, even if it's a to-do app. And you can articulate, like, why did you build it the way you built it? Who is this for? How is it used? How is it different from a standard to-do app? Functionally, basically the same code. Story-wise, outcome-wise, you're actually telling me, like, how you thought through a real problem and got to a working solution. Yeah. So the biggest thing to do is build, right?

Second biggest would be try to get in the same room as other developers. If you've got $200 in budget, see if you can get to a local meetup, see if you can save up for a couple months and go to a conference twice a year, something like that. Being around other developers and making friends with people in the industry, aside from being able to write the code, is the single biggest thing that you're going to do for your career. Awesome. So build and get in the room with other developers. I'm writing that down because that is very important. Yeah.

And I feel like you're like – obviously, people who hear that advice, they're like, oh, yeah, throwaway advice. But if they actually listen to it in the context of an entire conversation, they get all the tacit knowledge and the reasoning behind it and all that stuff. And this is one of the reasons I advocate for listening to podcasts and not just throwing a podcast into GPT. Hey, summarize this podcast. You get some bullet points. And I don't even like to use bullet points because I feel like devoid of context. Like if you look at the way Amazon does things, they do like the six-pagers.

You can't put bullet points in those. Yeah. You have to write a six-page...

that essentially distills all your thinking and why and all that stuff into like a document that people read that like one thought connects the other and all that stuff. And I think there's a discipline a lot of people lost with, you know, PowerPoints and stuff like that. Like people have been complaining about skills atrophying since they started writing things down and doesn't that affect your memory? You know, but like, like this is just like a common thing. Like, yes, it's, it's one thing to hear, Oh, you should be building stuff. You should get in the room with other developers, but it's another thing to like,

Here you talk about how those two things have had such a profound impact on the course of your career and your development as a person, going from suffering from success in one area to suffering from success in the other, and just continuing to find bigger, bigger challenges. I'll be completely candid. I would never be sitting there at a cushy job and being, you know what I want to do? I want to go work in some giant company.

You know, corporate bureaucracy as a developer and like try to claw my way up. But it's such a cool story the way that you went in and shook things up with your outsider perspective and you rambled – you roused some rabble. I don't know what the verb is. But you pissed off a bunch of people. Well, I think – a thing that I've learned about myself is that I –

My very existential takeaway from my crisis back in 2016, whenever it was, was the thing that matters the most to me is dying without regrets. I took away a very nihilism in a positive way look at life. Yeah.

Ultimately, life is meaningless. There's no point to us being here. There's no external value applied to our lives, which means that in good news, we get to assign the value to our lives. And so to me, the value that I've assigned is that on my deathbed, I want to be looking around and saying,

Nailed that. No regrets, right? I would do it exactly the same way. And so to me, the thing that I think about is what gives me that feeling of like I spent my time well. And I believe very much that the most value I get out of a day is when I have tackled something that was difficult and that expanded my abilities in some small lateral direction.

And I think that's why I went from musician to agency owner to software architect at IBM to startup guy to now I'm at CodeTV. And I basically do like 19 jobs in a trench coat because I spend most of my time in sales, but I do a lot of time building stuff. And then I'm also writing shows. I'm filming things. I'm editing things. I'm still doing design. I'm building websites. I'm all over the place.

And every single one of those things is hard. And every single one of those things is satisfying to me. Like I find value in having done it.

When I find myself in a position where I'm no longer feeling the value of it. So for example, editing videos takes me a really, really long time. I like doing it, but I don't get enough value to justify the cost. So I've hired contractors to help me with editing. Right. Similarly with like some of the other tasks in, in making the videos, like I'm not very, I'm not good at makeup, so I'm not going to be hair and makeup. So I hired a contractor for hair and makeup, all those sorts of things. Like, but I did them all to start. And,

And when I felt like I learned it, I was like, do I want to get really good at this? Or is this something that I'm happy to have somebody else do? And in most cases with, with like parts of the process, it's like, okay, I know how to do it. I'm not very good at it and I don't want to take the time to get really good at it. So I'm going to hire a contractor. Yeah. And that's the shift that I think has saved me from the pit that I fell into with my earlier agency where I would,

I would basically say like, I don't know how to do this and I'm scared of giving it away. So I'm going to, I'm going to like suffer and do it. And somebody else will do the parts that I like. Now I'm asking myself, like, do I care enough to get good at this? Because it is better to let an expert that I can't oversee do this job and observe their output. Cause I can tell whether or not they did a good job when I see the final product. Like if you hire somebody to run lights and you get your video and it's too dark or like everybody's blown out, you're like, Oh, I don't think I'm going to work with that expert again.

Right? Like you can – but you know you're going to make more stuff so you can make a different choice next time. And what I was doing before is I would hold on to everything really close because what if I make a mistake? But those mistakes are – you know you've got something else coming right behind it. So you get to learn from those mistakes and adjust and that allows you to – you're always able to stretch yourself, try something new, be challenged. And for me now, every single day when I go to bed, I'm like, man –

what a day I got to do all this stuff that I've never done before. I'm, I'm working on things that I never thought I'd be able to work on. I, I make TV for a living somehow. Like how I got there from where I started, I truly couldn't directly articulate it. Like I just, I saw something interesting. I was like, what if I tried that? And then it's like, Ooh, maybe do a little more of that. Ooh, that was fun. What if I tried this? And the next thing I know, you know, I'm, I'm basically an executive producer. I have a studio, like all sorts of weird stuff.

You can just kind of chase, chase the things that give you energy and that, that, that make you light up and try not to let go of the things that, that let you light up and, and you're going to have a great career. Like I have, I have no regrets. I'm having so much fun. Yeah. It chased the things that give you energy. I love it. And I mean, it is amazing to think back to you sitting on, you know, a tour van and,

Probably like really one of those really stinky like 70s vans that have been repurposed as like kind of a tour van, which was probably very dangerous if you had the gear. Did you have like the cage to hold the – No, we had like a 15-passenger Ford van. So it was like a four-bench van. Everybody had a bench to sleep on. And then we had a 15-foot trailer that we'd pull behind it. Ah, okay. That's safe. I've heard so many horror stories about gear that like just shifts. Yeah.

Oh yeah. Yeah. Yeah. We, we did that a few times too. Like earlier on where we'd, we'd load up a forerunner with like amps and stuff in the back seats and we were like piled up, you know, on each other's laps in the front seat so that we can make it down. Yeah. Yeah. But, uh, but like, like from you being, I can just imagine you on your laptop in between like,

doing gigs, just sitting on the bus, like learning these skills out of necessity because nobody, somebody on your team needed somebody in your band needed to be able to do this. And you just kind of like took it upon yourself to, you know, working as a dev and then running an agency, then working at a big company, then working at a bunch of small tech startups and now doing what you're doing, running essentially a TV show. I mean, it's a pretty amazing journey and it's,

It all may make sense looking back, but it doesn't necessarily make sense...

Like, like I'm sure if you were to send a time capsule or like some sort of message back to yourself, like you're running a TV station or something like that, that'd be like a really weird, like you probably be like, uh, this has been for somebody else. Well, and I think the other thing too, is if, if you had told me that when I was 19 and in the band, I probably would have taken a different path that would have led me away from where I am now. Like every experience that I had in the middle is what gave me the ability to do what I do today because code TV is

is specifically making TV for developers. And the reason that it works is that I am an engineer. Like if I was trying to make TV for like –

Site reliability engineers, the folks who do hardcore keeping the servers up, handling load, I've never done that job. I couldn't do that. It wouldn't be authentic. It wouldn't resonate. I wouldn't be talking to that audience in the way that I can talk to engineers. And if I hadn't done all the work as a agency runner where I learned how to –

Sell and talk to companies and align what companies want with what we're trying to make and make sure that their goals match the outcomes that we're designing for. If I hadn't learned to do that, there's no way that I'd be able to talk to the companies that I partner with now that make CodeTV possible, right? Because it's funded entirely through viewer and sponsor support.

Like there's no other income coming into the show. And, and so for me to do that, I have to be able to communicate the value to the people who want to get involved. And I learned that by being a VP, I learned that by running an agency. And so every single bit of my experience, as weird as it is,

is being used in in small ways or in big ways to allow me to do this completely different thing that if you'd even 10 years ago if you'd ask me what do you think you're going to be doing in 10 years i i would have told you i'd probably be you know a vp or a founder like that would be my hunch is like oh yeah i'll be running like a tech company is my guess i'll be in leadership somewhere um

And that almost happened. Like I was a VP at Netlify. There was a chance for me to probably leave Netlify and go in as a technical co-founder of a company or as a CTO somewhere or maybe a CMO somewhere. But what you're doing is so much more interesting. And at the end of the day, I get to do all those jobs. I am our CMO. I am our CEO. I am a dev rel. I am an engineer. And I get to like –

hold the camera sometimes and I get to do a little bit of acting and I get to write like I basically you know through chasing the things that I'm curious about I was able to carve out this space that didn't exist before and I get to use all of these skills and pursue all these things that I find interesting in a way that is it is really hard like don't get me wrong this is not a job that I'm like cakewalking I'm working a lot I'm

way over my head in a lot of different areas, but I'm having a blast. And, and I don't think I could have done that if I didn't just have this, this sort of like little thing in the back of my head. That's like, are you challenged? Like, are you actually, are you growing? Did you get a little bit better today than you were yesterday? And that driver is, is just kind of, you know, give me permission to be curious about stuff and chase that curiosity. And, you know, I trust that

that anything I learn will have crossover value. I could go learn ceramics. I'd probably find a way to use ceramics and what I learn about ceramics, at least, in how I do other things in my life. I think we get it in our heads that if you are in an industry, that if you leave that industry, none of the skills are transferable. But I have found...

many times over, every time I shift from one role to another, from even from an industry to another, that the amount of crossover is huge. Like you really do retain a lot of the value of anything that you learn. And the only thing that doesn't directly transfer is like, okay, if I were to leave engineering and go over into making food content, almost everything that I know stays intact. I just wouldn't be directly writing code anymore. Yeah.

So some of the domain expertise falls off, but like all the meta skills are still there. Like a lot of the context you said. And really the specific domain expertise, except in the most specialized roles, is

Specific domain expertise is really only valuable from getting you from junior to about senior. From senior to principal, staff, VP, director, whatever the advanced things are, your domain expertise doesn't really help after that point. It's all the other things. It's how you work with people. Can you articulate plans well? Can you...

Get everybody on board. You know, it's like all these things that are really not nothing to do with the specifics of your domain, which is why a great manager doesn't need to know how to code because that's really the least important part of a great manager's job. Like a good leader is there because they're good at leading, not because they're good at coding. And I think this is a big mistake we make in the industry where we take good coders and say, obviously, you can run a company and then they don't.

And we're all surprised. It's like, well, they didn't have any of the skills. They know how to code. They don't know how to lead. They don't know how to coordinate anything. I mean, I would do the why not both girl. I think that...

It makes you better able to empathize with the people that you're managing if they respect you and if you could potentially sit down and solve technical problems in addition to being able to just do the traditional thing. I think at the bottom of everything, what I believe is that there's no harm in learning and there's a lot of harm in thinking that learning is a waste of time. Yeah.

Yeah. So like if you're looking at a skill going, when am I ever going to use that? I promise you, you will. Like it could be anything. You want to learn how to edit tick tocks. You want to learn how to basket weave. You want to learn how to make little like paint miniatures, like any of that stuff. Every single bit of it is going to be valuable somehow. And you can find a way to use it. Specialization is for insects.

Well, I am going to encourage everybody to check out an episode of Elite Heat on CodeTV, and I'm also going to encourage them to check out an episode of Web Dev Challenge. I really enjoyed watching both shows, and I'm really excited to see what you all do with CodeTV in the future and see where you take things because it sounds like there's plenty of open...

see that you can explore in the area of, if you want to be like Bravo for developers, like I think that'd be like an amazing thing to exist in the world. Yeah. We've got a lot of ideas and you know, we're always looking for new partners. So, you know, like shameless plug, if you've got a company and you want to reach more developers, get into my inbox. Let's talk. We have some, we can, we can have a lot of fun together. Absolutely. Well, Jason, it's been an absolute pleasure talking with you. I've learned a tremendous amount from you. Uh,

And I think the role of tacit knowledge, the importance of going to developer-focused events, the importance of continuing to challenge yourself and not getting complacent. And I mean what you said about positive nihilism and the notion that life doesn't really have any meaning. There's this webcomic that I love. It's this guy. He's all down and sad. He's like –

like, nobody gives a damn. And then he looks up and he's suddenly really happy. He's like, nobody gives a damn. That's right. That's exactly right. Yeah, I can do whatever. And thank you very much for having me on the show. I feel like Free Code Camp has been one of those fixtures throughout my entire career where I've just, I talked a little bit earlier about how we don't always have access. I grew up in Montana where there were no other programmers.

And I didn't have access to other tools. And had I had a free code camp, I think that would have made a really big difference for me. And seeing how, you know, you've been able to connect people who are in all corners of everywhere who maybe don't have an in-person community they can get to, to get free access to materials instead of being told you got to go buy this, you know, multi-thousand dollar boot camp or whatever. Like,

It really is like I love when you can see that somebody found something that they can truly care about. And I feel that you –

You have found that thing and you make something that I think is really valuable. And I think the community that has emerged, the teachers and the folks who are really active in the community, it just – it's really something special. And so I'm really happy to get to play a small part of it and to be here on this. And I did a little – a couple other things in the past with y'all and it's always such a pleasure. Yeah.

Yeah, well, I've learned a tremendous amount from you. I hope everybody listening has learned a ton from Jason as well. Again, I've got some links to some stuff in the show notes that you should check out. If you want to learn more about Jason, learn more about CodeTV. And until next time, everybody, happy coding.