The History of the Jamstack with Brian Douglas
Brian Douglas shares his journey from finance to coding, building Netlify's dashboard and DevRel strategy, and helping define the Jamstack movement.
Episode Description
Brian Douglas shares his journey from finance to coding, building Netlify's dashboard and DevRel strategy, and helping define the Jamstack movement.
Episode Summary
Brian Douglas traces his path from a finance degree and a sales job into programming, sparked by building a church discovery app while his premature son was in the hospital. He discusses the bootcamp landscape of the early 2010s, the value of having a concrete project idea when learning to code, and how specialization matters more than chasing trendy languages. The conversation shifts to how Brian discovered Netlify at an Ember meetup in San Francisco, deployed his blog there, and was eventually recruited as employee number three after impressing the co-founders with his consistent content output. He details the DevRel strategy he organically developed at Netlify — targeting bootcamps, meetups, and conferences simultaneously — and how the team deliberately prioritized the dashboard experience over the CLI to reach a broader audience. Brian recounts how the term "Jamstack" was adopted and promoted through the podcast, meetups, and marketing materials, turning a niche concept into a recognized movement. The episode closes with his current work as a staff developer advocate at GitHub focused on Actions, his Open Source Pizza project, and his advice for senior developers to make themselves available as mentors to increase diversity in tech.
Chapters
00:00:00 - Brian's Path from Finance to Programming
Brian Douglas opens up about his unconventional route into software development. He graduated with a finance degree in 2008, right as the market crashed, and ended up in IT equipment sales before deciding to learn to code. The catalyst was the birth of his premature son, during whose 11-week hospital stay Brian conceived an app idea and taught himself Ruby on Rails through free online resources and an early online learning platform called Bloc.
The conversation expands into a broader discussion about bootcamps, MOOCs, and how aspiring developers should choose what to learn. Brian's practical advice is to look at local job markets before committing to a language, while Chris Burns argues that finding a language that fits your mental model matters just as much. They explore how different bootcamp graduates end up on wildly different trajectories depending on their aptitudes and interests.
00:06:01 - Specialization, Mentorship, and Knowing Your Goal
The hosts discuss why having a clear goal matters more than simply completing a bootcamp or degree. Brian shares an anecdote about a Hackbright graduate whose math background led a mentor to push them toward C++ and systems programming rather than the typical web development path, illustrating how understanding your strengths can shape your career. He emphasizes that people who reach out wanting to "get into computers" without a clearer vision often struggle.
Chris Burns offers his own hot take on university computer science education, questioning the practical value of learning sorting algorithms and database theory in isolation. Brian counters with a story about learning linked lists on the job during a payments engineering problem, arguing that concepts stick better when encountered in real-world contexts rather than abstract classroom settings. The discussion touches on how tools like Prisma abstract away database knowledge, which Chris calls both convenient and dangerous.
00:12:17 - From a Church App to the Jamstack
Brian describes his project "Choke" (putting the Y in church), a Yelp-style discovery app for churches that he built while learning to code. The project taught him valuable lessons about building real products, even flawed ones, and how churches resisted the review component. More importantly, it was a Rails app on Heroku, and the cost of hosting pushed him toward the Jamstack approach of free static site hosting once he discovered it.
The conversation traces how Brian's prolific blogging habit — two to three posts per week — led him to Netlify. When his previous hosting provider Divshot was acquired by Firebase and shut down, he attended an Ember meetup where Matt Billmann demonstrated Netlify's static site deployment. Brian was immediately hooked by the simplicity of connecting a GitHub repo and having Netlify infer the build command, solving a major pain point he experienced as someone still learning JavaScript tooling.
00:19:40 - Joining Netlify as Employee Number Three
Brian recounts the pivotal coffee meeting with Matt Billmann and Chris Bach that turned into a job offer. After a year of consistently publishing blog posts and podcast episodes hosted on Netlify, Matt reached out for a customer conversation. Over breakfast in San Francisco's Dogpatch neighborhood, the co-founders revealed they had just secured funding and wanted to hire Brian based on his work. He learned that Tom Preston-Werner was an early angel investor.
At the time, Brian's current startup was running out of runway, making the timing ideal. He joined as Netlify's third employee and unknowingly pitched what amounted to a developer relations plan during that breakfast meeting. The founders recognized the value of his ideas about community engagement, content strategy, and developer outreach, and encouraged him to execute that vision at the company, launching what would become a defining DevRel career.
00:23:08 - Building Netlify's DevRel Strategy
Brian breaks down the DevRel strategy he developed at Netlify, centered on achieving 30-second deploys and making the product accessible to everyone. A key strategic decision was prioritizing the dashboard experience over the CLI, differentiating Netlify from competitors like Vercel's Now tool, which was CLI-first. The dashboard approach opened the gates to developers who weren't comfortable with command-line tools, including the growing wave of bootcamp students.
His conference travel rule was strict: every trip had to include three activities — a conference talk, a bootcamp visit, and a meetup appearance. The bootcamp strategy was especially calculated: treat bootcamp cohorts like enterprise customers, get Netlify into their curriculum, and wait for graduates to become decision-makers at companies two or three years later. Brian also discusses how they leveraged external tutorial creators and platforms like Egghead to build deployment templates rather than managing their own template library.
00:31:04 - Security, Hosting, and the Jamstack's Staying Power
Brian shares a cautionary tale about a DevOps engineer who hosted a personal blog on home servers connected to a corporate VPN, inadvertently creating a backdoor that hackers exploited. This story serves as his belated rebuttal to Hacker News commenters who argued for self-hosting over services like Netlify. The anecdote underscores why managed hosting and proper separation of concerns remain important.
The discussion then turns to why the Jamstack has endured. Brian explains that the term was intentionally lowercased from JAMstack to Jamstack because the ecosystem outgrew the original JavaScript-APIs-Markup acronym. The real staying power, he argues, comes from the principle of separation of concerns and the fact that the approach mirrors what had been working for over a decade before being given a name. The Jamstack provided stability amid JavaScript fatigue by grounding development in proven build-and-deploy patterns.
00:42:12 - Diversity in Tech and Open Source Mentorship
Brian closes with advice on increasing diversity in the tech industry, directed primarily at senior developers. His core message is simple: make yourself available. He describes his own practice of fielding questions via Discord, coaching people on everything from code to office lighting setups, and consistently putting himself in positions where newer developers can access his knowledge and network.
He highlights his project Open Source Pizza, which encourages open source contributions and is preparing for a 1.0 revamp with new features and updated design. Brian emphasizes that open source provides free mentorship and networking opportunities for newcomers, from labeling issues to writing documentation. The key is creating welcoming pathways — a "kiddie pool" for learning alongside faster tracks for production contributions — so that projects are accessible to people at every level.
Transcript
00:00:00 - Anthony Campolo
Thing connected to the thing, to the thing, to the thing.
00:00:03 - Brian Douglas
Like a true professional.
00:00:15 - Anthony Campolo
Brian Douglas, welcome to the podcast.
00:00:18 - Brian Douglas
Thanks for having me. It's quite the honor.
00:00:21 - Anthony Campolo
Thanks. That's great to hear. You run your own podcast in the Jamstack realm as well, Jamstack Radio, which was one of the very first podcasts I was ever on. It's great to have you here because we want to talk about things you're working on today, but also what you've worked on in the past and how that fits into this whole story of the Jamstack.
I really enjoy the history of these different ideas and projects, and I've enjoyed getting to know you and talking about these things because you go back to basically the start of the Jamstack in a lot of ways.
Before any of that, let's get into how you first learned to code, because you have a cool story that really resonates with me. I think our similar journeys are why you wanted to kind of help me out when we first met.
00:01:17 - Brian Douglas
I have a degree in finance. I could start with that. I always tinkered with computers, never really did the whole computer science thing or cared to look down that rabbit hole. I didn't focus on that because I didn't really think of it as an opportunity for me.
So I got my finance degree and graduated in 2008 when there were no jobs. The whole market had crashed, at least in the US, and I think it trickled down everywhere else in the world. So I took a sales job, sold IT equipment, and then fast forward, eventually hated that and learned how to code. I had my first kid, and we were in the hospital because he was premature, and I had an idea for an app I built. I learned how to code from a lot of free tools, mainly Ruby on Rails, like the Rails Guides. There was so much content. It was around the time of Dev Bootcamp just kind of launching. Eventually I connected to a bootcamp.
[00:02:07] An online bootcamp called Bloc. I had a mentor that I connected with as well, and I took a job in Orlando, Florida, to do Ruby on Rails work full time. And that was in the course of seven months, from my son being born to taking a job.
00:02:22 - Anthony Campolo
That's awesome, and I'd really love to hear a little more about the boot camp experience because I went through a boot camp and it wasn't a Ruby on Rails thing at all. It was this super JavaScript-heavy, front-end focused thing.
When I talk to people who did boot camps years ago, the common thing is that they learned Ruby on Rails or something like Ruby on Rails. I know some people learned Django or something. I'd be curious to know if you would still recommend someone learn Rails today coming up, or if you think it makes more sense to jump straight into JavaScript, or how you think people should approach that if they're looking at some of these different boot camps in the past that are available.
00:03:05 - Brian Douglas
Some clarification as well: when I joined Bloc to learn, they didn't actually classify themselves as a boot camp. There were no real companies other than Dev Bootcamp who called themselves a boot camp. Everybody called them MOOCs, massive online open courses. I think Codecademy was one of the earliest MOOCs that were successful. There were a lot of them before then.
There were boot camps. Big Nerd Ranch was a boot camp as well, but it was super expensive. Maybe you'd have 25 people show up in Atlanta or Silicon Valley and do the boot camp all in person. That wasn't very accessible to me, to go learn iOS at Big Nerd Ranch. What attracted me to Bloc was the fact that I could do it from home, and it wasn't a class-based or cohort-based setting. It was you and your mentor. You'd basically link up one to two times a week, go through the curriculum, and then meet with that one person, for reasons that didn't really scale, to the point where Bloc ended up getting sold.
[00:04:01] That was probably the best experience for me because I could read documentation, I could do the Rails Guides. I just could not get over weird networking things or Ruby version management. Those are the things you don't see in the tutorials because everybody gives you the guided path. So that was my experience. It was quite different from what you got with your bootcamp.
But the question around should you learn Rails, is it good for you? I would honestly say you should check what jobs are in your area. If you're not looking to move, look at what developer jobs exist and you should learn whatever you can get a job with, because you set yourself up for success. So if it's Java or .NET, or if it's Rust or Fortran, you should probably do that research before you jump into it. Or if you just want to build a project and not get a job, then go ahead and do whatever you want.
[00:04:56] I think Rails served a purpose. It has a lot of maturity in the ecosystem, so it's not as exciting as JavaScript. When you're trying to sell bootcamp students on spending thousands of dollars, it's going to be harder to sell a bootcamp student on Rails unless you're in Boston where there are lots of consultancies doing Rails, or New York, or San Francisco.
I think you can't go wrong with JavaScript, but with JavaScript there are so many undefined paths. One of the things I like about both of you being connected with Redwood JS is the structured path to plug and play, get things embedded into a project, and then ship. If you really want to succeed in a bootcamp, you want to be able to specialize. If you're going to specialize in e-commerce, Shopify stuff, or WordPress, or serverless functions, or GraphQL, that's going to be the distinction between you getting your job versus the rest of the people trying to do the bootcamp thing. That's just my personal opinion. Put the Doogie sign on that and send it away.
00:06:01 - Christopher Burns
This is my hot take: bootcamps and university degrees are useless for finding your programming language. And I say yours because everybody has a preference. When I went to university and studied computer science, I touched JavaScript in 5% of the modules. Have I touched any of the other languages that I got taught at university since? No, of course not. They're not my languages. I'll never program in them.
So it comes and goes and everyone's different. It isn't only where there are jobs, and I totally agree with you. It's also what suits your mental model, like C++ and C#. They're not my languages. They're great at certain things, but not my thing. And JavaScript is that language. That's perfect because it's flawed.
00:07:00 - Brian Douglas
To that point, I've met an engineering manager at Webflow now who used to be managing at Netlify as well, and they were a bootcamp grad. They went through Hackbright and eventually got pushed to a different place than most other people in Hackbright were getting pushed into, like web dev.
Their background was a math degree and they were on the track of doing professional math teaching or university. But they took a gap between getting, I don't remember the exact story, so I don't want to name them or out them. Basically they took a gap, traveled on the West Coast, started doing a bootcamp, did the bootcamp, and their mentor found out they liked math, so they pushed them to C++ and systems programming. They absolutely excelled in it to the point where now they do Rust and Go and stuff like that. Not the traditional bootcamp evolution of you do a web project and rebuild a todo app.
[00:07:58] They were building systems integrations, and there aren't proper boot camps for that. You would learn that probably in university, but that wasn't their degree. So knowing what your aptitude is matters. Some people love styling and design and CSS, pulling out a Figma and converting that to React components. Some people like connecting APIs. Furthering your point, understand what your ultimate goal is and what you're looking to specialize in.
If I was a mechanic, I'd probably have a specialization of like, I know American cars, or I know sports cars, or I know boats, or I know buses. You have to know what you're trying to get to and what you're trying to move towards. A lot of people reach out to me like, hey, I need help, I need a mentor, I want to get into computers. Usually that's a red flag if they don't know computers. Do you want to code? They say, oh yeah, sure, computers. So what do you want to do with it?
If the answer is hard to pull out, I don't have the bandwidth to go on the journey with them to eventually figure out, okay, you said computers, but you probably should just work at the Apple Store because that's what computers are. Programming is probably not for you. I've gone through enough conversations and mentored enough people to know that if you're just trying to get the certificate, if you're just trying to graduate the bootcamp so you can get the job, you're doing it wrong. You should go in knowing you have some sort of goal, some sort of excitement, or try to figure it out quickly and learn that.
I think that's why bootcamps have succeeded and failed, because a lot of folks who did bootcamps were career changers who were able to understand what the goal was.
[00:09:40] My goal was to build an app, not to get a job, so I understood going in. You have some sort of goal as opposed to being 18 years old, starting college, having fun, learning life, learning how to pay bills. You might not as easily succeed, and it might take a little longer, but you have to be a little more ambitious.
00:09:59 - Christopher Burns
My favorite thing my university lecturers always say, and I still think is a bit rubbish, even to this day, is: it doesn't matter what language we teach in, we're teaching you the philosophy. And it's like, how many times do I care about the 20 different ways to sort an array? Most of the time a bubble sort is probably good enough. That's a whole module that they test you on.
00:10:26 - Brian Douglas
Yeah. And as a founder of a company, you'll probably just hire somebody if you have that issue and need to optimize performance. You don't need to pull up your sleeves and start looking at the plumbing of the code and figure out how to get this algorithm.
00:10:39 - Christopher Burns
Figure out which O notation it is. Is it big O? Is it little O?
00:10:44 - Brian Douglas
It reminds me of a situation because I don't have a data structures and algorithms background. I didn't learn that in the bootcamp, but I remember distinctly sitting as a junior engineer at a company and we were trying to solve a problem. It was payments, and payments are always kind of messed up. Every time we try to give people legit data, someone on the engineering team was like, "Linked lists," and I was like, what's a linked list?
They explained a linked list to me and it made sense. I know what a linked list is because of that one situation. It made sense that you want to have your records attached to each other like a little train so that if you do have something that fails, the whole chain fails or alerts you. That was a concrete example for me. Now I'm never going to forget what a linked list is, but when you try to explain it to me in philosophy terms, I'm like, okay, I could pass the test, but I'm not going to be able to pull this out in a conversation.
00:11:43 - Christopher Burns
One of the things I find really interesting, and it can be controversial, is databases. I did a whole module on databases at university and I don't really know that much in the end.
00:11:57 - Anthony Campolo
Oh, we did.
00:11:57 - Christopher Burns
I know tools like Prisma. They remove all knowledge of relationships or designing databases, and it's very dangerous. But that's the way we live these days. Dangerous. We know all the abstractions and none of the philosophy.
00:12:17 - Anthony Campolo
This is a good segue to the type of work that you were doing to get into the Jamstack. I was listening to some of your old podcast interviews last night and learned about a project you created called choke, which put the Y in church. Could you talk about what that was?
00:12:37 - Brian Douglas
That was the project I started putting together when I was in the hospital with my son. If anybody wants to learn about that whole story, GitHub.com README has me talking about that experience and how I learned how to code. It was an idea. We were sitting in the hospital. My son was 11 weeks early, so that's micro-preemie. It's extremely early. Twenty-nine weeks out of 40 is extremely early. So we were there for 11 weeks.
For emotional and spiritual consolation, we wanted to go to a church. But when you Google church in Tampa or church in New York, your results are pretty awful. Awful as in not specifically because of church, but because you don't know what kind of church you're getting into. Not every church is the same church you're looking for. If I wanted this type of Christianity with this sort of flavor of hymns or music and this type of connection, there was no filtration system to be able to figure that out.
[00:13:37] It was sort of a waste of Sunday to go sit in the back and see if it's good for you. If it's not, run like fire. But anyway, that was the app. It was basically Yelp for churches, and it was a good structure to learn how to code something because I had an idea.
Another answer to your earlier question is: have an idea, even if it's bad. Build a bad idea because as you're building it, you'll learn why it's bad and you'll learn how to build it. So you can take that to the better idea next.
That's what I did. I built the idea. I tried starting a startup and found out it was Yelp for churches. There was a review component, and I found that churches aren't really cool with reviews because one bad review could hurt the church. They try to keep everything in the positive light for whatever reason. I kind of like seeing both sides, but it didn't work out.
[00:14:29] At that time, I was figuring out that no one actually wanted to talk to me about this project, and I found that I could get a job doing it full time.
But to your point about the Jamstack, that was actually a Rails app built on Heroku, and that same structure is what I brought to building my future projects. The thing that attracted me to the Jamstack was the fact that there were a lot of solved problems.
You mentioned earlier in the intro that I've been around since the beginning of the Jamstack. Jamstack is a term, and I'm sure you've probably talked about this in the podcast, but it's a new term applied to an old concept. People have been doing Jamstack since the beginning of the internet, separating your database or accessing your backend API from your static HTML site.
When I figured out that it was cheaper and I didn't have to pay $7 a month for Heroku, because Heroku is still $7 a month, I didn't make that much money. $7 was a lot to me. I was hooked because I could host my front end for free, I could host my back end for free, and then I'm good to go.
00:15:36 - Anthony Campolo
That's funny what you're saying about the Yelp for church, because this is kind of how Redwood started. Tom wanted to make a Yelp for children's playgrounds, and that was Der Spielplatz. That was the test repo that eventually led to what became Redwood, which is pretty funny.
I want to hone in on what you were saying about how you started with Rails and then went more into the Jamstack area. I think a lot of this is the connection of where you're working and who you're working with. So I'd be curious to know how you first met Matt Billmann and how he fits into this story.
00:16:17 - Brian Douglas
From the beginning of my journey to programming, I started a blog and I would write a blog post 2 to 3 times a week. If I learned git stash, I'd write a blog post about it, or if I learned how to do geolocation with the Rails gem, I'd write a blog post on it because I wanted to remember how to do it next time I had to do it again. That goes back to the point of wanting to learn the bad idea so I could build enough structure to learn how to do it the right way for work or for my next thing.
That blog I hosted on Divshot, and Divshot is no longer around. It got purchased by Firebase, which then got purchased by Google. It's now Firebase Deploy. But the real story is Divshot got purchased by Firebase. They told everybody, in three months you have to take all your stuff off and migrate somewhere else. At that time I was pretty new to programming.
[00:17:09] Only a couple years in. I had never done any migration of anything ever. I put stuff on stuff, it lived there forever. I paid the domain every year for three years, and it just worked. When it was like, hey, you need to move your stuff, I was like, wow, I don't even know how to begin. Even though at the end of the day it was just a static site. It was an Ember site. And I also had a Middleman blog as well.
That month, a week or two later, I was learning how to deploy it somewhere else and looking for other tools. I tried Heroku, but it seemed kind of silly to pay $7 a month to keep it always up. I went to a meetup at [unclear], where I recorded my podcast, and they had a meetup specifically on Ember. It's actually the Ember meetup of all things because I was trying to do a lot of Ember at that time back in roughly 2015. At that Ember meetup, the second speaker was Matt Billmann, and he was talking about this new way to deploy static web apps.
[00:18:08] If you have an Ember site, you could do Ember build and use a build command, which at that point I was like, wow, build command. Yeah, I know about that. I didn't know very much about JavaScript or NPM at the time, but I knew about Ember build. Then you could host that onto Netlify, which was a tool, and I was hooked. So I moved all my stuff to Netlify. It just worked.
What Netlify did is they took your GitHub repo, inferred the language to framework, and then did the build command for you, which was super helpful for me because when I started using regular JavaScript apps and some Node stuff, I didn't know anything about build commands at all. I was mainly doing Ruby, and I was tinkering in JavaScript. So once I figured out I could get JavaScript apps up and running, I started learning React as well.
[00:18:56] I even went up to Matt and talked to him. I deployed my site, ran my site for my blog and my podcasts, my other podcast, It's This Developing Story, and I hosted them on Netlify, both Ruby static site generators. A year went by of me constantly writing a blog post 2 to 3 times a week and shipping a podcast every week. Then I got an email from Matt that said, hey, I'm reaching out to some of our customers and we've been reading your blog. We want to reach out to you to learn more about what you're working on and what you like about Netlify.
I was like, okay, cool. He's like, hey, do you want to come for a coffee? We're also in San Francisco. I was like, oh, that's weird. So I went and grabbed coffee with them and was like, hey, nice to meet you. We got coffee.
[00:19:40] At that time they had a contractor who was doing some content as well, and they had just hired their infrastructure lead, who's still there. They're like, okay, we'll get coffee across the street. So we're in the Dogpatch, where Netlify's offices were. I guess they don't have their office there anymore. They recently went 100% remote.
Coffee turned into breakfast. We had a conversation about the product, what I liked about it, and my blog. Probably 35, 40 minutes into it, I'm like, so are you meeting with all your customers and buying them breakfast and chatting them up? Chris was there, the co-founder, as well. And they looked at each other. They were like, actually, you know, we're actually looking. We just got funded.
At the time, back in 2015, not a lot of startups were getting funded. I knew that because the startup I was working at could not get their next round of funding. So the entire Silicon Valley had kind of taken a dip. It was shortly after Facebook IPO'd. Anyway, doesn't matter. What I'm getting at is that it was hard to get funding.
[00:20:25] So I was like, oh wow, that's interesting because I know personally that it's hard getting funding. And they're like, yeah, well, we got funded and we're actually looking to hire a team. We've been reading your stuff this past year and kind of want to hire you because you're working on the same code that we're looking to help develop our dashboards at Netlify.
They also mentioned Tom, creator of Redwood and co-founder of GitHub, was one of the first angel investors as well. So I'm like, oh wow, that's interesting. It seems like you have stuff going on, and the job I'm working at is about to go under. So yeah, sure.
[00:21:10] Let's do this thing. I ended up doing the interview process, taking the job, and switching over to Netlify, working full time as a front-end engineer, really empowering people in the Jamstack. That was my introduction into the term Jamstack, because that's when they pitched me at breakfast. I'm like, oh yeah, it makes sense.
Actually, the other thing I mentioned in the meeting is I pitched them on how to build out a developer relations plan. I didn't realize that was a developer relations plan. It was just my ideas that I was giving them for free. And they were like, oh, cool. You should do that here. And that's what I did.
00:21:41 - Anthony Campolo
What number employee were you?
00:21:43 - Brian Douglas
I was number three. I used to say number five because I always included Matt and Chris in the number. But I guess you're not supposed to include the founders in the numbers. So I have now adjusted to say employee three and customer number 8600 or something like that.
00:21:59 - Anthony Campolo
Yeah, the DevRel stuff is especially interesting. This is what I've really enjoyed getting to connect with you on because I'm in DevRel also. When I was coming up into this whole world, I was meeting people such as yourself. There are so many things you were already doing that I could see and that made sense. I was like, that's a good direction to go.
But it's funny because so many people who get into this world, it's so intuitive the way they go about it. As you were saying, it's like you never even knew that DevRel was really a thing until you were already doing it. You kind of fell into it and it made sense to you, and you understood why community was important and why you'd want to go out and advocate for these technologies. But having it be a formal role is a whole different thing.
We'll also talk a little bit later in the episode about how this all connects to your current work. But when you were getting out and communicating the Jamstack in the first year or two that you were doing this, how else were other people thinking about the DevRel stuff they were doing at maybe similar or different companies?
00:23:08 - Brian Douglas
I do have to preface this as well. I never considered myself a developer advocate until a year before I left Netlify. I always figured I was just an engineer who liked writing blog posts, who liked talking about strategy and business with the co-founders of Netlify. I also did mention I was getting my master's in business when I was learning how to code, which was also the catalyst to [unclear] and also to learn how to code to build other projects. The business side of it, I mostly get.
My strategy has always been: get the stuff in front of the people and get a reaction as quick as possible. A lot of the stuff we really focused on was: how can you deploy Netlify within 30 seconds? Thirty-second deploys was the focus when I was there, and they knocked it out of the park.
[00:23:56] It wasn't just me. It was the engineers. It was the infrastructure team. It was the entire 12-person team. By the time I really started getting the groove, we all figured it out and we focused on that.
I didn't really pay attention to a lot of other folks who were doing DevRel, so I can't speak on what other folks were doing. But I knew a lot of other companies like Parse. They basically got acquired, they disappeared. There were quite a few other companies. Anyway, it doesn't matter what other companies are, but they all have since moved on or are not around anymore. The one that does come to mind is Vercel and the Now deployment tool.
I think the conscious decision we made at that time is that Netlify had a CLI since the beginning, just like Now. Now was running gangbusters with all JavaScript heads, all wanting to use Now because it was so beautiful. You type in now, you deploy it, it goes up and it works. The thing is that Now didn't have any dashboard. If you wanted to see your logs, it was all command line. So they hit a ceiling: we've got all the people who want to use the CLI, we should probably start working on a dashboard.
Netlify kept our CLI, but we overindexed on the dashboard and the user experience. So instead of typing in netlify deploy on the command line, you're finding your GitHub repo, clicking it, deploying it. From there you're going to a starter guide, clicking the Deploy to Netlify button, and then you have a Netlify site in 30 seconds. You could probably do it faster on the command line. We wanted to give that experience to folks who were not as JavaScript CLI focused. That opened up the gates to everybody else, which goes back to the plan I pitched at breakfast to Matt and Chris: attach yourself to a firehose.
[00:25:47] You attach yourself to a firehose, and that firehose was boot camps. Back in 2015, as you mentioned and as I mentioned earlier, boot camps weren't a thing when I started in 2013, but they were really a thing in 2015. App Academy, Hackbright, the big one, the Hacker School, Hack [unclear]. It's still around, but it was the premier program before Lambda School. This was the one everybody wanted to fly out to San Francisco to go and do.
What I'm getting at is boot camps were taking off. So my pitch to them was: go to every boot camp and get your stuff in the curriculum. That's an easy win. If you start giving boot camps attention and free hosting and support and treat them like enterprise customers, then whatever boot camp succeeds, you've attached to the boot camp. I think Lambda School was a couple hundred folks in the program per month joining. It was something insane.
[00:26:41] But that's every single month you're now attached to these new programmers. Not everybody's going to succeed, but the ones that do succeed then will go two or three years later and become hopefully senior engineers, maybe almost senior engineers, making decisions on the team. When it comes time to make those decisions, they're like, oh, I know Netlify. That should be the easiest way for us to deploy. It's got logs, SSL, single sign-on, and all this stuff you eventually care about. So you just indoctrinate all the boot camp students, and then in addition, obviously CS students as well.
My plan was essentially to summarize this: I would go speak at a conference, and every time I spoke at a conference, I did two other things. I did three things every time I traveled. Go speak at a boot camp and speak at a meetup. If I couldn't do all three, I would just not do it.
[00:27:29] That's how I activated my DevRel career. I got to talk at React Rally, and then I would go find a boot camp, find a meetup, and I would do those two other things. So every time I went to a city, we would land and deploy Netlify into the community.
00:27:46 - Anthony Campolo
The dashboard stuff is so interesting because this is embedded now in the Redwood tutorial. If you go through the Redwood tutorial, the way Rob walks you through it is he has you go through the Netlify dashboard, not the CLI. It's because, as you say, it's so friendly to anyone, whether you're an experienced developer, a new developer, or someone who's never really developed at all. You can click your way through it and probably figure it out.
This is going back to your influence on the Jamstack because building something like the Netlify dashboard means you are touching so many people's projects indirectly, and so many people who have learned to code and gotten into this. Did you have any sense of how important it was, what you were building when you were building the dashboard?
00:28:42 - Brian Douglas
No. Honestly, when I was working at Netlify, the biggest reason I said yes to Netlify is my last job was about to go under. They had no runway left, so I knew I was going to have to find a job anyway, so I might as well do it now. The other thing was they had such senior talent. The CTO came from Docker. Matt came from a lot of other startups as well. This was not their first try at it.
I was also learning all this extra stuff while just being at the company. Full credit goes to Rafa, the original dashboard designer. He is a whiz when he thinks about user experience and UI. He didn't have all the answers, but he spent a lot of time thinking about: if I click in, if I get through this wizard and click deploy or click to my GitHub repo, what's the next step and how can we take out steps?
[00:29:33] One of the biggest things I really missed was when you first started Netlify, you had a Stackbit integration. Stackbit being an actual company, you could get a template, like Sanity does this. So many other companies do this now in the Jamstack, where you get a template to deploy. If you don't have a site, you can pick a template, deploy a site, and manipulate it.
We had to make a decision to remove that from Netlify because most of those templates were awful. There were a couple standouts, but they were all over the place, and it wasn't a great experience. So we overindexed on people who already had sites to come and deploy. The other thing we did is we attached ourselves to Egghead teachers and other tutorial creators and had them build templates that would lead you to Netlify.
[00:30:22] So we stopped trying to manage our own templates and let other people manage them. As far as zooming out, I remember sitting in a conference and pitching somebody. Everybody asks you where you work, so sitting next to this person in the conference, I said I work at this company, Netlify. They were like, oh, what do they do? I was like, we're kind of like GitHub Pages, but if you took it seriously. That was my pitch.
Mind you, I work at GitHub and GitHub Pages is a great product, but that was my pitch back in the day. The person's like, well, why didn't you just use GitHub Pages? I was like, well, because Netlify adds so much more to it and I have a different pitch. For conflict of interest, I won't give you the full pitch.
What I'm getting at is that we would be on Hacker News, Netlify. We sort of lucked out of getting on Hacker News consistently, like six times in one year. It seemed like every other week at one point, just from launching features like deploy previews. In the Hacker News comments, you have the one reply guy that says, why not just put a server in your closet and then host your static sites from your house? It's much cheaper and you can control everything.
[00:31:04] I think as we're now learning what was the latest, there was a large conglomerate, a company we all heard of. It happened that you could VPN access into it from your home. So the person doing the SRE work from home also hosted their blog from home on the same servers. That's how the hackers ended up finding a backdoor into the company and getting access to data, because this DevOps person had their blog hosted in their own house.
[00:31:59] So that's my rebuttal to that guy from six years ago. That's why you don't want to host it on your own. Because it wasn't even the service; it was because the network was attached. Their Wi-Fi was attached to their VPN, and then they could sort of cross over.
So yeah, don't host your stuff at home anymore. Those days are over. Security is serious. If you don't want to do it yourself, get AWS or Fargate. But wait, which ones? The CDN doesn't matter. Who knows what AWS stuff is called?
00:32:30 - Christopher Burns
Isn't it just buckets?
00:32:32 - Anthony Campolo
Yeah, no, they actually have a CDN as well. It's CloudFront. That's their CDN.
00:32:37 - Brian Douglas
Yeah. Marketing, they got a lot of stuff. They got a lot of catching up to do. But basically what I'm getting at is I didn't really have the perspective of what we were working on.
The other thing is the podcast. I talk about this in a YouTube video I shipped a couple of weeks ago about the truth about the Jamstack. I saw a lot of people doing the origin stories of Jamstack and I was like, oh, I've got a story to tell.
The reason Jamstack took off is because at the time we chatted about it: should we call it Jamstack? This is a term that Matt was throwing around with Chris, and they were like, yeah, this makes sense, but no one's ever heard of it. If it expands out of JavaScript, APIs, and markup, then what's the answer to that? We doubled down when we started the podcast Jamstack Radio.
[00:33:20] We needed a name for the podcast. I was like, well, it should be Jamstack Radio, because Jamstack is the obvious thing that we're trying to pitch to get people convinced, to then deploy to Netlify. We went back and forth on it and eventually, yeah, let's just do that. So we renamed Jamstack Radio. Then we renamed the meetup in San Francisco from Static Web or Static Web Meetup or whatever to Jamstack SF.
Then the cards started to fall: okay, Jamstack gets a refresh, we're going to start using Jamstack in our marketing materials. By December, I started in the summer, and by December we were full on indoctrinating people about the Jamstack in all of our content. It was a nice place to educate people on how to build stuff, which leaned into me going to all these boot camps and colleges. I had a term that you never heard of. Let me explain it to you, which is Jamstack.
I could do some teaching, show you how to build your blog, your portfolio, get your first job. That was the pitch. I was walking to boot camps after doing conference talks and saying, hey, I'll stay a couple extra days, talk to your boot camp students. We'll teach you how to deploy your templated blog and portfolio site and host it on Netlify.
00:34:31 - Anthony Campolo
Yeah, that's great. Since we're going into the history here, it's good to point out some people always wonder who came up with the term Jamstack, and no one can ever give the answer because the person who created it has a really hard to pronounce name, who is just a random friend of Matt, whose name was Andreas Johnson, something like that. We'll link to that in the show notes.
Some other people were trying to call it the new dynamic. That was another popular term around at the time, and I think that dude lost the thought leader wars on that one, unfortunately.
00:35:05 - Brian Douglas
Yeah, I like the new dynamic too. We toyed with that being the name of the podcast as well. We also toyed with Modern Web too, the Modern Web meetup, which now Tracy from Star Labs owned that name and they do a lot of online content. We really wanted to call it the Modern Web podcast, but now they have a podcast. There are a couple different things.
This is also pre-serverless. Serverless came out the next summer as a term.
00:35:36 - Anthony Campolo
Yeah, that's so funny. You're not only in the Jamstack, you were also talking about serverless. You were talking about GraphQL and GraphQL wrappers especially. This is a good segue into the work you're doing now and some of the open source projects you're working on now. You've transitioned from Netlify to GitHub, and you also do a lot of cool stuff around GitHub's GraphQL API. I'd love a description of what you're doing now, how you see your role, and what kind of projects you're working on.
00:36:14 - Brian Douglas
My role is staff developer advocate at GitHub. Staff is a term or a level I had not heard about previously until I joined GitHub, and it's kind of popular and other companies are using it, but it's kind of the next step after senior. I am really focused on engaging GitHub users and teaching them how to use strategic features at GitHub.
One of the features I've been spending a lot of time on lately has been GitHub Actions. GitHub Actions is a way to automate your workflow to your heart's content. A lot of people stop at CI as a way to automate your workflow. So you just want to run tests. That's a great introduction.
But if you wanted to also run some integration tests, I wrote a Playwright script to take screenshots in different browsers of the deployed application, and also the staging application, to see what it looks like. You can also run tests at the time of a PR to see if your Lighthouse score has gone up or down.
[00:37:09] Lighthouse is normally what people use in production. You go run it and you write a bunch of notes and open issues. If you open a PR on my project and the score goes down, we have to have a conversation: do we really need this change? Or can we improve and get the score back to where it was at the time of PR?
I do that on the back of a Lighthouse action built by Jarvis and it hooks into Netlify deploy previews. So automation is pretty much the point of GitHub Actions: find a piece of something that's repetitive, the thing that you always do manually, and see if you can automate it.
00:37:43 - Anthony Campolo
Any questions, Chris, before we start closing it out here?
00:37:48 - Christopher Burns
Enough to fill another hour.
00:37:49 - Anthony Campolo
I know, right? It's incredible. It's ridiculous. This is going back to trying to tell people this whole story, and it's massive.
00:37:59 - Christopher Burns
The reason I like to be quiet is because I just derail the train. It's like, well, go right, 90-degree turn. One of my biggest questions is, why has the Jamstack stuck around to you? Because is it truly Jam anymore when everyone's now going to TypeScript? And that's not really JavaScript, but it's still JavaScript. And do we even use markup? Because I don't think I've ever used markup in the Jamstack.
00:38:31 - Brian Douglas
Yeah. The markup could be JSX. It could also be whatever you want to manipulate in your templates. At the time, Emmet was huge, and Jade was also huge back when we started using the Jamstack. The reason we went back and forth on whether to call this Jamstack is for that same question you just asked. Elm was also a thing that was pretty up and coming at the time. Elm being the compiled language from... anyway, it's so long.
What I'm getting at is, yes, JavaScript, APIs, markup. We're going to outgrow that term, which is why I think the Netlify team and the Jamstack org, and they should really create a foundation because I think it's been built big enough that a foundation could lead this, have also lowercased the A and M in Jamstack so Jamstack is no longer an acronym. That was intentional.
[00:39:25] It was something that they quietly shipped, but it really is because of that same question. We've outgrown JavaScript, markup, APIs still around. I think the real goal is separation of concerns. Knowing that it is okay to be a front-end developer, it's okay to be a back-end developer. It's okay to be infrastructure. It's okay to have your stuff in separate repos or separate folders. If you have a monorepo, it still could be the Jamstack.
There are ways. I know Blitz.js is a one-stop solution, but you can deploy your backend separately with Blitz. This takes a lot more extra effort, but it is a monorepo experience. Why has it stuck around? I think it's because we went to what was actually working ten years prior.
A lot of times we were going down a really weird path with JavaScript fatigue, a JavaScript ecosystem where we had the next thing, the next thing, the next thing, and people were loving it. Then other people are like, I'm going back to Python because this is insane. I can't keep updating my build system because something changed or we found out something's broken. It was a ramp on ramp to nothing because no one was building fast enough.
So with Netlify, we went to what was working in the build system and compiling down the static to the point where I could take that static site. I have a GitHub Action that I want to build, which is to rebuild Netlify with GitHub Actions. Mainly because this is where I sit today, but I can rebuild Netlify with GitHub Actions because all I'm doing is automating build processes. I can use GitHub's hosted runners to do that, and I could also set up different environments in GitHub as well, which is a feature not a lot of people are using. Not a lot of people are using GitHub Pages outside of open source documentation and standing up marketing sites, but it stuck around because it was a proven model.
[00:41:19] It was a proven model ten, fifteen years before. Instead of FTP directly into a server and get it up and running, you're now using Netlify instead. And now you see all these other options, like DigitalOcean point-and-click to a GitHub repo to deploy to a droplet. It's a beautiful experience, and I avoided DigitalOcean for years because I didn't want to get into a server and start clicking around trying to figure out what's going on and feel like a hacker.
That's not where I want to be. Back to your point, Chris, knowing where you enjoy being. Being inside a server and doing tmux is not where I want to be. Where I want to be is talking about the projects that are deployed, being able to talk about them, and getting people to sign up. I talk a lot. I'd rather do that than sit behind a computer screen trying to figure out why my SSL certificate is now expired one day late.
00:42:12 - Anthony Campolo
One more thing I want to ask before we close off here. I know you're really passionate about increasing diversity in tech, and I think it'd be really great if you could give our listeners any advice or wisdom, or how they can help in this mission to get more diverse individuals into tech.
00:42:32 - Brian Douglas
I imagine your listeners come from a number of different backgrounds. Some are experienced senior devs. Other people are just getting started. I would talk to the senior devs. The people who are already in the industry should make themselves available when they are available. If you do have availability, you could do a conference talk or speak at a meetup and then have a conversation.
I think the reason I'm here today is because people took time to mentor me and put themselves in a position where they can chat with me and teach me the stuff I didn't know how to do. That's constantly what I do. I put myself in a position. I've got a Discord. People DM me all day, every day about questions. I try to push them to a public channel, but they just DM me and ask me questions like, how's this or what about this?
I was coaching somebody on lighting for their office because they were like, oh, your lighting is really good. How do I do this? How do I do that? And I'm like, okay, let's open up the Zoom call and I'll tell you where to put the light and stuff like that. Then we'll get you halfway there.
Making yourself available. One thing that we didn't mention, but I work on this project called Open Source Pizza, and we're going to be doing a revamp. I just started talking to the designer to get a revamp for a 1.0 version because we never officially got 1.0. We'll revamp the UI, add some new features, and it's going to be a tool to encourage open source contributions, but also recommend as well. I think a lot of times open source is a great place to get started and get a network. Anthony, you're a case in point right now.
[00:44:04] Getting free mentorship and free networking just by adding labels to issues or creating documentation or starting a starter guide section in the docs, that's all available to people. It's just that not a lot of people know you could do that. So being able to set your projects up in a way that anybody can walk in, there's a path for people who just want to get issues closed or get their stuff working on their production site.
There's also a pathway for people to say, hey, I just want to hang out, have a conversation, learn, grow. Create the kiddie pool, create the place where people can have that conversation and learn slowly, but then also give them the GitHub repo where they can fast track into getting this deployed to production.
00:44:45 - Anthony Campolo
Thank you so much, Brian. You have been such a great mentor to me. Everything you said about making yourself available, you have done that for me and I really appreciate that. I'm glad to get the chance to give you a chance to tell your story. Because I think you really have done a lot in the Jamstack. And so if you don't know now, you know.