Building Online Communities with (the) David Price
David Price from the Redwood core team discusses his path from philosophy and engineering to open source and how Redwood balances developer learning with community.
Episode Description
David Price from the Redwood core team discusses his path from philosophy and engineering to open source, and how Redwood balances developer learning with community building.
Episode Summary
This episode of FSJam features David Price from the Redwood core team in a wide-ranging conversation with hosts Anthony Campolo and Christopher Burns about the intersection of technology, learning, and community. David shares his unconventional journey from mechanical engineering and philosophy studies at Oxford to eventually finding his way into the JavaScript ecosystem and open source work, driven by a persistent interest in how technology affects people. The discussion shifts into how each host first encountered programming—from 1980s pixel art to Minecraft modding—before turning to the challenges of learning modern JavaScript development and how Redwood's tutorial-driven development approach tries to address them. The group explores the delicate psychology of learning, comparing it to video game progression where developers need just enough challenge to grow without enough frustration to quit. They discuss real pain points like configuration complexity, poor error messaging, and deployment headaches that drive developers away from frameworks. The conversation closes with reflections on open source sustainability, the value of cross-framework collaboration over competition, and David's vision for measuring Redwood's success not by GitHub stars but by the human connections and opportunities it creates—teasing a future episode on the ethics of technology.
Chapters
00:00:00 - Introduction and Meeting David Price
The episode opens with Anthony teasing themes around community organizing and full-stack JavaScript before the hosts welcome David Price from the Redwood core team. Anthony expresses gratitude for David's mentorship in helping him contribute to Redwood, calling him the person he's spoken with most on the team.
David responds warmly, noting how rewarding it has been to watch both hosts grow and use Redwood as a springboard for talks, articles, and podcasts. He emphasizes the genuine pleasure the core team takes in seeing community members flourish, setting a tone of mutual appreciation that anchors the rest of the conversation.
00:02:41 - David's Academic and Career Background
The hosts dig into David's background, starting with his philosophy studies at Keble College, Oxford, and his earlier mechanical engineering degree from the University of Colorado Boulder. David describes feeling dissatisfied with engineering work—his first job involved Boeing landing gear struts—and pivoting toward bioethics as a way to connect technology with its human impact.
Christopher draws parallels with his own experience studying computer science at the University of Lincoln, where formal coursework in C and C++ never resonated the way self-taught JavaScript did. The two bond over the tension between what universities teach and what actually proves useful, questioning whether higher education prioritizes marketability over genuine learning.
00:07:12 - Early Programming Experiences and JavaScript History
Anthony asks David how he got into programming, sparking a round of origin stories. David recalls drawing pixel art by hand on grid paper and typing X-Y coordinates into a computer in the 1980s, while Christopher shares that his first programming happened inside Minecraft. The group traces JavaScript's evolution through jQuery, MooTools, CoffeeScript, and the module system wars of CommonJS versus AMD.
These personal stories illustrate how differently each developer entered the field and how rapidly the JavaScript ecosystem has changed. The conversation highlights that despite vastly different starting points and eras, the common thread is a desire to build things and the satisfaction that comes from making something work on screen.
00:11:09 - How David Met Tom Preston-Werner
David recounts how he came to know Tom Preston-Werner through family connections in San Francisco, where his brother-in-law was an early GitHub employee. Their friendship began at a climbing gym in 2013 and grew over years of casual conversations about car dashboard design, humanitarian work, and technology's potential to help people.
David describes how he and Tom occupied complementary mental spaces—David thinking twelve steps ahead about technology's societal effects, Tom focused on practical next steps. Over beers, they discussed everything from social impact startups to what would eventually become the Hammer framework, later renamed Redwood, born from Tom and Peter's frustrations with building in React.
00:17:56 - Learning Redwood and the Tutorial-Driven Approach
The conversation shifts to how newcomers experience Redwood. Christopher explains that his prior knowledge of Apollo, Storybook, and React made adoption easy, while Anthony describes coming in without that background but still being able to use the framework effectively. They compare it to driving a car versus being able to rebuild one—both valid entry points.
Anthony then describes tutorial-driven development, where the team designs how they'll teach something before building it, ensuring the end product is learnable by design. The group discusses how the tutorial creates a satisfying on-ramp that mirrors video game progression—providing enough empowerment to keep learners engaged while gradually increasing complexity, and how a second tutorial is now being developed to guide users past the initial learning phase.
00:31:17 - Pain Points, Error Handling, and Developer Experience
The discussion turns to the frustrations that cause developers to abandon frameworks: configuration headaches, opaque error messages, and deployment issues. Christopher shares his wish for Redwood to provide helpful error links the way Next.js does, and Anthony mentions that Rust and Elm compilers are praised for teaching developers through their error messages.
David acknowledges these are real infrastructure challenges as the Jamstack evolves toward fuller stack capabilities, citing his own struggles with Prisma binary sizes blowing up API deployments. Christopher adds his ongoing Stripe webhook issues across Vercel and Netlify, illustrating how deployment complexity compounds the difficulty of building applications and underscoring the need for better diagnostic tooling and IDE integration.
00:38:23 - Community, Competition, and Open Source Sustainability
David pivots to the community side of Redwood, emphasizing that the human impact of the project matters as much as the code. The group discusses cross-framework collaboration, agreeing that frameworks like Blitz and Remix are tackling similar problems in different ways and that mutual inspiration strengthens the entire ecosystem rather than threatening individual projects.
They also address the paradox of open source success: popularity brings more demands without a built-in business model, often punishing maintainers for their achievements. David shares that when investors ask about Redwood's metrics, the team cares more about measuring how many people accomplished something new because of Redwood than counting project installs or GitHub stars—a philosophy that ties back to his lifelong interest in technology's effect on people.
00:48:00 - Ethics Teaser and Closing Thoughts
The episode wraps with David offering a teaser for a future conversation on the ethics of technology, posing the question of what kind of team and behavior would be necessary to build products that genuinely unlock human potential. He references Aristotle as the original source for these ideas, drawing a line from ancient philosophy to modern open source values.
Anthony recommends Nadia Eghbal's book on open source communities and introduces Vygotsky's circle of competence as the formal term for the learning philosophy David described throughout the episode. The hosts thank David and express enthusiasm for a follow-up episode, closing with David's reminder that the relationships formed through Redwood are the most lasting outcome of the project, regardless of what happens to the framework itself.
Transcript
00:00:00 - David Price
There's this really interesting interplay with Redwood. We spend a lot of time talking about community and organizing an open source project. That's a major theme. The other major theme is this full stack JavaScript framework. As we start doing more with the data side and get more into full stack, the kinds of things you can do at build time and have visibility into just need to get a lot better. As a friend of mine said, your current prototype is already outdated.
00:00:44 - Christopher Burns
Welcome back to FSJam. We have an amazing guest on today from the core team at Redwood, David Price. With me is Anthony.
00:00:55 - Anthony Campolo
Hello, hello. And remember, it's the David Price.
00:00:59 - David Price
The "the," David? It turns out there's a lot of David Prices, as you may now know.
00:01:04 - Christopher Burns
We've got some really interesting subjects to ask David today. Some of them technical and some of them about him, because as we know, a developer is two-sided. There is them as a person and the code they write. And sometimes, to truly understand their abilities, you have to understand where they excel. So let's get to it.
00:01:29 - David Price
I'm excited and no pressure, right, Chris?
00:01:31 - Christopher Burns
No pressure.
00:01:32 - David Price
It sounds fun.
00:01:33 - Anthony Campolo
I'm really happy to have you here, David. You've really helped me get into the fold in terms of the community. When it comes to contributing to Redwood, I think I've talked to you more than everyone else on the team, probably combined. So I really appreciate you being so generous with your time and helping me learn so much and get spun up. You've been a really great mentor. I want to thank you for that.
00:01:54 - David Price
Of course, you're welcome. It's truly a pleasure and it's been fun to watch you. Well, both of you, in different ways and now working together, but just really take off. I don't think we envisioned this quickly in the Redwood project that we would see so many people having the opportunity to use Redwood as a springboard of sorts to do other things. I will say this again and again, so I hope it never sounds trite, because it's a deep sincerity we all feel. It's really a pleasure. It's so much fun.
00:02:24 - Anthony Campolo
It's been great for me. And like you said, as a springboard, it's led to me getting podcast interviews, doing meetup talks. I've had published articles now that I've been paid to write about Redwood. It's really been an incredible thing.
00:02:37 - David Price
That's incredible. That's really fun.
00:02:41 - Anthony Campolo
We want to get into not only what you do today in Redwood, but I really want to learn a little bit about your background. What have been the influences that have led to you operating the way you do? I was taking a look at your LinkedIn and you studied philosophy at Oxford.
00:02:58 - David Price
I'm sorry about the LinkedIn thing. I did study philosophy at a place called Oxford.
00:03:03 - Christopher Burns
Oxford, UK, or some place in America called Oxford, because that confuses many British people.
00:03:10 - David Price
There's a place for all the major cities in the world in Texas somewhere. We've got Paris, Texas. That's a very important question. It was actually Oxford, UK. I was at Keble College, so that's legit, right? Because if you do the Oxford thing, it's not Oxford, that's just the place. But it was Keble College. A little bit of backtracking there. My undergrad work was at the University of Colorado Boulder. My emphasis was biomedical engineering. My major was mechanical engineering. It was a really dissatisfying degree in the sense that I learned really well, but every university is kind of feeding the industry around it in the States. There wasn't really this sense of design and holistic design for the engineering school at the time. That's changed a lot since then. But the thing I loved about building stuff was how technology could be applied to help people. I didn't really get that. My first job was actually working on landing gear struts on a Boeing AWACS.
[00:04:01] How fun is that? And I thought, this is not what I want to do with my life. Bioethics became something of interest. It had been of interest for a while, but it was kind of like, well, maybe I could leverage this technology degree. I now have to find a way to really connect it with people and the human element. It's the intersection of the two, technology and how it intersects with people, that has always been an interest of mine, especially how can we help people. I just didn't find that. So I thought ethics was going to be the thing. I started down the career path. I did not get a degree from Oxford, actually. I came back and continued graduate work at the University of Colorado. It was really interesting. I found out ethics was basically going to lead to two career paths at the time for me, or so I thought. I could be a professor or I could be in healthcare compliance at a large administration facility, and I didn't want to do either of those things.
[00:04:47] So I hit the eject button. But I still care deeply about those kinds of things. Early days. It is true and I love the Bodleian Library. I have never felt so smart just sitting in that place with all the books. Have you been there, Chris? The Bodleian, am I even saying it? You say it. I want your accent to say it. Say the Bodleian.
00:05:07 - Christopher Burns
The, the, Boolean. Boolean? I don't, I don't...
00:05:11 - David Price
Bodleian. Okay, maybe you don't. It's just the library in Oxford and it's got history. We don't have these things in the States. We don't have a thing that's hundreds of years old. And that's what it was.
00:05:21 - Christopher Burns
I went to a university called University of Lincoln, Lincoln, UK, not Lincoln, Nebraska. It gets confused quite often.
00:05:30 - David Price
Hey, where I was born, you would never guess. Lincoln, Nebraska. I'm that guy.
00:05:36 - Christopher Burns
You would not be surprised how many Google searches probably go from the UK to Lincoln, Nebraska. I just want to back what you said about college and university. At university, I studied computer science. A lot of the languages that I learned were heavily based in C, C#, and C++, and they just never resonated with me. I got that you could program computers and do cool things, but I would always go back to my crutch of JavaScript. I learned JavaScript before I went to university, and it was my go-to language. Sometimes you're privileged enough to go to college, but then you sometimes find out that it really disenfranchises you. When I came back, I felt like I learned not much from university because the skills I had for JavaScript, I very much self-taught them. That's a really interesting path as well.
00:06:28 - David Price
I've spent a lot of time talking with you about that, especially now when people ask you for advice, and I'm sure it happened to you. Should I go to college? What should I study? And isn't it a tragedy of the commons, if you will, that education is not as much about learning to learn anymore as it is trying to make you marketable? It's hard. We need both those things to happen, but it took me a long time, Chris, to reconcile the value of a degree. It was really hard earned. I worked my ass off in college because I thought that was the way, that's what you're supposed to do. And then to get to the end of it and realize I didn't want that job. But did I learn how to learn? I learned Pascal, C++, because that was applicable to mechanical engineering at the time.
00:07:12 - Anthony Campolo
I was curious about this, how you got into programming. It sounds like you were someone who was doing programming as a way to accomplish things within your degree. I hear this story a lot from people who are in the hard sciences, and they learn things like R or they learn Python, scientific libraries and things like that. Were you doing statistical type work or were you more actually writing programs? How did you see what you were doing?
00:07:42 - David Price
I wish there was a better theme or a more linear journey to these things, but the first time I ever programmed, I'm a little older, was in the 80s in elementary school. I don't even remember what the computer was or what the program was, but I could plug in X-Y coordinates and a color and I could draw something on screen, and it just blew my mind. We're not talking about a high-resolution screen. I think the pixels were probably what would be now 16 by 16. That was a pixel. So I actually did the grid on paper. I drew out the picture on engineering grid-lined paper, and I went in and figured out all the X-Y. Could you imagine? It probably took me a month of just typing in X-Y coordinates.
00:08:22 - Anthony Campolo
It's so funny you say that. What that makes me think of, I once was watching a tutorial and it showed you how you could take the X-Y coordinates of your mouse position in the browser and set that to different pixel colors. So as you move your mouse around the X-Y grids, it changes the color of the background. That's the type of thing that I've learned today that parallels that.
00:08:42 - David Price
There you go. See, those skills are applicable.
00:08:45 - Christopher Burns
I'll go on record and say the first time I ever programmed was inside Minecraft. Does that show my age? I am 24. I was early on in the modding scene, so you can install mods that allow you to open doors and all that. And then I moved from that into building my first website with HTML and CSS. I remember HTML5 was this brand new thing that had this weird icon that was a shield, but no one even used it.
00:09:13 - David Price
That's amazing. And how awesome for Minecraft. I envy you for all the pain you were able to avoid getting to start with HTML5.
00:09:21 - Christopher Burns
But the thing is, you talk about pain. There's so many different languages that resonate so differently depending on how your brain works. I'm dyslexic and I find JavaScript just clicks with me. But then when I was in university and I had to write C++ and C#, it just never clicked with me as easily as JavaScript did. You would say that the industry is turning JavaScript into C# with TypeScript. That's not a good or bad thing, really.
00:09:48 - Anthony Campolo
I don't think anyone can control JavaScript. JavaScript does whatever it wants to do. Right now it wants to be more like C#. It'll hit a limit and it'll rebound the other direction.
00:09:58 - David Price
Around 2006 or 2007, there was a lot of thinking that JavaScript would eventually be abstracted away.
00:10:05 - Anthony Campolo
That's WebAssembly, right?
00:10:07 - David Price
It wasn't unpopular thinking at the time because the challenge then was JavaScript was becoming more powerful as a tool. The browsers were behind compliance, and compatibility across browsers was just terrible. Also, all these things you wanted to do with JavaScript. So the answer at the time was compile. Now we have Babel effectively, which is doing these things. But we didn't have Babel back then.
00:10:33 - Anthony Campolo
Back then would have been CoffeeScript.
00:10:34 - David Price
Yeah. Somewhere in there, jQuery was right there answering those. Do you guys remember, did anybody ever use MooTools? Come on.
00:10:40 - Anthony Campolo
I know about all these things just because I'm a history nerd. I didn't live through any of them, obviously. I find the whole history of JavaScript really fascinating.
00:10:47 - Christopher Burns
I lived through, was it target JS, where you used to basically take other people's libraries and compile them into modules yourself?
00:10:54 - Anthony Campolo
CommonJS is the module system that underlies Node. There's also RequireJS and AMD and all the module systems that battled.
00:11:04 - Christopher Burns
It could have been AMD. It's been so long ago. Three years.
00:11:07 - David Price
It does change quickly.
00:11:09 - Anthony Campolo
So let's get into how you came to Redwood. But I'm actually kind of curious, how did you first meet Tom?
00:11:16 - David Price
Oh, man.
00:11:17 - Christopher Burns
I think let's first preface it: who is Tom?
00:11:20 - David Price
Who is Tom? Tom Preston-Werner. Tom is a friend.
00:11:25 - Christopher Burns
Of Tom.
00:11:26 - David Price
And Tom.
00:11:27 - Christopher Burns
Well, should we just say he's the creator of TOML and call it a day?
00:11:30 - David Price
One thing I didn't know about Tom, and I've known him for quite a while, was until last year: oh, TOML. Tom's Obvious Markup Language. That was a good confession.
00:11:40 - Anthony Campolo
Tom's Obvious Minimal Language.
00:11:42 - David Price
Oh, minimal. Sorry. That was a good correction, over beers, back when you used to be able to hang out with people and have beers occasionally. So I met Tom. My work at the time brought me to San Francisco very unexpectedly. Most people don't have a family and then move to San Francisco. It's quite the opposite. You have a family while you're in San Francisco, and then you move and go somewhere else. So I was already swimming upstream. But in 2013 is when we arrived in San Francisco. Kind of a mundane story. My wife's sister's family, brother-in-law Tim, good friend and brother-in-law, he's a computer scientist, worked at GitHub, was an early employee there, and I got to know a lot of the early GitHub employees because of Tim. Tim and Tom were great friends, obviously, because there were just in the teens of people there at the time. So the first time I ever met Tom was at a climbing gym in San Francisco.
[00:12:32] I remember the first conversation we had. There were two things that struck me about it. One, we were in a car driving somewhere, and Tom and I spent most of the time being incredibly critical of car dashboards and how terrible they are. Can't they just do something right, and can't they all do the same thing? We were both whining about that. Tim, Tom, and I are in a car, this is 2013, driving somewhere. We're complaining about car dashboards and how terrible the user interface design is. And I asked Tom where his wife was. I wanted to get to know Teresa. Teresa is in northern Guatemala at the time with what would have been a one-and-a-half-year-old. Our children are roughly the same age, our oldest kids. Teresa was in northern Guatemala doing humanitarian work with indigenous people. And I'm like, she sounds amazing. I don't know, Tom, I guess you're okay. But this Teresa, she sounds like an amazing person.
[00:13:26] And it is true. I know she has a PhD in anthropology, and has done all kinds of work around the world for people. So we're just family friends. We lived five blocks away from each other for about three years. We never worked together. We've shared a lot of beers at pubs over time. I have pitched Tom... "pitched" isn't the right word. I have thrown so many crazy ideas at Tom. I'm about 12 steps ahead in terms of seeing things and wondering where things are headed. I'm just way too far in the future and connecting dots. Especially when I drink too much coffee, the connections just shouldn't really be there. Tom is very much the next step. What is practical? What can we do today? We just had wonderful conversations.
00:14:09 - Anthony Campolo
Were you thinking of building a big open source project then, before Redwood was even a thing? Like, eventually we're going to have some sort of crazy huge JavaScript open source project?
00:14:20 - David Price
No, that wasn't it, although that was Tom's vision. It's kind of fun. Over the course of going back three years now, some of the things in my career journey, two big questions for me, and I'll tie this into the conversations Tom and I were having. And again, this is conversations over beer, friends just noodling on what's interesting in the world. What are we thinking about? For me, it was starting to drift into something I've always been very fascinated by, because one of my many careers was as a consultant. Chris, doing what you're doing now, building software tools and applications for companies, thinking a lot about process, but really noticing something. There's ways to implement technology where the process is more readily receivable and acceptable to an organization, but getting a company to use a tool is infinitely harder than actually building the tool for them, which is hard in and of itself. Just getting them to figure out what they want is time consuming. I've always thought about what is the behavior around technology, and also how do you enable people to learn a technology.
[00:15:18] And then I started noticing the kinds of ways technology would change the processes and the people and the organization, depending on what it was doing and how it was implemented. As recently as four or five years ago, I started thinking more about the cause and effect of the technology products we have, and obviously now it's a really hot topic. But five years ago, we're getting into mobile devices and connectivity a lot more, and we're starting to see some things happening that we can measure in terms of technology's effect on people and society. So I was really interested in that. And then the other thing I was really interested in is what's happening culturally and at the team level of people making products. I've always cared, as I mentioned, even going back to the academic days. I'd always cared a lot about what are we thinking about when we design a product? How do we think about the people that we're trying to solve problems for, and what it might look like to help them? So human-centered design. But also I spent a lot of time in the world of business. I was a CTO at an investment bank for a very short amount of time.
[00:16:23] That's a very long conversation. It does require beers to go deep into it. It was a very challenging career segment in my life. Not exactly satisfying. But when you start thinking about the kind of effect that software will have on people, those who use it, the companies that use it, you also have to factor in that software is trying to make money for a company. That's a different kind of effect. I'm a bit on a tangent here, but I was nerding out on those kinds of things. How you could develop teams, how you could develop people, how we could think better about the kind of effect our products have in the world. I was working in the social impact space at the time, trying to get two startups back to back off the ground. So that's the stuff I'm talking to Tom about. And Tom is entering a new season of his career as well, and he's starting to think about the next things that he wants to build, the two ideas he was floating around.
[00:17:10] One of them was this thing called Hypothesis that was going to be a container of sorts for building a lot of different projects, things he just wanted to see exist in the world. Hypothesis does not exactly exist today yet, but that's in Tom's mind. He's got this whole list of things he just thinks should exist. And then at the time, it was this framework called Hammer. Tom had been working at Chatterbug, and he told me about this guy named Peter, and they'd been thinking a lot about the challenges that were happening in the ecosystem with trying to build in React. That's what he was talking about. I'm way off in the clouds, 50,000 feet, talking about what if the world could be perfect and we could all live in harmony. And Tom is trying to figure out how to actually build things better. So we spent a couple of years talking about that stuff. That was a long story.
00:17:56 - Anthony Campolo
That was cool. That was amazing. Thank you.
00:17:57 - Christopher Burns
My thought, as someone who has never been a Ruby on Rails developer, is: did you ever think about a box to put all your gems in? As someone who doesn't know Ruby, that sounds like a funny joke to me.
00:18:14 - Anthony Campolo
I get it. I don't write Ruby, but I get it.
00:18:17 - David Price
I don't know. I'm not a Ruby guy. I don't write Ruby. That is not my background. My background was PHP. I did Drupal for a lot of years. After Drupal, I had a segue, that's not the right word. I took a left turn and started programming in R. What I did learn in college was math. Too much math. Math I can no longer do today. I do love data quite a bit. I like finding patterns, especially patterns that don't exist. I can make them exist. That is not a marketable skill set.
00:18:49 - Anthony Campolo
Unless you're in academia, and it's very marketable.
00:18:51 - David Price
Now in advertising. It's great. I like that kind of stuff. I digress. So I went from Drupal to R and Python and also Gephi to do network analysis. I did that for almost four years, and then I kind of missed React and all these transformations that were happening in the JavaScript ecosystem, remember, because I thought it was all going to go away anyway, so who cares? This stuff popping up was of a lot of interest to me because I wanted to get back to building. And then I probably experienced what you guys experience, which is it is so much simpler to learn a thing in application development now, but it is so complex to have to learn all the things you need to build one thing. Early days, it was HTML, CSS. That's about all you had. And then you would choose some server-side language to drive stuff. But it was a simple state. You could wrap your mind around the HTML and the CSS, and they were much more limited in scope.
[00:19:49] It was a smaller set of things they could do. And then deployment was just painful, but even deployment was pretty linear. You could just buy a server and you'd pay more money or not, and you'd put this thing on the server.
00:20:01 - Christopher Burns
Stick it on an FTP.
00:20:02 - David Price
So I kind of came in. We get into the things past 2010 and it's like, oh my gosh. People ask me, where do I start learning to program? I just try to find a site to send them to because there's not one thing. You have to learn all the things at once, as well as how they all connect together. What were we talking about?
00:20:20 - Christopher Burns
It's a good tangent. And I think this is really important to know. You see these mind maps on the internet where JavaScript is in the middle and then 20 arms coming off of it. And then one of the arms is React, and then there's 20 arms coming off React saying all these different things. And then there's APIs and then 20 arms coming off that. And it's like for you to be a senior developer, you need to know everything. And that's not the case at the end of the day. But to what I understand about Redwood, I found it very easy to know it, understand it, and start using it. But I learned each individual piece of technology separately. I already understood how Apollo worked. I already understood how Storybook worked, Jest and React. When I understood Redwood was doing all the magic, gluing it all together, off to the races we go. It was really easy for me to understand, and it just clicked with me. Then I start reading on the forums and there's some people, no fault of their own, just don't know where to start.
[00:21:25] Where does one tool end and the next start because it's all packaged in the shiny thing called Redwood? And that could be really hard if you've never programmed before, to just get started. Because what is better to do? Follow the tutorial, switch off your brain, and say, I'm not going to worry about how this actually works underneath? Or to know how it works underneath before you implement it? I, as a person, am very much an implement-it-and-then-work-out-how-it-works-underneath person, but not everybody's like that. We're all different.
00:22:01 - Anthony Campolo
I can definitely speak to a different perspective where I came in not knowing any of the technologies. I didn't know Prisma, I didn't know Apollo, so I didn't really know GraphQL. I knew a little bit of React. That was pretty much it for me. I was still able to actually use the thing and get going. The metaphor I would make is that you have a car, you saw it and you're immediately like, oh, I can rebuild that car. Whereas I was like, I can at least drive this car. We were both able to make use of it, even though it was at different levels. You had a deeper understanding, but it was still designed in a way that I could still drive it even if I couldn't rebuild it.
00:22:37 - Christopher Burns
And is that the biggest point of Redwood? Do you need to know how it works to use it, to use it as best you can to build with it? I would argue no.
00:22:52 - Anthony Campolo
I would say not to get started, but to make full use of it.
00:22:56 - Christopher Burns
You do not need that to get started. To get full use, yeah. What would you say, David?
00:23:02 - David Price
I like this. I was going to ask you guys some more questions about that too. I want to loop back around. I want you all to throw some thoughts out there too about how do we approach this better. These are real-time challenges we have with the framework right now in terms of making it accessible for people to learn and adopt, especially if they're new to programming, new in their career. That's a huge priority to us. But then there's this whole other segment. I love the diversity of skills, the kind of people, and where people are from that we have in the community using this thing, because we also have people that are decades into their career and finding Redwood to be a really powerful tool. They're adopting, moving very quickly with it. But those are two very different types of individuals I've just described. Let me flip it a little bit, because I think here's the trick. And I don't mean trick in terms of anything devious going on, but I think there's some things that Rob and Tom and Peter and myself are intuitively doing.
[00:24:00] Now we're being asked why things are the way they are, and we just learned that, oh, this works best. But now we're trying to describe what works best. How do people learn, and why do people learn anything? Super broad question. Why, Bernzy, did you learn to program in Minecraft?
00:24:16 - Christopher Burns
Because I wanted to achieve a goal. That goal was opening a door in the game, and then it went from there. I think that's such an important question. Redwood's been tackled from two ends, from the person whose first web application could be with Redwood to somebody who's been writing web applications for years. How do you navigate that gap? I think it goes back to the point of humanizing the technology, and Redwood's doing a really good job at that. What's the same thing between someone that's never done it before and someone that does it every day? Communication. How they understand the platform. They read the same documentation. Has that documentation got really complex words? Do you need those explained to know what it does? You tend to find that in this podcast. I'm not very good with long, complex technology words, but I know what they probably do because my brain just doesn't work like that. I'm dyslexic, so I just see patterns easier than I see the names of the patterns, if that makes sense.
[00:25:24] I think the way the gap is bridged most is by having something very human, having something as simple as possible and taking it in steps at their own pace, because we all learn differently. How do we make sure that the senior people in their career don't go, I know how to write React, but then someone who's never written React before is like, what am I doing? Maybe we need two different tutorials. We don't know yet and that's what we're working out. But one thing we could do is get Rob Cameron to create a todo app.
00:25:56 - David Price
Yeah, well, maybe he is. And also, do you know about the tutorial?
00:26:00 - Anthony Campolo
I'm showing it.
00:26:01 - Christopher Burns
The return of the tutorial.
00:26:03 - David Price
The other tutorial's coming down the pipe. I don't want to miss this point because I think it'll lead to some other things too around the learning. Anthony, for you, why did you learn in the first place? And then also how? I think these are all leading questions, but...
00:26:17 - Anthony Campolo
Well, the two are connected. The why and the how are very intertwined. For me, it's sheer desperation. Having already tried to learn so many different things in coding and making very slow, incremental progress, but never getting to somewhere where I really felt like I had command over tools that I could do something useful with. That was the first thing I got from Redwood after learning on my own for a couple years and even being in a boot camp for many months. At the time, it clicked. In a way, it's hard to explain because it wasn't like it clicked immediately. But once it got there, I had a holistic view of it in a way that I wasn't getting from learning all these other tools and trying to put them together. The way it really clicked is just the tutorial. I really can't stress enough how important the tutorial is. I think it's groundbreaking in a lot of ways in terms of what it's doing as an educational tool. I don't think anything like it has ever really been created before because, as you guys have said:
[00:27:20] I've talked about this in a lot of my talks. We haven't talked about it yet on the podcast. Tutorial-driven development is you think about how you're going to teach someone something before you actually build the thing, so you can ensure that the thing is actually going to make sense to learn before you build it. It's a really mind-bending idea that sounds really counterintuitive. I've even done it myself. I wrote an article and I wrote it like it was a tutorial before the project was actually built. And then I built the project to work.
00:27:49 - David Price
Yeah, we're taking our own medicine on this, because about a month ago we were having a conversation and we brought up, or I brought up, that we're at that place in a product lifecycle where you've got a milestone and you've got scope against the milestone, and just building a todo app is growing infinitely. Anytime you try to ship something against a milestone, that last push out the door gets really deep. It's hard. We were feeling that, and also feeling it in an open source context. You have a lot of people that are coming in with new ideas all the time. You have exploration that wants to happen, and there's just bugs and things to fix. It's like, oh my gosh, it's hard to limit scope, and how do we choose? We're never going to get to V1. We're like, wait a second. We're not working against anything here like we did the first time. Shouldn't we have a second tutorial or revise the current tutorial?
[00:28:39] Or aren't we missing the thing we did the first time? So that's where the tutorial came out. We realized we didn't have that again for the second time around. We needed the process to work against to actually get to version one. That's what happened. And then where does this all play into learning to program, learning in general? There's some things to keep in mind here. One is people have to want to learn a thing. A great way to want to learn something is when it's play and when it's empowering. When you feel some sense of capability and potency. Minecraft is just all about building stuff to no end, or whatever end you want to create, which is no end in itself. It's play and it's fun. It's building. So there's desire there. There's want, and it's fun. There's an enjoyment in it. And that's really important because a core feature of learning is that you have to experience pain. Humans are, it's a term I learned recently, antifragile. We need to be stressed. Our physiology, our senses, all of those things need to be used and stressed. If you want to get strong, what do you do? You stress those muscles. You work them to the point where they hurt, and that's what causes your whole body to react and grow. When it comes to learning, there's this really delicate balance between stressing just enough so that you're actually learning, but not enough so that you quit. So what happens in programming is you have to understand how programming works. But for a lot of people, there's a lot of ways into understanding the logic and things behind programming, but then you've got to want to do something. Wanting to build something, I want to build an app, that's a very typical thing people want to do. But then how do you actually take them on that journey where they feel a sense of power, they feel their strength, their capability? I can do this thing, and I like it.
[00:30:26] I like this feeling, but then you have to level them up over time. Video games are exceptional at this. You can hijack these things, but it's a natural way that humans work so that you level them up over time so that they want to learn. And then they are learning because things get harder and there's a challenge. The tutorial is doing that very well. It invites you in, you experience, oh my gosh, this is awesome. I built a thing, and not only did I build a thing, it was fun. And then you want to learn. And then it turns out there's a lot of pain ahead of you, but you ignore the pain because it's going to be worth it, because you remembered how fun it was to build something, which is awesome. So what happens when you run into configuration issues? Integration issues? Just the raw complexity of trying to get something spun up locally and then, oh my gosh, deploy. This has to live somewhere other than my computer, not locally.
[00:31:17] So you get to all these steps along the way that you're not really building the thing, but you have to connect the thing to other things so that you can build the thing. And that's discouraging. That's where people quit. What I'm trying to describe on a high level is things that have discouraged people trying to learn something in the JavaScript ecosystem, especially when people talk about this fragmentation of stuff. What they're saying is, I am so tired of having to manage config and integration and I just want to quit. It's something I'm having to learn, but I don't want to learn it anymore. I'm done. So then they move on and try to find something else that's more satisfying, the human side of this thing. I want to experience satisfaction in what I do every day, and if I don't, I'm going to find another way to do that. Which also we can loop back to, because that's how communities and teams work as well.
[00:32:04] Satisfaction plays a very important part there. We're trying to figure that out. I think what we've nailed, and by we I really want to put that on Tom and Rob and Peter. The first version of the tutorial, I came in late. I came in in February, so I was a part of the conversations as Hammer was getting started and turned into Redwood, but I didn't actually start working on Redwood until February of this year. So that was really those guys and they nailed it. The problem to solve now is connecting the dots for what people need to learn next. And I've felt this pain too. My last project was a MEAN stack classic, Mongo, Express, Angular 1, and Node, which was really fun to work with. The performance was great. I really enjoyed it, a very well-integrated stack, but there were some reasons why I wouldn't recommend that to people today. So I came into this and I'm trying to figure out, wait, what does Prisma do?
[00:32:54] And this is February. Prisma still didn't know what it was doing yet.
00:32:57 - Anthony Campolo
We talked about that in our first episode.
00:32:58 - David Price
Right. Wait, where does Prisma start and stop, and Apollo? Okay, so I've got Apollo on the server, but I'm using lambdas and I'm building all that. That's weird. Zip it and ship it. What? And then Apollo Client. Where does that fit in versus React? I had to go through all those things too. I think what we're missing now is a lot of conversation on our forums and discussion around how do we connect the dots for people so that when they do the tutorial, they know where to go next and find the resources they need. "I feel weak" or "I didn't understand how services work." A lot of people go to services and it's like, where are the docs for services? Well, actually what they want is the CRUD docs for Prisma. That's what they're really asking. But no one was connecting those dots for them. A deluge of questions. Did that make sense? Am I right?
00:33:45 - Anthony Campolo
Yeah, no, I got a bunch of follow-up stuff. But go ahead, Chris.
00:33:47 - Christopher Burns
You like to go on a long conversational spin like I do, but I guess one of the first items on my wish list would be things that I think Redwood really needs. When it breaks, it gives you a link and says, here's how to fix this problem. Because Redwood is earlier on, we know that. But when I recently worked in Next.js, every time it broke, it gave me a link and said, this is what's gone wrong. And there's been many times in my Redwood development where things have broken, but the only way I actually worked out why they were broken was by opening the console, console-logging network requests, and then looking at the reason the network requests failed.
00:34:31 - Anthony Campolo
This is something I've heard other communities talk about for sure. Two that I've heard do this really well: Rust and Elm both have compilers that essentially will teach you how to fix your errors as you get them. I think this is something that other people have definitely thought about. This is actually something that the Redwood IDE is going to be perfect for. We need to get Aldo on and talk to him, because that's where you get a tool that is able to be aware of your whole Redwood project because it has a language server in it, so it can actually tell what's broken and how it relates to the larger pieces of Redwood. I think that's definitely the next step to the tutorial, making a better tool that can actually teach you as you're building something out.
00:35:22 - Christopher Burns
That, I think, is the biggest barrier to understanding most of these frameworks. The tutorial is great, but it's a neatly paved path.
00:35:35 - David Price
It's tidy, it's artificial. Of course it is.
00:35:37 - Christopher Burns
Yeah, it's artificial, but then you get to the end of the path, and now it's forests that you need to walk through and make your way through, and then you get stuck. And what's the easiest way? Right now I have this problem myself with Redwood. Something's broken. Okay. First, try and work out if it's me that broke it. Second, poke someone on Redwood. Is it broken? And if I really think it's a Redwood problem, I'll poke Peter.
00:36:02 - David Price
Welcome to JavaScript, Chris. Absolutely, 100%. I think that's a brilliant insight and needs to happen. Part of that is just maturity and time. We're not there yet, but Aldo is thinking about this. There's a lot of major changes happening with the IDE extension right now, so he's just been doing mechanical things to port it over, making its own project, etc. It feels slow right now. The foundation is being set so that can take off again. Three months ago there were conversations happening. This is a JavaScript problem. You have so many places errors can come from, and then you have so many different ways a thing could be connected to another thing. Tracing is just painful, and you add deploy on top of that. Chris, I get really fired up when technology is causing people the wrong kind of pain. We should fix that. That's just wrong. Just to complete that, diagnostics. Anthony's on it. Diagnostics is where that needs to happen, because there needs to be a centralized place where all those errors come to.
[00:37:00] But diagnostics is more static at the moment. We need to do a better job of integrating an IDE. It can do this at runtime because you have server and website, and then also we need more visibility. It is just an infrastructure challenge right now with what was Jamstack now evolving to some version two of Jamstack. As we start doing more with the data side and get more into full stack, the kinds of things you can do at build time and have visibility into just need to get a lot better. I'm even encountering this right now. I had some problems happening with my build for Prisma Client, the engine and the binary, and I was blowing up my API size that I was trying to upload. I'm like, what's going on? It's because I'm actually getting two binaries locally. Is that what's actually happening? I have no visibility into that stuff. And that's where you quit. That's where you're like, screw this, I'm going to go use another framework.
00:37:52 - Christopher Burns
It's really hard. I currently have a problem with webhooks and Stripe, and it all works on my computer. As soon as I upload it to Vercel, it just dies. And half of my application works on Stripe webhooks and that is currently a problem. But do you want to know the other problem? I tried to upload it to Netlify and my server's too big for Netlify functions. So what's the ultimate solution?
00:38:16 - Anthony Campolo
Get on Edge Workers beta?
00:38:17 - Christopher Burns
Maybe.
00:38:18 - David Price
Yep. See? Maybe I can help you with that.
00:38:21 - Christopher Burns
Yes.
00:38:23 - David Price
Okay, we'll talk about that another time. So my passion in all this stuff is the community side of things, probably. I think that's a topic that would be easy to close this out on. And by the way, thank you for asking me to do this. I love this stuff. I don't get to do this kind of stuff very often. I'm really excited and honored you would ask. I have no expectations anyone would listen to this. It's just fun and I'd love to do it again in the future and we'll get better at it too, which would be great.
00:38:47 - Anthony Campolo
We got so many more things to talk about. I can keep going on a lot of things.
00:38:50 - David Price
I'd love to redirect here, but just to say, I'd love to spend as much time as you want talking about community and people, the human side of this and what we're trying to do there, because it is as important, especially to Tom and me. What's happening on the human side of this project and where we want that to go is as important as all this code stuff. The framework has to work and deliver on its promises, or else there won't be the people. But if we don't have a certain kind of effect on the people, we would actually consider this project a disappointment.
00:39:21 - Christopher Burns
Exactly. I think as the organizer of FSJam, we see that other frameworks out there are tackling very similar problems in different ways that I would love to talk about sometime.
00:39:35 - David Price
What? No, there's no other frameworks.
00:39:39 - Christopher Burns
Sometimes some of them are making really interesting solutions that could also solve some of Redwood's problems. One of my questions is, do you think it would be worth it for Redwood to be inspired by the other frameworks?
00:39:57 - David Price
Oh, it does, and it has, I think, and vice versa. Absolutely. That's the way these things work. The challenge there is when you feel a sense of competition with the product or a company. This happens a lot in startups and businesses, and you start to mimic things because you feel like, oh, thing X is popular because of feature Y. If we had feature Y too, we would be popular.
00:40:23 - Anthony Campolo
Might be popular in spite of feature Y.
00:40:25 - David Price
The challenge is there's a few topics here. When you look at innovation, the horse-drawn carriage, I'm going way back in time here. Thought about too many things. When you look at the horse-drawn carriage turning into the horseless carriage, now known as a car, there was a massive period of trying to figure out what a car is going to look like, taste like, feel like. What are the design requirements? What works for the user? Think of them like patterns and user interface design. The hamburger menu that people revolted about for years and years when that was just standard. It's an expected pattern because it works. The user expected it. So that thing happens in any industry, but it takes a long time for those patterns, those design requirements to evolve and get solidified. There were all kinds of engines that were used in cars: steam, coal, electric engines very early on for the horseless carriage. But then they settled on gas combustion.
[00:41:22] So it took a while for that to become the thing. That's going to happen with this full stack Jamstack. We're just not there yet. We don't know what those patterns are. So we would be very much amiss to not be inspired and build on them. Things are always derivative in every industry. People copy each other. It's not a jab. That's not taking away. That's how the industry is going to move forward. We need to find what those things are. But if you veer off your path and get distracted from your vision and your core values and your ultimate goal for what you want a framework to deliver on, then it's not helpful. And there are some things about Redwood, and we talk about developer experience all the time, that just has to trump the kinds of features we add. Because if we add features for features' sake, this is my complaint about Gatsby. Gatsby is entering configuration hell. You have to have a template to start with. It's really challenging to start from a vanilla Gatsby project.
[00:42:15] I don't even know what that is. And then you just get into plugins on top of plugins and oh my gosh, this is not fun. And that's what we don't want to do because I think Gatsby's value is to add plugins. But what's the effect it's having on the developer? It's developer satisfaction and experience. That was a lot of thoughts all strung together. But I love the collaboration that's happening between the players right now. They're on our forums and we're on theirs. Peter and Brandon have had good conversations. I've had wonderful interactions with him on the old internet. Same with Chris Ball. It's fun to see because I hope what we all get out of this is relationships that we get to carry forward, because that's what will change the ecosystem versus a whole bunch of disparate frameworks that are all competing against each other for market share. That's not why we're doing open source. At least that's not why I'm doing open source.
00:43:05 - Christopher Burns
My closing thought on this is competition is a hell of a good thing. It's good to know what over the road's doing. But at the same time, you can't let that distract you because then you lose sight of your own goals. One of the core things happening in FSJam is abstractions and what matters to the developer. Because every single FSJam framework out there right now does every single abstraction in slightly a different way. Some of those abstractions may click with different types of people, different types of products. I am one that always says whenever you start a project, you should always assess what's best for that project, not what's necessarily best for you. Because at the end of the day, you'll be fighting an uphill battle if what you like doesn't work well for what it should be. All these groups are growing and they're growing well, and they're getting whole new types of people. But we have to always make sure that we never pick up the pitchforks, because we're all trying to get to the same goal of this FSJam ecosystem.
[00:44:15] But we are all taking different routes. And that's okay, because different developers may say, I like that route better than that route, and that's the one they go down, and that's okay at the end of the day.
00:44:26 - David Price
Absolutely, 100% agree. There will be a lot of different solutions. There'll be a lot of different frameworks because the problem sets are different, of course. And that'll be the paradox and the tension between finding out what really works for the developers, because they're the ones who will say if thing X adds value or not. At the end of the day, if they use it. Paying attention to that, but then also staying true to some specific vision and some kind of problem-solution set that you are designing the framework to be applied toward. Absolutely. And that'll be fun. But then mixed on top of it is this: maintaining an open source project is hard. The person that I just can't applaud enough is Brandon, and what he's doing with Blitz and carrying that on his shoulders. It's stressful. The demands as your project grows. Here's what happens in open source. You most often become punished for your success because you get more attention, more demands, more incoming, and there's no business model built into the whole thing.
[00:45:25] You've still got to pay your bills somehow in the middle of all these demands because your framework is now popular. The thing is, good people are using it. So now the consequences of developing and creating something that people like is you're stressed. You're like, this was fun for me, but now I feel pulled a million directions and I still have my bills to pay. I really applaud what the Remix gents are doing trying to pivot into a new kind of business model. Remix Run is not going to be open source itself. There's a license with it. I really hope that works for them because that would support the React Router. Those things could be complementary. This is the challenge of these types of projects, open source. That's also happening behind the scenes. And I think that's where the competition thing can come in too, because you're like, wait a second, I'm working so hard. And what's my end result at the end of the day?
00:46:16 - Christopher Burns
At the end, what's more important, the amount of stars you have on GitHub or the people that you connect with and change every day with your applications?
00:46:25 - David Price
And there you go. That's a good segue into questions around community. I would be lying to you if I didn't tell you, I tracked the stars on Redwood and felt some satisfaction, like, oh, people are using it. Our stars have stalled out. By the way, I think we've been at 4.8 forever. And I'm like, oh, is something wrong? Because that's an easy thing to feel.
00:46:46 - Christopher Burns
It's a pit of despair. It's a pit of despair.
00:46:49 - David Price
The pit. So something's going on versus... I actually wrote an email to a venture investor. As you can imagine, we have a lot of people that would love to invest in Redwood and they can't reach Tom. Although Tom gets back to them, but then they're like, oh, who else can we talk to? So then they email other people on the team. Are you going to turn Redwood into a business? Is there a business model? Could we invest in Redwood? No, not right now. We don't know. That's not the plan for it at all. But we don't know. The thing I told this investor in an email: we don't know how it's going to look at the end of this. We're learning as we go. What we're trying to measure is not how successful Redwood is in terms of how many projects get spun up, or what its value is in monetary terms. What we're trying to measure is what is the most amount of people that can actually get to do something they haven't done before because of Redwood?
[00:47:37] What are the teams that get created because Redwood existed, the teams that would never have happened earlier? What kind of collaboration? How do we actually measure the human effect, the effect that Redwood has on the humans involved, versus just measuring the things that the humans produce with Redwood? For us, the former is much more interesting than the latter, although from a business perspective, we should be paying more attention to the latter. Did that make any sense?
00:48:00 - Christopher Burns
It did, but we're going to have to wrap it up there. We have so much more that we could talk about.
00:48:06 - David Price
So many things to say.
00:48:07 - Christopher Burns
And I 100% think we should get you back on for a second episode and talk about the ethics, the ethics of open source technology.
00:48:19 - David Price
Way to drop ethics. Yes. Do you want a little teaser? Here you go. This will be the little nugget, the teaser at the end of the episode. This is where the ethics plays in. When I think about ethics and technology and people and users and all that stuff, it really boils down to just a few very simple things. If you want a technology product to have a kind of effect on the world, and especially on people, if you have some vision for the kind of potential you would like to unlock or increase in people with your technology product, then what kind of person or what kind of team would you need to have in order to build that product? What would they do? What would they think about? More importantly, how would they behave? What characteristics and qualities would you expect from that product team in order to have X effect on the world with their technology? And boy, do I have ideas.
[00:49:19] And it happens. It happens all the time. We just don't pay much attention to it.
00:49:23 - Anthony Campolo
You need to write a book.
00:49:24 - David Price
Well, Aristotle actually wrote the book. It's just a little inaccessible.
00:49:28 - Christopher Burns
You could call it The Price to Pay. Question mark.
00:49:33 - David Price
Oh.
00:49:35 - Christopher Burns
Thank you for tuning into this episode of FSJam with David Price. We have really enjoyed having him on and we would love to have him back on soon.
00:49:48 - David Price
Yes.
00:49:48 - Christopher Burns
Please tell us what you thought of the episode on Twitter. Our handle is FSJamOrg. And that's it from me.
00:49:56 - Anthony Campolo
Thanks a lot, David. That was a blast. There's plenty of other things I would love to talk about. Just to wrap up some of these things, I want to shout out the book Working in Public by Nadia Eghbal. She talks a lot about what's going on in open source right now and covers it in a way that hasn't really been covered anywhere else in terms of really telling the story of what people like you are doing. And if you really want to sound smart when you're talking about how people learn, there's actually a specific term for what you were talking about. It's called Vygotsky's circle of competence. Being just outside your circle of competence is where you want to be when you're learning. I have a formal education degree. Vygotsky was a really incredible Russian education theorist. The circle of competence is an idea that really sticks with me. That's what you were describing earlier.
00:50:45 - David Price
Wonderful. We'll talk about that more next time as well. Gentlemen, thank you. See, look what this weird, crazy project called Redwood did. Relationally. Regardless of what happens to Redwood, and I hope good things for it, this is what we get to carry forward. I'm really thankful for both of you. It's been fun and there's so much more to come. Look at you guys doing this podcast thing. Way to go. Hats off to you both.
00:51:10 - Christopher Burns
Thank you for being on board.
00:51:11 - Anthony Campolo
Thank you.
00:51:42 - David Price
The board.