Learn with Jason Lengstorf
Jason Lengstorf shares his journey from running a band and agency to pioneering GraphQL at IBM, joining Netlify, and building Learn With Jason.
Episode Description
Jason Lengstorf shares his journey from running a band and agency to pioneering GraphQL at IBM, joining Netlify, and building Learn With Jason.
Episode Summary
Jason Lengstorf joins the Full Stack Jamstack podcast to trace his unconventional path through web development, starting with building a custom PHP CMS for his band, running an agency on WordPress, and eventually tackling massive frontend performance problems at IBM. His work normalizing data across dozens of microservices teams led him to create Gramps, an early GraphQL federation tool that predated more polished solutions from Apollo and others. Jason recounts a pivotal burnout crisis in his late twenties—complete with stress-induced hair loss and a reflective trip to Alaska—that reshaped how he thought about work and life balance. The conversation shifts to his role at Netlify, where he champions framework-agnostic hosting and a collaborative, non-zero-sum philosophy toward the developer ecosystem. He explains how Netlify's developer experience engineering team differs from traditional advocacy by combining community outreach with actual integration engineering, like building plugins to support Next.js on their platform. Jason also reflects on Learn With Jason, his live-coding show where guests teach him new technologies, describing how it evolved from streaming internal Gatsby meetings into a format that lowers the stress of public coding while fostering genuine learning. The episode closes with a discussion of how his team measures impact through shifting community narratives and adoption metrics rather than simple dashboards.
Chapters
00:00:00 - Jason's Early Web Dev Journey and Agency Days
Jason Lengstorf introduces himself and recounts how he first got into web development through his band, learning PHP, JavaScript, and even Flash to get music online. He built his own CMS, which turned out to be a painful lesson in maintenance and client handoffs. The experience taught him the value of pragmatism and using established open source tools rather than reinventing the wheel.
After realizing his custom CMS was unsustainable, Jason switched to WordPress and felt less like he was locking clients into his own fragile solutions. The hosts discuss alternative CMS tools of the era—Perch, Concrete5, Movable Type, Drupal, and Joomla—and how the PHP ecosystem shaped early web development choices. Jason reflects on how he initially felt intimidated by enterprise-oriented tools like Drupal, thinking they weren't meant for indie developers like himself.
00:06:00 - From WordPress to Burnout and the Path to IBM
Jason describes how shifting to WordPress freed him to focus entirely on frontend work, building elaborate interactive client sites. But years of 90-hour weeks and toxic hustle culture caught up with him—stress caused a chunk of his beard to fall out, prompting a serious reckoning. He booked a trip to Alaska, spent time in a cabin without internet, and journaled about what he actually wanted from life.
After selling his agency, Jason took a low-demand consulting role that swung too far in the other direction, leaving him feeling empty working only ten hours a week. He eventually joined IBM at a healthy 40-hour pace and began confronting the massive legacy frontend of IBM Cloud. The dashboard he worked on took 40 seconds to load due to multiple stacked frameworks and a tangled Node proxy layer, which led him to start decoupling the frontend from the monolith—an approach that would later align perfectly with Jamstack principles.
00:10:05 - GraphQL, Gramps, and Solving Microservices Data Problems
Jason explains how IBM's REST API architecture forced dozens of sequential calls to load a single dashboard, motivating the move to GraphQL. He created Gramps, a GraphQL harness that let independent teams define their own schemas and resolvers while centralizing everything into a unified API layer. This predated popular solutions like Apollo Federation and schema stitching, solving a real enterprise problem born from IBM's sprawling multi-team structure.
The conversation broadens into how working at large companies gives early visibility into problems the open source community hasn't yet encountered, such as internationalization at massive scale. Jason notes he wasn't necessarily the first to solve the federated GraphQL problem, but he was among the first to discuss it publicly. Anthony draws connections to his own work at StepZen, and both reflect on the blurry line between open source projects and paid cloud products in the GraphQL ecosystem.
00:16:25 - Netlify's Philosophy and the Non-Zero-Sum Ecosystem
Jason articulates what drew him to Netlify: its framework-agnostic approach and commitment to being a rising tide for the entire ecosystem rather than locking developers into a specific tool. Unlike platforms tied to a single framework, Netlify supports Gatsby, Next, Nuxt, Angular, vanilla HTML, and anything else developers want to deploy, investing in serverless compute and partnerships to expand what's possible on the Jamstack.
He pushes back against zero-sum thinking in the developer landscape, arguing that complementary services like Hasura, Apollo, Netlify, and frameworks like Redwood all make developers' lives easier without competing directly. The hosts discuss Netlify's free tier philosophy—letting developers launch commercial projects without paying until they're actually generating revenue—and contrast it with platforms that require payment upfront. Jason highlights customers ranging from indie developers to major brands like Popeyes and Victoria Beckham Beauty as evidence the model scales.
00:23:43 - Learn With Jason: The Joy of Learning in Public
Christopher asks about the intent behind Learn With Jason, and Jason explains it's rooted in sharing the joy of learning rather than pressuring viewers to adopt specific tools. He credits his career advancement partly to having learned how to learn, describing how curiosity across all domains—from Ikea furniture to cooking to code—makes him more effective, especially at senior levels where impact on others matters more than individual technical skill.
Jason traces the show's evolution from streaming internal Gatsby meetings to pair programming with community members, eventually settling on a format where guests teach him while he does the coding. This structure lowers the stress of coding in public for guests and creates a safe space for beginner questions. Anthony shares his own positive experience appearing on the show, and they discuss how the format organically builds community connections and creates genuine moments of discovery.
00:30:53 - Favorite Tools and the Developer Experience Engineering Team
Jason highlights his favorite technologies discovered through Learn With Jason: Hasura for instantly standing up GraphQL backends, Sanity as a flexible content platform, and Applitools for intelligent visual regression testing that makes frontend quality assurance accessible. He praises Angie Jones's demonstration of Applitools as a standout episode that made testing feel approachable rather than intimidating.
The conversation closes with a look at how Netlify's developer experience engineering team operates differently from traditional developer advocacy. The team combines community outreach with hands-on integration work, such as building Essential Next.js plugins, and measures success through shifting community narratives, adoption metrics, and delivering on OKRs rather than relying on simple automated dashboards. Jason explains how principals on the team get deployed wherever extra attention is needed, embedding with different groups across the organization to maximize impact.
Transcript
00:00:00 - Anthony Campolo
Christopher, are you wearing an oodie? Yes. Do you love it?
00:00:04 - Christopher Burns
It's very warm.
00:00:16 - Anthony Campolo
Let's get it rolling. Jason Lengstorf, thank you so much for being here at the Full Stack Jamstack podcast. I've listened to so many podcast interviews with you, I think I could probably tell your whole life story.
You originally were in a band and then got into this whole front-end world through IBM, of all places. You did a bunch of crazy GraphQL stuff at IBM. Eventually you found your way to Gatsby. You were the Gatsby dev advocate and were at peak podcasts when I was first learning to code. Now you work at Netlify, which is kind of the Mecca for developer experience right now. I'm really happy to have you.
00:00:48 - Jason Lengstorf
Peak podcast. Thank you so much for having me. That was a very good breakdown. The only part there was a few years in the middle between the band and IBM, where I also ran an agency. That was where I learned a lot of my front-end stuff because I got thrown all the way into the deep end of things.
00:01:05 - Anthony Campolo
I'd love to hear about that then, because I don't know if I've heard you talk about that on many of your other podcasts. Could you dig into that? What were some of the technologies you were working with?
00:01:11 - Jason Lengstorf
Like most developers who are young and don't have a support system and don't have anyone to tell them they're making bad decisions, I decided I was going to build my own CMS when I was in my band. That was kind of how I first got into web dev.
I had learned a little bit of JavaScript and PHP. I got into ActionScript. I was doing Flash because, you know, for bands at the time, the way to get music on the internet was Flash.
00:01:32 - Anthony Campolo
So this was before MySpace then.
00:01:34 - Jason Lengstorf
It was right around the time that MySpace started picking up. We wanted our own website in addition to the MySpace, and then I got really into MySpace customization. That was when I kind of got my feet wet with CSS.
When I got into the agency, I realized that some of the stuff I was doing for the band was completely infeasible for client work because with the band I could just go and make the change or do anything like that. But that ongoing maintenance was not something I could do for multiple clients.
I started looking into how I could let people update content. Like I said, no adult supervision. I bought a book on PHP and MySQL, and I built my own LAMP stack CMS that was horribly insecure and barely worked, didn't handle images, and all of these bad, bad decisions. I rolled it out to a bunch of clients and eventually realized how bad of an idea that was when the maintenance calls started coming in and I realized that I couldn't really charge somebody because I had built a bad thing.
[00:02:34] That was my first dose of reality as a developer. You can't just reinvent solutions because other people's solutions aren't exactly what you want. You have to be pragmatic, and you have to recognize that it's not just the building of the thing.
The building is exciting, but then there's the training and the maintaining and the documenting and the growing and evolving. That part's not fun, especially if nobody but you uses your tool.
At that point, I switched over to WordPress because I knew if I handed off a WordPress site to a client, not only were they able to do all the things that they needed to do, but I could hand them off to another developer. I wasn't leaving them completely out to sea. If I said, sorry, I can't take this project, they'd be like, okay, I guess I'll take this custom pile of crap you handed me over to another developer and say, please help. Then they'll charge me to build a brand-new website.
[00:03:22] I felt less like a crook when I switched over to using open-source software because I wasn't locking people into my solutions. I wasn't tying people to my whims.
00:03:30 - short split/interjection
That was a tough set of lessons.
00:03:31 - Jason Lengstorf
That I had to learn.
00:03:32 - short split/interjection
But it all ended...
00:03:33 - Jason Lengstorf
...up being good in the long run. I feel like it taught me a lot about how to build a CMS and how difficult that actually is. I feel like that type of pragmatism is something you can really only learn by getting so in over your head that you realize how much work went into these tools that we otherwise kind of snub our noses at and say, "Oh yeah, but who would use WordPress?" I'll tell you who uses WordPress. Everybody uses it because it's good.
It is maybe not as polished or beautiful or modern as you want it to be, but it is a good tool that covers so many use cases and all that stuff. So I think that's a hard lesson through many late nights.
00:04:12 - Christopher Burns
When I worked at an agency, they were very much a PHP agency, but they thought WordPress was a bit too big, so they went with an alternative called Perch. Have you ever heard of Perch?
00:04:25 - Jason Lengstorf
I have heard of Perch. I don't know if I ever used it, but I do know the name.
00:04:28 - Christopher Burns
It was created by Drew.
00:04:31 - Anthony Campolo
Drew McLellan. I was going to say, I have heard of this, but I've heard this because you told me about this.
00:04:35 - Christopher Burns
Yeah. Him and Rachel.
00:04:37 - Jason Lengstorf
Rachel Andrew.
00:04:38 - Christopher Burns
Yeah, they made that. It's still really good, but they've just handed it off to another company now to carry on. Back in the day, when you wanted a WordPress alternative, grabbing Perch was pretty good.
00:04:52 - Jason Lengstorf
Yeah. There are a ton of good alternatives out there. Concrete5 was one that a lot of people used. Even Movable Type, is that what it was called?
00:05:01 - Anthony Campolo
Well, Movable Type, was that a CMS? I always thought of that more as a static site generator tool, but I have no idea what Movable Type was. I've just heard people talk about it.
00:05:08 - Jason Lengstorf
Yeah, it was kind of like, at the beginning when there was WordPress and it hadn't taken over, it was Movable Type and WordPress. They were the two that were kind of poised, at least from where I was sitting in my little corner of the world.
00:05:20 - Anthony Campolo
Because Drupal is also in this conversation, right?
00:05:23 - Jason Lengstorf
Drupal and Joomla and all of these. It's interesting when you look at the development landscape because I remember when I was getting started and I thought of myself as an indie dev. I was intimidated by Drupal because it felt too... I was like, well, I'm not a real company.
00:05:40 - Anthony Campolo
Too enterprisey.
00:05:41 - Jason Lengstorf
Like, I looked...
00:05:42 - Jason Lengstorf
At Drupal and I was like, "Oh, that's for real companies, and I'm not a real company." So I was looking for something that felt like the indie web, and that was maybe a mistake on my part because I do think that, you know, seeing how flexible the Drupal and Joomla communities are. Why are we talking about PHP so much?
00:06:00 - Anthony Campolo
So I'm super curious now how you got from this whole world into the Jamstack world then, because you transitioned at some point from WordPress to doing Jamstack?
00:06:07 - Jason Lengstorf
That's a great point. As I was building more and more sites for my clients, I started moving into the front-end experiences we were making. Once we got to WordPress, suddenly I wasn't building backends anymore. I never thought about backends because you just threw a WordPress site at it and it was done and that was it.
I had all this energy to spend on the front end of the site, so we were building these really elaborate and beautiful interactive sites for clients, and it was really, really fun. When we started seeing the shortcomings of that, we started to explore things like React or Angular or whatever was out there around that time.
That was when I had this really bad quarter-life crisis. I was in my late 20s and I had been working like 90 hours a week for years. I also came from that unhealthy corner of hustle culture where it's like, if you're not overworked and under-slept, you're not trying hard enough and all that stuff.
[00:07:02] So at a certain point, I woke up. My partner at the time was like, "Hey, you've got a bald spot on your chin." A chunk of my beard had just died. Over the next few months, it just got worse, and I spent two years not being able to grow a beard.
When I realized that was happening, I was like, oh my God, I'm so stressed that I'm actually decomposing. That can't be my life. I'm in my 20s. I can't be physically falling apart in my 20s. So I kind of freaked out, decided I was going to burn it all down, booked a trip to Alaska, and spent a week and a half in Alaska in a cabin with no cell service and no internet with some friends.
We went out and went crabbing every day, then we'd go out and pull up our crab pots and cook those and eat them. That was all I did. I was just like, okay.
[00:07:44] And I thought about what I really wanted my life to be like.
00:07:48 - Anthony Campolo
Did you read Walden?
00:07:49 - Jason Lengstorf
No, I didn't read Walden.
00:07:51 - Jason Lengstorf
I journaled the whole time. I was thinking, what am I worried about right now? What am I afraid of? What is the urge that I'm feeling at this particular moment?
When I came back, I decided I needed to get out of that agency. I sold the agency and moved to a consulting role that was on the opposite end of the spectrum. They were like, we don't care how many hours you work. We want you to do R&D. Here's the project we want you to build. I was able to work on it really quickly, and I was like, do you want me to do more? And they were like, no, this is all we need you to do.
So I was working like ten hours a week. That led me to the other side of this existential crisis. I was like, okay, I can't just make money and do nothing either. That also feels terrible. I started feeling very empty and weird.
[00:08:30] Then I took the job at IBM, and that was how I started moving to the Jamstack. I got to IBM, and I was working 40 hours a week. I got to leave and be at home when I was done and not think about work or anything like that.
But I was working on these big legacy front ends and the way they were set up. I worked on IBM Cloud, and IBM Cloud is a mass of multiple teams that have been built and acquired and mashed together into one service, as all the cloud providers are.
One of the projects we were working on, we needed to make this certain dashboard that was really slow. It took like 40 seconds to load, and we wanted to make this dashboard performant. So the process we took was to start looking at where the slowdown was. There was an API call, and there were like four different front-end frameworks being loaded. You would hit jQuery that loaded, I think it was Backbone that loaded something else, and then finally we loaded React in there. It was like, okay, so that feels bad. We probably shouldn't do that.
Then we started really looking into what it was. It was this Node microservice that was really a copy of the monolith, like one of 30 copies of the monolith. It had all of this legacy stuff in it. The front end was mostly written as a front end, but it was kind of built by the server, and there was this Node proxy layer in the middle that was wrapping all of these. It was a mess, just code going every which way, and everything came from weird places.
I wasn't using the Jamstack in the way that it's described today because I didn't know that was a thing, but what we started doing was pulling the front end out. The way I used to describe it was that it floated over the rest of everything else, which it turns out is the way we describe it now. It's decoupled.
00:10:05 - Anthony Campolo
Decoupling. Yeah. Is this around GraphQL stuff you're doing or is this separate?
00:10:09 - Jason Lengstorf
Yes. The GraphQL stuff was actually part of it.
00:10:12 - Anthony Campolo
Yeah. I'm curious about Gramps. We can get into that in a second though.
00:10:15 - Anthony Campolo
Yeah.
00:10:15 - Jason Lengstorf
As we were starting to float this UI layer over the top of the monolith, we needed a way to normalize data. What we were doing before was a whole bunch of work with proxies, so every back-end service exposed an API. They were REST APIs, and they were thoroughly normalized.
That meant that if you were trying to load an account dashboard, you were going to load a user object and then get a list of IDs for transactions. Then you would have to make one query per transaction ID to get that transaction object. Then you would have to make one query per additional list of IDs per transaction to get more details to fill out this thing. That was why it was taking 40-plus seconds to load this page.
We started looking at how GraphQL fit into this scenario. GraphQL was the way that we were able to get away from writing Node proxy layers in our front ends that were trying to build bespoke endpoints, but it was creating all this weird confusion.
[00:11:09] Gramps was this idea. I was doing some study around how we can make APIs better. I saw what Facebook was doing with Relay and GraphQL. I started looking at how that works in a microservices environment.
Facebook has the monorepo, or uni-repo, however you want to describe it. All the code is in one place. So when you start implementing GraphQL, it's in one place and it has this thing. I had 30-plus teams at IBM that needed to be able to control their code independently, and they were not interested in getting into a monorepo. It was a nonstarter.
00:11:40 - Anthony Campolo
You're building a mesh.
00:11:41 - Jason Lengstorf
Yeah. I was like, how do I let these teams control their data but also centralize the data into one layer in a way that doesn't make anybody feel like they've lost control and that doesn't turn into another spaghetti proxy? GraphQL ended up being that solution.
So what we did, we built a GraphQL harness, and that GraphQL harness could accept a bunch of resolvers and schema definitions. It kind of smashed them all together. This was before schema stitching or federation or any of those things were popular.
00:12:11 - Anthony Campolo
Yeah. I've never heard the term GraphQL harness before. What does that mean exactly?
00:12:15 - Anthony Campolo
In my mind.
00:12:16 - Jason Lengstorf
What I was thinking of it as was like a plugin system. So each service, each backend, would define their own schema resolvers and any auxiliary stuff that they needed. Then they would put that out through a Node module.
That Node module had a uniform API surface. So as long as their backend module for GraphQL adhered to the API contract for Gramps, then Gramps could stitch it all together and turn it into a single GraphQL API.
As part of that, I was providing a Redis layer for caching. It had good defaults, but they were able to control those if they wanted. It did query deduplication. It did a lot of things that just get tricky with REST. You have to build it yourself and your front end or the REST team has to know how you're using it and give you special caching treatment and stuff.
00:13:01 - Anthony Campolo
Do you know people still use Gramps?
00:13:02 - Jason Lengstorf
They do. It's still live. Yeah, it's still in use at IBM. What I will say is that after I built Gramps, the Apollo team and other companies have built more sophisticated versions of what I did.
00:13:13 - Anthony Campolo
What's funny is I work for one of those companies, actually.
00:13:16 - Jason Lengstorf
Oh, nice. Yeah, yeah, yeah. That's kind of the thing. I was experimenting, and I went to the GraphQL Summit and I talked about this thing.
Later, other companies built, I would say, more robust ways of solving this problem. I built it in a way that was scalable, but it was very much like, you do things exactly this way, which there's an argument for that. But I think that the way Apollo solved federation in a really nice way, Hasura has done this idea of kind of remote schemas in a really nice way, and there are companies all over the place that are doing really cool stuff. What's your solution?
00:13:49 - Anthony Campolo
StepZen is a newer one, but it's a similar type of deal where it's doing connections between a lot of different APIs and it's translating from REST to GraphQL. We're also getting more to thinking of how we can kind of stitch the schemas and the components together so we can start creating more of a workflow around the front end as well.
Because right now it's just like this. It's like a managed GraphQL API gateway is kind of what it is. So you get all these questions, how you expose your secrets and stuff like that. It's a huge, massive, interesting space. Hearing you talk about this kind of blows my mind because you were way ahead of this.
00:14:24 - Jason Lengstorf
The benefit and the curse of working in a big company is that you'll see these big problems coming before the open source community does because you're actively living through the problem. You see that now when you look at open source projects where they'll introduce internationalization and it works really well if you've got one site.
Then a big company comes in, the Microsofts and the Oracles and IBMs, and they're like, hey, we have 10,000 web pages and they're managed by 40 different properties. We need internationalization to be customized like this or we can't ship it. And you're like, oh, I have no idea how we're going to make that work in our product.
Being able to handle that really bespoke work, where it's enterprise and we made our company by balling up a bunch of other companies and we have all the tech debt that comes with that, solving those problems is really weird and hard. I had unique insight because of the ball of teams that was at IBM into a particular problem that was going to come up for GraphQL users at the time that GraphQL was ramping up really hard. I don't think I was the first person to tackle this.
[00:15:24] I think I was just the first person to talk about it in public.
00:15:27 - Anthony Campolo
Because in this strange space between open source projects and actual services that you would pay companies for, like Apollo Federation, I've heard it referred to as both an open source thing and as a paid product. I haven't really looked into it, but it seems like they're all kind of on this periphery line of where do we make this line between open source and not open source. Does that line end here with these kind of API type tools?
00:15:51 - Jason Lengstorf
The thing that's interesting is, as open-source companies are getting funded, it seems to me that the model has been: build an open-source thing and then build a cloud platform that supports the open-source thing when it's done well.
I think it's great because it's an optional thing that adds enough value that you want it. When it's done poorly, it starts to feel like they're shipping two-thirds of a product and then you have to pay. It's like when you get a game on your phone and you get to play one round, and then it's like, oh yeah, you got to pay to unlock the rest of the game.
00:16:25 - Anthony Campolo
Freemium games.
00:16:26 - Jason Lengstorf
I don't know. It feels like something that is an actual value-add and not the value. If I feel like I got tricked into getting half of an open-source product and then I have to pay for the cloud for it to work, then I'm sad. But I do think Apollo Federation, I think they've done a good job of, like, you can build and host and manage your own federation if you want, or their cloud will do all of the configuration and setup and dashboards for you so that you don't have to deal with that yourself.
00:16:54 - Anthony Campolo
That seems great. That seems totally reasonable. What I find interesting, I'm pretty sure I have a speculation about which cloud you're talking about, but I am really curious. I don't feel like Netlify led with a framework. They've had different frameworks that have circled around them, but I feel like Netlify never really bought into a framework the way Vercel bought into Next. It almost was Gatsby, but now it can't be because Gatsby has their own cloud. So what do you think about that?
00:17:19 - Jason Lengstorf
Something that has always been really near and dear to my heart is this idea that open source is and should be the rising tide that lifts all ships. We want to be the people who are putting things out there that make everyone around us better.
That's part of what really attracted me to Netlify. Netlify is a platform and it's a paid service, but it supports anything. You can deploy Gatsby or Next, or Nuxt or Angular or your vanilla HTML site or whatever you want on Netlify, and we don't care.
We use the Jamstack architecture, and that's what our platform is built to support. But we're working hard to make sure that open-source patterns that are becoming popular are supported. That's why we've put so much into Netlify Functions and the ability to do serverless compute so that you can build full-fledged apps on the Jamstack.
We're working on partnerships with other companies so that you can bring, like, how can you make data work on the Jamstack? How can you make error reporting and observability work on the Jamstack?
[00:18:20] We're not trying to be the company that sets up competition with anybody. We're trying to be the company that makes all the people around us better. Because to me, the heart of this is community. The heart of this is making people feel like they're better at their jobs.
I'm not a big fan of this idea of drawing up the territories. I don't like this idea that if you are a developer, you have to choose a camp and then you have to use that tool forever, or else you have to migrate to a new service.
What I prefer is this idea of I'm a developer and I can work on whatever I like now, and then in two years, two years ago it was Gatsby. This year it's Next, and who knows what it will be in two years from now. Maybe it'll be Next. Maybe Vue finally takes over the ecosystem.
I'm going to have to rebuild my app anyway. I don't want to also have to go churn all of my cloud providers and all of my accounts because I have to move to new hosting or something.
[00:19:11] And that's what attracted me to Netlify. I run Learn With Jason, right? On Learn With Jason, I build everything. People come and they just teach me whatever they're excited about, and I love it.
00:19:24 - Anthony Campolo
I was there. I did one, exactly right.
00:19:26 - Jason Lengstorf
You came in, we did Redwood, and we deployed that to Netlify. We're able to just build and deploy whatever we want, wherever we want.
It's such an exciting experience to be able to say, okay, I have a site, I have an idea. Now I can pick the best tool to build my idea, and then I can deploy it somewhere like Netlify that is not opinionated about what tools I'm using. It just gives me a good experience and lets me do whatever I want. That's why Netlify has never gone all in on a framework or anything.
00:19:52 - Anthony Campolo
Yeah, the phrase I boil it down to is collaborators, not competitors.
00:19:56 - Jason Lengstorf
Exactly. People love game theory, right?
00:19:58 - Anthony Campolo
Do they? I do. I don't know about people.
00:20:00 - short split/interjection
I feel like I hear people talk about it all the time.
00:20:02 - Jason Lengstorf
And there's this very active discussion about strategy and game theory. There's a discussion of the competitive landscape being a zero-sum game, and I completely refuse to believe that. I do not believe that web dev or open source is a zero-sum game. It doesn't have to be winner-take-all.
We are complementary services. If you use Netlify and you also use DigitalOcean, or you use something for Kubernetes and you use Apollo for your GraphQL layer or whatever, everybody's winning. Your job just got so much easier as a developer building a thing because you're able to say, hey, I'm going to use Hasura to manage all of my data and events, and I'm going to use Netlify so I don't have to think about release engineering and deployment. And I'm going to use whatever open-source tool, I'm going to use Redwood, because it gives me all these opinions about how I can very quickly get something scaffolded up and running.
[00:20:53] How easy did my life just get? And every single one of those services wins because none of them are actually competing. They're all very complementary. I think that's the power of this Jamstack model.
It really gives me so much hope and excitement about the community in general. When I see that, it does bum me out a little bit to see some attempts being made to carve it up and say, no, no, no, come to our walled garden.
00:21:12 - Anthony Campolo
Yeah, I think it's different marketing teams. When I'm boots on the ground and I talk to developers, every developer I've ever talked to who has used Netlify has raved about it. I've never met a single developer who used Netlify and was like, ah, that was the worst.
Not only does it work for them, they say it's like the nicest thing they have ever used. I can attest to that. For what it does, it is by far the nicest tool I've ever used. So yeah, it's amazing. And for what I was doing, it was free.
00:21:39 - short split/interjection
Yeah.
00:21:40 - Jason Lengstorf
I think that's another important thing too. We want you to be able to launch a commercial entity on Netlify and make some money. We want you to pay when you start making money. It's not like pay when you think you might make money someday.
If you read the terms for other clouds out there, you can't run commercial sites on the free plans. You have to immediately start paying. We want to be aligned with what people are doing. We need to make money as a business or else we don't continue to exist, but we don't want to make money at your direct expense.
It should be the kind of thing where we're providing so much value to you that we're only taking a small portion of what you're already bringing in and aligning free tiers with that and making it so that we can be a platform that grows with you. We've got everybody from indie developers who are trying to launch their first thing to Popeyes Chicken, Loblaws in Canada, which runs the largest retail chain in Canada, or Victoria Beckham Beauty in the UK. Big companies with huge amounts of traffic and huge amounts of revenue are also running on Netlify.
[00:22:38] We'll grow to that scale with you and will charge accordingly when you're making millions of dollars in revenue. You'll have an enterprise contract with us, but when you're an indie, you don't have to pay us. Go get your own bag before we come after it.
00:22:52 - Christopher Burns
Something that I always think is super interesting was a talk by Sean C. Davis at Next.js Conf, and he was saying that everything is a CMS. When you look at a situation, a challenge, you shouldn't just go with your biases. You should always evaluate the current options and pick the best one. That's always stuck with me.
Since I saw that, I've always sat in a camp like Gatsby forever and then Next.js forever. But now I always think about it like I've got a problem. What is the best tool for that problem? It changes the more you grow. A Gatsby image-heavy Jamstack site was the key for ages. But then as soon as Next.js brought out their image component, you reevaluate and say, maybe I could build this on Next.js.
Now it's this thing that I think is always really hard to think about, and I think this segues well into Learn With Jason, because my biggest question with Learn With Jason is, do you want people to feel like their hair is on fire and they need to learn just what you taught them and take it into production in the next week?
00:24:07 - Jason Lengstorf
No, not at all.
00:24:08 - Anthony Campolo
Definitely not. Yeah.
00:24:09 - Christopher Burns
What I mean by that is I watch a lot of conference talks, and some talks are like, you're not using this, this is like the best thing ever. Here's a 15-minute presentation with just the highlights.
00:24:20 - Anthony Campolo
Because they're selling you something, dude. Because they're selling you a product.
00:24:24 - Christopher Burns
I know, I know.
00:24:25 - Jason Lengstorf
From my standpoint, the whole goal of Learn With Jason is this: my absolute favorite place to be is in that feeling of optimism for the future. Nothing makes me feel more optimistic for the future, at least career-wise, than when I'm seeing somebody who is really excited connect a new set of dots for me.
People talk about the joy of learning, and I think that a secret weapon in my career, one of the keys to my advancement, is that at some point, and I don't know when this happened for me, but I learned that I had spent a lot of time learning how to learn. I have to thank my parents for that because I feel like they kind of just locked me in rooms and forced me to figure stuff out.
At some point, learning became fun. I enjoyed the act of trying to put a puzzle together. I have just as much fun learning how to put together an Ikea shelf as I do learning how to cook a different kind of meal, as I do learning how to build something on the internet.
[00:25:21] That joy of learning is, for me, easily the thing that has been most valuable because it means that when I walk into a room, I'm not just waiting until we talk about the thing that I'm interested in. It means that I'm interested in everything we're talking about, and I want to learn more, and I want to understand how it all fits together.
Especially when you're talking about career advancement, when you get to senior engineer, I'm referencing my ladder at Netlify, you're still an individual contributor and your advancement is tied to your own individual abilities. But when you move beyond that, when you move up to staff, principal, etc., you start getting measured on your impact on the people around you and your impact to the broader business.
So if all you're interested in is the exact code, how much of an impact can you have? You can do it on your team, but can you have a bigger impact when you're talking to product or sales or the community? How can you get connections there?
The goal of Learn With Jason is really just to try to share that joy of learning. What could we learn today and what would be fun? That's why not all the episodes are about code. It's primarily about code. We've done over 200 episodes, and I would say that 95% of them are about code. But I've also got episodes where I played Minecraft with Lindsay from my team. I made music with a producer out of Brooklyn.
00:26:36 - Anthony Campolo
I'm talking about career stuff too. That's a lot of good content you've started putting out.
00:26:39 - Jason Lengstorf
Yeah, I had Sarah Drasner on and we talked about getting hired. We talked about how to grow your network and your resume, and all of that stuff is interesting. What I want to do is create an environment where I feel like the best way to get people interested in something is to show them what it's like. I have a lot of fun, and I hope that comes through in the show.
00:27:00 - Anthony Campolo
Well, I had a blast when I was on.
00:27:04 - Jason Lengstorf
Yeah, right.
00:27:05 - Anthony Campolo
For me, coming from the perspective of a teacher, the fact that someone would create an entire show based around, hey, let me bring on people to teach things, you have no idea how big that is, what that means.
I never would have ever gotten that as a music teacher in a million years, to have been brought on to a platform to teach and be watched, like, 100 people watch me teach. That's crazy.
00:27:25 - Jason Lengstorf
It didn't seem novel when I started doing it, but I kind of realized now that it was something new. At the time, I was just like, I don't know, I need to figure out how to make this stream interesting.
The evolution of Learn With Jason was like, I started streaming meetings at Gatsby because I was just trying to create transparency for the company. That was one of my big goals when I was there, was like, how do we make this community feel like it's actually a community and not just like a group of people who are potentially the customer.
00:27:50 - Anthony Campolo
That's what I'm doing today. Doing my first stream today, actually.
00:27:52 - Jason Lengstorf
Oh, nice. Nice, nice. Yes.
I was streaming meetings and those weren't very interesting. Nobody really cared. Then I streamed some product work and that was a little more interesting. People kind of cared. Then I brought on somebody from the community and we worked on a Gatsby problem and pair programmed. That was interesting. People cared.
So I was like, well, how can we do more pair programming? Then I realized that it's not super comfortable for most people to code in public. But I was like, well, I'm comfortable coding in public. What if they taught me and I did the coding? That was how the idea was born.
00:28:20 - Anthony Campolo
That's the other hack. We're not coding at all when we're on the show. That's what flips the whole level of the stress that comes along with, obviously people are going to be very stressed just to be out kind of speaking publicly in general, but it puts the burden on you to fix the bugs, right?
00:28:34 - Jason Lengstorf
Yeah. And it puts the burden on me. I'm the beginner, and sometimes I really am the beginner, and I really don't know anything about what we're about to learn. But a lot of times I'm coming in with a pretty decent amount of knowledge of the topic because there's only so much JavaScript in the world. I've probably seen it before.
But I still play the beginner. I ask the beginner questions. I try to remember, okay, what were the questions I had when I started this, and encourage the chat to do the same thing. I figure if I can ask the beginner questions, it makes it a safe space for somebody to ask their beginner questions.
00:29:05 - Anthony Campolo
That's what I liked about the Redwood one. As far as I know, you actually didn't really know anything about Redwood. You'd heard about it, but you hadn't actually built anything with it.
00:29:11 - Jason Lengstorf
No, I intentionally didn't learn it.
00:29:14 - Anthony Campolo
I thought getting that genuine response, for me, was great because all the moments that are supposed to hit, you're just like, "Whoa, that was awesome." We were just like, nailed it on all fronts. It was very cool to get to introduce it to you, knowing how you know all the tech around it.
00:29:28 - Jason Lengstorf
Yeah. That's the fun, right? I think the other thing is when you take someone who is an expert in one area and you move them outside of their area, my response could be to get defensive because I'm used to being smart. But I don't know, it's kind of fun to be a beginner again. That's the joy of learning thing.
It's not fun to just know all the answers. It's really fun to be in a room where I'm like, man, I don't know anything. All right, there's so much to learn. Let's go. I've never had as much fun as I've had on that show. It's exactly in line with my sensibilities and my goals and what's valuable to me.
It's building such a cool community. There are so many people that I know because of that show, who either have come on as guests or who show up every week in the comments, in the chat. There's this whole thing that's happening that I never would have found had I not just pushed that button and gone live.
00:30:19 - Anthony Campolo
I mean, this interview is a spin out of that because we met through Learn With Jason and that happened through Brian Douglas. Brian Douglas was there. I was doing the Open Source Core Contributor Summit, and you had hopped on a chat for a second and you're like, oh, cool, Redwood. I was like, oh, hey, I wanted to get an idea about doing Jason. And you're like, yeah, sure. And then I got on Jason.
So it was just like those little moments, you know, where people's paths cross are super interesting. The thing you describe about creating an environment that allows you to continually learn from new people, that's kind of why people podcast too.
00:30:52 - Jason Lengstorf
Yeah, yeah, yeah.
00:30:53 - Anthony Campolo
Cool. Do you have any other questions, Chris, before we start winding down here?
00:30:57 - Christopher Burns
Of the technologies that you've taught or learned on Learn With Jason, what are your favorites, your most memorable ones?
00:31:06 - Jason Lengstorf
Probably the ones that I've gone back to the most. I use Hasura for all sorts of things now. It's become the thing that makes me really, you know, this podcast is called Full Stack Jamstack, that's the thing that makes me feel full stack: I can build a front end, and then I go to the Hasura Cloud and set up a full running back end with GraphQL and webhooks and all this amazing stuff.
I never had to write any code or figure out how to deploy a container, or even really understand how the Postgres stuff works in the background. I just know if I go and click these buttons, then I'm going to get a back end and it gives me a huge amount of power. So that one is very exciting.
I use Sanity a lot. We use Sanity to power a lot of web properties. I think it's really configurable and really flexible. I also just like that team. I really liked Espen, and he's been on the show a couple times.
00:31:53 - Anthony Campolo
Bryan, right, who hosts That's My Jamstack. He's at Sanity also.
00:31:57 - Jason Lengstorf
Yeah. Yeah, he just joined up. They just hired [unclear], and she's also amazing. That's a great tool, great team.
The other one that I really did not expect to be blown away by was Applitools. Angie Jones came on and she taught me about Applitools. That is a visual regression testing tool. I know that I said that out loud and somebody was like, "What? Why is that interesting?" But it's amazing because what it does is basically you add just a tiny bit of code, and you're using Cypress, which is another amazing tool that's so intuitive for something that you would think would be really hard.
You add just this tiny bit of code, and then you will get a notice if something visually changed on your site and not in a really rudimentary one-to-one comparison.
00:32:41 - Anthony Campolo
Because it snapshots your front end, right? That's what it does.
00:32:45 - Jason Lengstorf
It snapshots, but it's intelligent enough that you can say, well, this is the newsfeed. This will always change, so don't fail builds for that, but fail builds if my newsletter opt-in broke because that should never change and that's the number one thing on the site.
So you can do these really fascinating things where you're suddenly able to confidently make changes to your front end and know that you didn't accidentally break the styles of a page you didn't look at by tweaking the style somewhere else. It's so simple. It's another one of those tools that I think takes something that we all know we should eventually do, like, oh yeah, we should totally get testing in on this app, but who has time? Who knows how to make that work?
Applitools is like, cool, we can do it. You can get it set up in an hour and then you're good to go. That one has really stood out.
[00:33:28] Also, any opportunity to spend more than a few minutes with Angie Jones is such a delight. She is one of my absolute favorite people on the internet. You can watch any of her talks, or if you get a chance to interact with her, she's incredible. Very much after my own heart.
00:33:43 - Anthony Campolo
Yeah, I follow her on all the social platforms. I haven't gotten a chance to actually meet her yet, but open invitation. If she wants to join the show anytime, for sure.
The last kind of thing I would like to talk about is that you are on a team of developer advocates, which I think is still kind of a pretty rare thing. I feel like it's more of a solo role in a lot of companies, and we've had Natter and Swinson, who are on a developer advocate team at Amplify.
So you are on that team with Tara, Ben, Cassidy, and Phil, right?
00:34:13 - Jason Lengstorf
And Kenny.
00:34:14 - Anthony Campolo
So wow, that's a big team. How do you guys think about, first off, metrics? This is the first question I always ask. I still have yet to hear a good reason. What metrics do you look at? How do you even figure out if anything you're doing matters to the bottom line?
00:34:26 - short split/interjection
So there's a couple things that I'll say that are a little bit different about Netlify.
00:34:28 - Jason Lengstorf
The first is we very intentionally don't call it developer advocacy. We call it developer experience engineering, and there's a reason for that.
I didn't talk about Lindsay because Lindsay is on our integrations team, but she's very much part of the developer experience team. That team, the integrations team, is actively building what we call the Essential Next.js plugin so that those server things that Next is building work on Netlify now. Because of the work that the integrations team on the Developer Experience Squad is doing, we are out there prototyping things.
So in addition to what would be traditionally called advocacy, blog posts, speaking, community outreach, those sorts of things, we're also doing engineering projects around what would make the experience of using our CLI better, what would make the experience of using our app better, and what would make the experience of building an app on the Jamstack better. We bring a lot of that back.
Integrations was born out of that question. What would make it easier to build these full-stack Jamstack apps on Netlify? A bunch of questions and conversations happened, and we looked at what was going on in the ecosystem.
Next is the first thing we've tackled, but it's far from the last thing we're going to tackle. There's a lot of really exciting stuff coming out that's going to make building Jamstack-style apps while keeping all the benefits possible.
The other thing is I feel like people are getting excited about reintroducing servers into the mix, but I feel like everybody forgot that we got servers out of the mix because they're a nightmare. The response that we're hearing in a lot of cases is like, well, yeah, just set good cache-control headers. If cache-control headers were easy, we would have never stopped using them. The reason that we got to the Jamstack is because it's just not reasonable to expect the development team to be able to do that. There's a reason that joke is made that caching is one of the two hard things in computer science.
[00:36:11] So we're thinking about all that. But then you asked about metrics. When we're looking at metrics, we've got a few things.
The first one is on the integration side. We're looking at, are people using what we're building? Are we actually making a difference? If we build this Essential Next.js stuff, does that bring in Next sites? Are we seeing people use Next on Netlify? Yes, we're seeing that number go up and to the right, and we're very happy about that.
On the outreach side, we look at language. If we see a particular set of messaging, a good one that we've seen is, "The Jamstack is only static," right? That's a thing that you'll hear. It's an objection that people make. We know that's not true, but the community didn't know that wasn't true.
So we started making a really concentrated effort to create content and demos and examples and work with partners to show you can build really complex, full-fledged apps. Just about anything you can imagine can use the Jamstack architecture.
The way we measure that, our metric for it, is: are we the ones having to correct that misinterpretation of the Jamstack? If the community is jumping in and saying, "Oh no, you can build full-stack apps, here's the resource," or, "Here's a link," if other people are writing articles about it, that's our metric. We've changed the conversation in a way that's measurable.
00:37:32 - Anthony Campolo
If people built entire frameworks around full-stack Jamstack and podcasts, you could say exactly that.
00:37:39 - Jason Lengstorf
That's a metric for us. Were we able to influence the conversation so that this misinformation that was out there is being dispelled? Not by us yelling as loud as we can, but by providing enough examples and helping be stewards of the community.
We didn't do it by ourselves, but we hope we added the resources and some of the firepower that allowed people to shift that mindset.
We also look at stuff that's pretty standard. How many people look at the blog? How many people are converting? If somebody comes through our blog, how many of them actually become users? We look at key adoption metrics, like things that we want them to try in our platform. Are people actually trying that thing?
00:38:19 - Anthony Campolo
And then how do you think about your particular impact within your team in terms of how you all should measure that?
00:38:24 - Jason Lengstorf
We each end up owning key initiatives. My job is also a little bit different because now that I'm at the principal level, the way that principals get deployed inside of Netlify is we're sort of dropped into something that needs extra attention. So I get moved around a lot.
Right now I'm on our integrations team and I'm helping.
00:38:43 - Anthony Campolo
You're like the Wolf in Pulp Fiction.
00:38:45 - Jason Lengstorf
A little bit. Yeah. Cassidy as well is a principal on the team, and she's in kind of the same boat. She just went over to help out our engineering team on a project that was really high priority, and she went and embedded with them as an engineer on the team.
I'm on the integrations team right now. Before that I was working on the Explorers platform, the educational platform that we just dropped at Explorers Netlify. I helped with building that. We worked on the architecture and stuff.
Basically, we set OKRs. I don't even know what that one stands for anymore.
00:39:17 - Anthony Campolo
Objective key.
00:39:19 - Jason Lengstorf
Results. Yeah, yeah, yeah. We look at something that's like, this is an important thing. Last year it was like, we need to get Explorers out. That was one of our OKRs.
Then my metric is, did we deliver on that? Is Explorers live? We define outcomes. We want certain things to be true. A developer can find a resource about X. Someone is able to get from point A to point B in this topic.
Those are the kind of OKRs that we measure against. So it's very fluid. It's not the sort of thing that I think you could automate in a dashboard.
It's very much like we sit down at regular intervals and we say, what impact do we need to make, and what are the outcomes that show us that impact was made. Then we measure against that until we feel that we've made that impact, and then we reassess and make a new set of goals.
00:40:07 - Anthony Campolo
And that's why they pay us the big bucks, because it can't be automated. I would love to get into that whole conversation about the terminology around it and what we call ourselves as well, but we unfortunately are all out of time here.
I really appreciate you answering all those questions. You have been such a huge inspiration, I know, to myself and many others I know as a dev, not a dev advocate, but as a developer experience engineer. It's all kind of the same big bucket, I think, in a certain respect.
So yeah, thank you for doing what you do and being a force for good in the world.
00:40:42 - Jason Lengstorf
Thanks for having me. I had a lot of fun today.