Ep. #15, Learning in Public with Shawn “Swyx” Wang

Patrick Woods: Awesome. Swyx, thanks so much for coming on the show today.

I'm really excited to have this conversation.

I'm sure lots of folks are aware of who you are and probably follow you on Twitter, but for those that don't, would you mind giving us a little bit of an overview about who you are and what you're working on?

Shawn "Swyx" Wang: Sure. Thanks for having me on.

Been enjoying the podcast, and this is my second Heavybit podcast alongside JAMstack radio.

So I'm Shawn, I also go by Swyx, that's my English and Chinese initials.

It's a complicated history, but I was at Netlify, passed through AWS and most recently just left AWS to join Temporal.

And have been primarily active in the front-end/ serverless space.

And I've been very interested in this whole idea of developer experience.

I did not know to call it developer love until I came across Orbit.

And I think Orbit's model is fascinating and really nails it.

But to me, the way I've been breaking down developer experience is developer tooling and developer communities.

So kind of straddling both.

I was a moderator of r/ReactJS subreddit, going from about 40,000 members to over 200,000.

Recently stepped down from that to help run the Svelte society, which is the community organization for the Svelte framework.

And I think it's just a magical thing to be able to enable a community around a certain technical topic.

Patrick: Yeah. Thanks for the overview.

So you mentioned developer experience as a concept and a practice that you're very interested in.

What do you think led to that point for you?

Swyx: Honestly, it was Netlify branding their developer relations people as developer experience engineers, which I was pretty skeptical about, because if you are devrel, just say your devrel, don't try to put some unique spin on it.

But then I think they really envisioned something bigger than traditional devrel, which was building our integrations and also working on community building, which is not like me talking to everyone, but also enabling others to talk to everyone else.

And so I think many to many is a really noble goal.

It's very challenging obviously, because you have to influence without any formal authority, but it's also a very appealing goal economically, because then you don't have to scale their number of employees linearly with your number of users, which I think makes a lot of sense.

Patrick: So you mentioned developer experience for you is really comprised of tooling and communities.

Can you talk a little bit about the relationship between those two pillars?

Swyx: I don't know if I have a formal relationship in my head.

The framework that I come from is actually from Cheng Lou, who used to be on the React Core team.

I think he's on the Reason or ReScript core team now. And he gave a talk at Facebook's internal conference called Taming The Meta Language, and the argument of that--

And it's a very good talk. I recommend people check it out.

The argument on that talk was essentially that every programming language or every framework has a core and a periphery, and the more developed it gets, the core which is kind of like the code that runs, is a smaller and smaller part of it.

And really the middle language starts to go around it, which involves tutorials, docs, workshops, community, jobs, third party libraries, yada yada.

And so in his original slides, he had a long list of these things that are wrapping around a very popular framework, which for him was reacts, but you can extend this to basically anything.

But for me, I think it essentially just breaks down to, okay, the code that is not core but makes all the developer experience much better, so that's the developer tooling, and then developer communities, which is all the people around the code, which isn't core to the code, but makes using that code a lot better.

So it's just code and people.

Patrick: Yeah. I love that.

So as a project or a framework grows the core, maybe it becomes smaller as a percentage of the overall footprint with the periphery, the middle language increasing.

What's that tipping point look like, do you think, when it switches from code to community being the bigger part?

Swyx: Yeah. This is something you can tie in to Geoffrey Moore's idea of Crossing the Chasm.

So for people who haven't heard about this, it's like a five stage adoption process going from 0% of the total population to 100% of the total population.

And then it's a bell curve from 0% to a 100%.

So the early stage is kind of the hobbyists, like super early adopter types.

The only thing that they care about is this is cool.

I can hack on this in the weekends, and this is technically better on some basis, right?

Like in theory, I really want this thing to exist. I look at all the existing solutions out there and none of them fit me, because I have very specific needs.

And they don't need a lot of documentation.

They don't look for other people like, is this used in production by some big company that I recognize.

They don't think about stuff like that. They're just like, does this fit a very specific need that I have?

That's it. If it does, good. That's enough for them.

But the majority of people don't work like that. Right?

They do want to see documentation. They want to see a thriving job market.

They want to see that like whatever, Netflix has used this in production.

All that stuff that's not core to the code, but does provide some measure of faith that this is tested at scale, that this is reliable and dependable and a good technical bet.

As you go from early adopters, you cross the chasm into the early majority and the late majority. The requirements of the early adopters versus the majority are very different. The earlier adopters require a lot less essentially handholding.

I'm not trying to demean the people in the majority.

They just have different needs for that specific domain.

And the people in the majority are more conservative, probably as a good measure of technological conservatism.

You don't bet early on everything because you're going to get burned.

So I think it just makes sense to bet early on some things where it really, really counts, and then just be conservative, use boring technology on everything else.

But it does make a lot of sense that the crossover is a very challenging thing.

Because when you start a framework, when you start a programming language, you're just like one person or like a small team just hacking away, right?

You just care about the code and making it run fast or more securely, or have special features that nothing else in the world has.

That's great. And then suddenly a community grows around you and then they're asking for things like, "Can you make better docs? Can you integrate with my thing? This doesn't work well with my existing worlds."

And you're like, "Okay, sure. I want you to be happy."

But that takes you further and further away from just working on the thing itself.

So I think as a project grows in importance and adoption by the majority of the community, you start to embrace different parts of the population with different needs.

And I think that that's the crossover point. I don't have a number for you, but people typically peg it at--

I don't know, 5% or 10% of the population where it really starts just crossing over already.

Because there are a lot of people in the middle.

Patrick: Thinking about your experience with the React subreddit, what were some of the learnings or observations you had as that community scaled through those different phases?

Swyx: It's a challenging one because Reddit is a constraint format.

It's essentially a link aggregator with a voting and some comments.

So, JavaScript is the largest programming language and React is the largest framework within JavaScript.

Arguably there's some other measures.

But when you have such a large community like this in a constraint format where basically only one link or one question can be in the top position when you sort by up votes, then there's a matter of what target audience do we want to target?

Because there are a lot more beginners than there are advanced people, but people come for engaging events, knowledgeable conversations.

So there's always this tension between, there's a lot of beginners who don't know any better and we should be welcoming to them, of course.

But at the same time, if we make it too beginner-focus, the events will go away, and it will lose its quality.

So there's a very challenging tension.

One of the ways in which we solve that is to basically contain the beginning of questions to a dedicated thread.

And that's something that I did when I was starting out.

Basically the promise you make is that you will answer every single question that goes in there, which is a step up from stack overflow, where you can ask a question and it just gets crickets.

Patrick: All right.

Swyx: And so that contains the beginner questions and allows other types of contents to come up, which can be more advanced.

And you try to make the two extremes happy, even though you can never really do a fantastic job.

So there are other ways, for example, you can forge the community and create as specifically beginner focused one.

But then you get what you get, which is that there won't be that many experienced people frequenting that subreddit, therefore the answers may not be as good, or you just have a glut of people asking questions and nobody's around to answer them.

Patrick: Yeah. In terms of tactics, were you the one answering the questions in the beginner thread or were there other moderators that jumped in or did the community help out?

Swyx: I started doing that. So there were some months where it was like 500 pushes and answers, and the vast majority of them were me.

Patrick: Wow.

Swyx: And it's not so bad, once you find repeats, then you can just copy and paste.

But I think when you're leading the community, you do have to lead by example, and then people who see what you're doing in the service of the community, start to jump in and help out.

That's where I recruited a couple of my other fellow moderators, because I saw that they took the initiative and joined in with no expectation of any personal benefit.

They're just serving the community.

I think there is some personal benefit in the sense of, you get to answer all these questions and you strengthen your own knowledge, which is really good.

And you also understand the pain points.

So you can go write blog posts and articles and even libraries to solve those pain points.

So having a very close ear to the ground for what people are facing helps you just be relevant to everyone else.

So I think there's a lot of benefits for doing that.

But yeah, it's actually a pretty good recruiting ground.

Basically, if you want to be a leader of the community, just act like it and people will see what you're doing, and then they'll formally give you that position.

Patrick: You mentioned that by being heavily involved with these beginner questions, things like that, it leads to inspiration for blog posts, tutorials code, things like that.

We think a lot about the second order of effects of an active community.

And one of those is content like that, where if you have a thriving community, one second order effect is you probably have ideas for blog posts, guides, tutorials, things like that.

And I'm not sure everyone realizes the sort of power of that type of output.

Swyx: Oh yeah. We have people who teach React for a living.

They actually go through the Reddit to browse for people's pain points so that they can write articles. It's pretty effective.

Patrick: Yeah. That's awesome. So you're working today with Svelte Society.

Can you tell us a little bit about what you're working on there, and the nature of the community that's around that?

Swyx: Yeah. So, Svelte Society started off as a meetup in New York, because I was friends with Rich Harris, who created Svelte.

And I had basically ignored him for a full year because I was so deep into React, that I was just like, I don't need a new framework in my life.

And I think we were both speaking at a conference and he gave a really convincing talk where I reached a point where I was just like, "Okay, I got to try this thing out."

And of course I was impressed.

Of course it solves major pain points that I had with React.

And I just ignored him for a year, because I'm one of those not early adopter types.

So there was a meetup that was going to happen in London, which is going to be this first Svelte meetup in the world.

And I was like, "We can't have that. We're in New York. We have Rich Harris in New York. We need to meet up as well."

So I just decided to tweet that.

I wanted to launch a meetup. I had no speakers, no guest list, no venue. I just set a date, that was it.

And then people got together and within a week we actually organized a met up with 50 people, someone from Microsoft stepped up and offered their location.

And we did the very first Svelte meet up just scooping London, and eventually Stockholm also did one.

So eventually the three of us got together when COVID hit.

The three organizers from New York, London and Stockholm got together, and then we created Svelte Society as a global online community.

We've done two conferences, we're about to have our third in April. And a few thousand developers, I think we're at 7,000 and something. And it's a small, tiny community, but it's actually a lot of fun growing something from scratch, rather than taking over something halfway and growing into something already huge. So I'm enjoying that difference in vibe.

I think that developer communities where you are not the default, so everyone comes to you as the second framework or the second tooling, is a very nice position to be in because you get people who know what they're coming to you for.

For example, when people choose React, they just choose React because they're told to do it, right?

They don't actually know the difference between JavaScript and React, or they don't know anything else apart from React.

And so some of their questions might be very off topic or just kind of not discerning.

They don't actually know what they want.

I kind of call this second framework syndrome, which is just actually like a positive.

So I need a different word than syndrome.

But essentially, once you've picked one tool in some domain, and you've gone onto the second tool, you're much more discerning and you're less likely to identify so strongly with one tool, because if you've left a tool before, you're never going to say like, "Okay, this is the solution for everything."

Because you might leave the tool for something else again.

Whereas I think people who are first time to a framework or to a tool might be too loyal to it and try to solve everything with it. And that's a recipe for pain.

Patrick: It reminds me of the classic advertising campaign from Avis.

They were number two in the market.

And so this is like 1950s, 1960s mad men era, and their whole campaign was, "Hey, we're number two. So we'll try harder for your business."

Swyx: Yeah. This is great. Acknowledge that you don't have the top spot, but there are things that you can still bring that people still really value.

And if you just say that, I think people recognize it and respect that.

I do a lot of marketing types in my line of work, and I don't like marketing that just denies reality.

I think it's way better to just accept it head on, call it out.

The other famous example is Domino's, right?

They're just like, "Hey everyone, we know our pizza sucks. We revamped it. Come try us out." And it worked.

Patrick: Big time. Yeah. Well this reminds me of a tweet you shared recently of talking about the advice, to talk about benefits versus features, but your view is that the opposite is true for developers.

Swyx: For developers.

Patrick: Yeah. Can you talk a little bit about features and benefits when it comes to communicating with developers?

Swyx: Yeah.

This is one they struggle with back and forth, and specifically the tweet is about me relearning it.

So the advice in traditional marketing is to sell benefits over features, right?

Sell people on the vision of what they will be with you rather than without you.

Instead of, you're specific how you get there.

And that's why, I guess when people sell perfume or clothes or whatever they show you someone in a fancy dress or some dude with a fancy watch on a yard or something.

It's association and that's how you do marketing in a traditional sense.

But I think developers have been lied to too much, where we just stopped believing in people in marketing.

So if you tell me your library's blazing fast, I don't know what that means.

So tell me why it's fast, show me why it's fast, don't just tell me that it's fast. Because, sure, that's a benefit.

Obviously that's an improvement to my workflow.

But if I don't know why it's fast, then I'm not going to accept it on faith, because I've been burned too much or I'm not going to be able to explain it to the rest of my team or my boss when I try to adopt it at work.

You have to have a logical reason, because there's also going to be a trade-off right?

There are some free lunches, but usually there's no free lunch.

You have to be able to answer the question of like, "What am I giving up in order to get this benefit?"

And usually, marketing you only talk about the benefits, and you don't talk about the sacrifices.

And I think that the most concise way to do all of that is to tell you how it works.

Show you under hood and give you the logical explanation for, okay, all these alternative solutions that you're used to, they all use this legacy format, and we use a different format that is just way optimized without those legacy assumptions.

In exchange for all these benefits, it will not be compatible with some legacy features that you now no longer care about.

And you're like, "Ah, okay, that is me and I'm sold."

But if you skip all of that and just go like, "This will be faster." I can't get behind that.

So I think that's my insight on developer marketing that we want to know how it works.

And I think that's which is partially why open source is something that's so appealing as well. We are able to see the code.

Patrick: Yeah. Do you think that the continuum from features to benefits, do you think where the messaging lands at the timeline maps to where a potential user is on the chasm?

Maybe early adopters care more about how it works and late majority we're about?

Swyx: Exactly.

Patrick: Yeah.

Swyx: Yeah. So I got some pushback on my tweet saying people don't understand how React works, and it's a black box to most people.

And that's true, but because React has already crossed the chasm, it doesn't have to.

So I definitely am focused more towards early adopters, because I guess I work on earlier stage companies.

If you're IBM, nobody knows how Watson fricking-- What is Watson?

I don't know, but it does Jeopardy.

I don't talk to the type of developers that buy IBM.

And no shade on them, it's just really, I think when you're dealing on cutting edge stuff you really have to open the hood.

Patrick: Yeah. Agreed. Shifting gears a bit, you champion the idea of learning in public.

And you described your writing on this topic as your most impactful essay.

So I'm really curious, how did the concept of learning in public become so central for you and your work?

Swyx: I think that it was a reflection of when you look back on your work for the past year, for me, it was like the past six months, and try to understand what parts of my work was the most impactful, and what parts of my work didn't matter at all.

I realized that it was the stuff that I did in public.

And sometimes got wrong in public that contributed most to my learning.

And I think this idea, there's a name for it. I actually got from Kelsey Hightower, who is sort of Mr. Kubernetes now.

But he's very much someone who learns in public.

Something that he just learned, he'll share it because it's was valuable to him from three to six months ago.

Therefore it will probably be valuable to a lot of other people. It may not be the most insightful thing in the world.

He's not presenting himself as the expert in something, but that's not going to stop him from sharing something fundamental that he learned, which is useful.

And if you do that, you'll not only learn faster, because you get feedback from other people.

Both from people who know more than you, and also people who are with you in your journey.

But also you get to demonstrate your interests, which is very good for your career. It's a two-way street.

It turns your network from outbound network, you reach out whenever you need a job, to an inbound network, people understand what you're into and they reach out to you for stuff that you are interested in.

And I think that's a fundamentally different way mode of operation that most developers are used to.

And they don't even realize that this is possible.

They're like, "Oh, you got to be internet famous to do this."

And surely you can get internet famous by doing this.

But to me, that's not the goal. The goal is to just have a record of what you learned.

Because when we do interviews, for example, we try to have this really lossy compression algorithm.

We compress all that we are, all that we can do and that we've done, into one piece of paper and hope that the other side has the right decompression algorithm to unpack that.

And then we complain about how broken the hiring processes, because we stick to this completely useless thing.

It's much better to have a, let's say like a site or a GitHub that just shows that I've been interested in this.

I've been hacking on this for three years and here's all the things I've done. It's instantly verifiable.

It's like a cryptographic proof of work. And you don't need some massive following for that.

All you need to do is actually do good work.

Patrick: What's a tangible example of learning in public?

What does that look like in practice?

Swyx: So one of my talks was about how React Hooks work under the hood, because Hooks were a major feature of React that were launched.

And those launched in 2018, and a lot of people were talking about it and not trusting it, because it was a little bit magical.

So I thought about this question and then I tried to make a small clone of it.

And it was just a very simple, like 29 line proof of concept. And I tweeted it out.

This is a career hack as well. Whenever you tweet about a company's products or a framework's features, probably the people who wrote that feature will see it. Especially if there's a company involved, they will have a Slack channel hooked up to their company's Twitter account.

That's how it works, right? And so, Dan Abramov and the React core team actually saw it.

And it was like almost there. There's some flaws.

So he actually gave me suggestions to correct it, and I just went and did it.

And then that actually got a lot of traction.

So that actually led to a blog post, then actually led to a workshop that was conducted with egghead.io.

And then eventually a conference talk at GS conf, that was my biggest talk to date.

And all that just because I tweeted out a tiny thing that I was trying to work on myself.

And I could not have got there without help, without feedback from other people.

And the other thing is I would never have thought that this was something that I could do, like do a completely live coded presentation on stage without all this validation and support and help.

And it's one of those things where you don't know what you have until people sometimes pull it out of you when you share it.

It just wouldn't have happened if I didn't share it.

Patrick: Have you seen this concept work for non-technical people as well?

Swyx: I think so. So I used to be in finance and I still follow a lot of investing people in the investing sphere.

So, Patrick O'Shaughnessy is, I guess, a well-known investor by now.

His approach is very much in the learning public phrase as well.

So he also uses that term. But he uses it to just talk about the industries that he invest in, right?

He can be much more in-depth in, let's say, minerals or energy, but let's say if he wants to learn about tech or consumer retail or shipping, he can just invite a guest to go on his podcast and he'll talk about it.

And that's a form of learning in public as well.

You're putting a beacon out there and having real conversations.

You're never presenting yourself as an expert, but you become an expert if you do it this enough.

And the rate of learning is way faster than if you just did everything in private.

So the argument is very much like you're not putting everything in public, but if you put it just a little bit, you actually get a lot of benefits, because there's such a great network effect to learning in public.

Patrick: Yeah. It's interesting to think about the gradient of self editing that has to happen when you're deciding what to put in public versus what not to share.

Swyx: Yeah. And some people, especially women, have to do more editing, just because they get attacked more.

And that's really unfortunate, but it happens.

And I think you have to have a thick skin, actually my preferred way of saying that you should have a thick skin is that you should divorce your identity from your work. When people criticize your work, they're not criticizing you, they're criticizing the work that was produced by some past version of you. And if you're growing at all, you should look back on your work like a year from now, and just say, that was totally horrible.

So you should agree with the people who are criticizing you.

And in fact, if you build a reputation of someone who takes criticism well, then they'll criticize you more and you'll learn more.

And if you just don't take it personally, and as long as they don't make personal attacks at you, of course that's not acceptable, but if you don't take it personally, then yeah, you're totally fine.

So the way I phrased it is that you can learn so much on the internet for the low, low price of your ego, and just get you out of the way.

Are you here to be good or are you here to feel good?

Patrick: That's a pretty fundamental distinction that not many people may draw.

So you've mentioned before the idea of learning in public and the phrase you use is building a habit of critical learning exhaust, which I think is very poetic.

What do you think the relationship is between learning in public and the communities you're a part of?

How do those two aspects interplay for you, do you think?

Swyx: So there's a selfish reason. And then there's a selfless reason.

The selfless reason is that I think we need to make it easier for people to learn in public, to create receptive and welcoming communities that recognize that you're just trying to improve yourself just like everyone else is improving themselves.

And sometimes we don't have a space for that. And when we don't have a space for that we just clam up and just not try.

So if we just foster a community of people who are all improving and working on things, I think that's just a better net positive for the world and net positive for everyone in that community.

The selfish reason for that is that there's a scaling law that scales beyond me.

So the way I think about this is that, there are few scaling laws.

Some people are very familiar with Metcalfe's law in tech, which is that, the value of a network scales according to a square of its number of nodes.

And that's analogous to me having a very big "Rolodex" which is like, my friend's list is very long, then I can call upon these as experts or friends or mentors whenever I want.

That's really good. But it could be better, which is what's better than Metcalfe's law?

Metcalfe's law is great. But what's really explosive is Reed's law.

So Reed's law is sort of an exponential growth of the number of nodes.

Because each of the number of nodes can form subgroups independently of the central node, which is the reason why Facebook, when it grows, the value of Facebook grows not as number of the members, it also grows by the number of interest groups within Facebook, right?

That's why Facebook groups is so powerful as a value added to Facebook, to the point where most people would just use Facebook today for Facebook groups.

And Facebook just doesn't care. Doesn't have to know.

And you can be in a thousand different groups and it doesn't matter.

But they're all valuable to you. Okay. How does that tie back to the community?

A community is a many to many ongoing sustaining relationship between all of them, and me being able to grow them.

I grow at that accelerated pace faster than Metcalfe's law, because Metcalfe's law is limited by Dunbar's number like--

Sorry, I'm pulling in so many concepts, but there's a limit to the number of people that I could possibly know.

But if I enable each of them to talk to each other and collaborate with each other, then I benefit as well, partially because I help to be a central member of that community.

But then also when I find them, they will be innovating without me there.

And that's a benefit to me as well, whether I've realized it or not.

Patrick: Yeah. The distinction between Reed's and Metcalfe's law is really quite fascinating.

Swyx: That's community. It really is, Metcalfe's law scales, but it's so much effort to add each node, because you have this central dependency, right?

Which is, let's say the company or the core team of a framework, but once you have a community, then they're just all interacting on their own basis.

And you don't really have a say, which is a little bit worrying, because it's out of your control.

It's adding value to your network, whether you've realized it or not.

Patrick: So a lot of Orbit's customers and folks in our own community have this question where they're early on their journey.

Many of their early community members are just users of their product--t he early adopters, we would call that, or the Orbit one.

And they're starting to ask this question of, what's the tipping point when a community goes from mostly people talking to the company about the product or the project to talking to each other about the project, about ideas and their job and broader concepts.

Can you talk a little bit about when you've seen that occur, and if there are any tools or tactics or frameworks that the project maintainers or the company founders can implement to accelerate that tipping point.

Swyx: Yeah. I think I definitely am not the authority on this, because I haven't seen this occur too much.

I've seen instances of it. And I just don't know if I have the authoritative story.

If said like, this is the general theory of how to make networks, I think I'd be a millionaire.

That's a very valuable information. But I'm actively researching this.

So with all that said, I think that what can be very helpful is that you make the identities and the interest graphs of your members of your network discoverable to each other.

So a lot of the times when you hire a community manager, their job is to know the community members very well, and they typically store it in their heads.

But if you have a listing of them, where people can actually independently search and discover, then you really find that independent connections start taking shape.

But you as someone who manages that community needs to make that happen.

Because that's not going to happen in any organized fashion on its own.

So one of the ways in which I do see it happening very effectively for a company or a framework is sort of an official partner designation.

So you do have the ability to bless some people as the recognized experts.

So at AWS, we have AWS Heroes, like we'll anoint like external parties as serverless heroes or data heroes or machine learning heroes.

These will be recognized experts. I just saw that Webflow actually, and Vercel have Webflow experts or like a Vercel partners program, where these are sort of the key system integrators, I think they're called, or like agencies or whatever you call it, that are very keen on working with Webflow.

So then they get a lot of benefit from associating themselves with you as experts, or just as long as they derive significant value from hiring or finding business off of you, then they're a very engaged community members, and they're very incentivized to contribute to the value of your community.

And it's just like a reinforcing loop, because as you build that then more people know to come to your community to find these people.

And because more people come to find these people then more people on the supply side sign up and it's like a demand and supply side marketplace type of thing.

So I do think that a marketplace is like the ultimate business model. I am a huge fan of marketplaces, but it can be hard to start. And sometimes you have to bootstrap one side versus the other.

But essentially what you're doing is a marketplace, where you set the rules, you make it easy for people to transact and you establish reputation systems, you establish trust, you establish like this conflict or dispute resolution mechanisms.

These are all traditional forms of a marketplace, but you can actually bring all those lessons, all of it, to communities.

Patrick: I love marketplace as a metaphor for community.

Swyx: The other thing that you can do as well is to organize events.

Because I think we as humans, we like-- Okay, most of the time we like async, we like to do things on our own.

We like to build our own networks independently, but every few months we love special occasions to announce some things and to gather to celebrate something you, like a woodstock, or I don't know, basically a conference.

But the definition of a conference is changing in the COVID world.

And another thing that you can do is definitely organize events where people would just get together.

And sometimes it can just be a small dinner, let's say we can all meet up again in person.

You can just have a day when everyone just gets together and just talks, and you as a community organizer, that's a minimum viable market place, which is just like, "Hey everyone, we're all going to get to get together in this room at this time and day."

Which is what I did for my meetup, right?

There's no economic transaction, you're not taking a fee or anything, but you're just making it possible for people to find each other.

That's a marketplace.

Patrick: Thinking more broadly about communities in general.

What are some trends that you've been seeing in the way communities are being built or platforms are using or methods you're seeing as we go into 2021, and what are some of the community building concepts that you're excited about?

Swyx: Oh, I'm so into this. Yeah.

To a point where I do have an ongoing research collection about dev communities and people who are innovating in community space.

I always thought that things were sort of going online, things are going asynchronous, and then Clubhouse changed everything for me.

I realized that people actually like real-time connection and the ability to ask questions and participate in chat, and sometimes video and anti-feature, which is another interesting concept, right?

Because Zoom was the darling, and now Clubhouse is. A nd Clubhouse is like Zoom, but worse.

So yeah. I think people are realizing that connection is real.

Having events like a clear before and after is a real thing, which I think is a reversal of some of the trends that we were seeing.

We were moving towards more async online chat-based communities.

And I think now we're seeing some revival in live events and live ongoing discussions in spontaneity and imperfection.

Beyond that, I'm not really sure I have-- Okay, so the other thing that's also happening is cohorts, right?

Which Wes Kao and Gagan Biyani from Udemy are championing.

Which is basically communities gated by when people join. So most communities they're just open at all times.

So you just come on in whenever, and whenever someone says hi, they're just like, "Okay, it's another person it's not something special."

But when you make something into a cohort, suddenly groups have identities like, Oh, I'm sort of class of spring 2019.

That's Y Combinator, right? But that's also college, and that's also a cohort of communities.

And those cohorts are prebuilt, it's an event.

Everyone is new and everyone knows that there's a group that's going through the same experience as they are.

But then there's also broader group with more experience than they are. And they can access that as well.

I think cohorts are an interesting twist on how people run communities.

None of this is new, right? But we're just taking lessons from maybe other domains and applying it to online communities that may not have been applied before.

And I wish I could go back in time and tell myself from three years ago all this stuff, because I didn't know any of this, but now it's obvious.

It's obvious to me because I watch all these people closely, maybe people who are listening, if it's not obvious to you sit up and listen, because this is real.

This is very valuable. And this is happening at a very, very fast pace.

Patrick: Where would you suggest people tune in or the resources or people that you follow that are particularly insightful when it comes to these topics?

Swyx: Yeah. Wes Kao is pretty much leading the core based course league.

Rosie Sherry, from Indie Hackers is definitely collating a lot of community news.

There's also Greg Eisenberg, he runs a consultancy that starts communities for people.

The only problem I have with him is that he thinks of himself very highly.

So he rubs people the wrong way, I think. But he does have valuable insights, which is very frustrating.

Sometimes arrogant people are worth it.

Patrick: Yeah. I think it's complete opposite of someone like Rosie, who is such an intellectual heavy hitter, but also so humble.

Swyx: Yeah. I got more resources for you.

So by the way I collect all this in my circle community.

So, codingcareer.circle.so is where I collect all this information.

So there's Get Together, which is a book and podcast for people who form communities.

There is CMX Hub, which is, David Spinks, who has been doing this awhile as well.

There's a bunch of people in this community space.

Oh, Lolita Taub is a VC who just launched the community fund.

So they're specifically a venture capital firm that is focused on companies building communities and companies building tools for companies building communities there's a whole circle of that.

Patrick: Yeah.

Swyx: There's a lot of stuff. And then there's also a couple of books that people really like.

So Nadia Eghbal, Working in Public has some sense of community building in her stadiums and whatever and village metaphors.

And Laís de Oliveira, has a book on hacking communities, which I haven't read, but I've definitely singled that out for reading up.

Anyway that's just my resource dump.

And I'm keeping this list because I think it's a growing knowledge base of what it means to run a community, and what are all the different ideas that people are bringing to their communities.

Patrick: Awesome. Thanks for sharing that.

So zooming out a bit to a question that I ask pretty much every guest on the show, what do you think is the secret to building things developers love?

Swyx: So in that tweet about development marketing, I actually also mentioned another concept, which is a wow moment, right?

And I actually expanded upon that by saying a wow moment should be something that inspires you to talk to your friends, tell your friends about it.

It makes your jaw literally dropped. And it makes you never want to go back to the old way of doing things again.

It creates a clear before and after.

There was you before seeing this demo or seeing this tool, and then there's you after. And it creates a gap, because it makes everything that you used to do before the old way, you didn't even use to call it the old way. It just became the old way once you saw this new thing.

And I think developers love something that takes away some pain that they might feel at their core, but maybe sometimes they don't even know that they have it.

So I'll give you one example, which is Prettier in the JavaScript ecosystem.

Anyone could have built Prettier in any of JavaScript's 25 years of existence, but nobody did.

Until it was some-- It's Christopher Chedeau, but someone just went like, "Hey, Go has this really nice formatting tool. What if we just had that in JavaScript? And what if it was just standard."

And he built it, and now it is standard in the span of two to three years in JavaScript, which is massive.

And people love Prettier for what it does. Which is pretty funny.

The thing is you'll never make everyone happy.

There's a very strong band of people in JavaScript who don't like Prettier for their own reasons.

But you make a lot of people happy and they do say that they love Prettier.

So I think that's one of those examples where, there was an old way, which is you manually formatted your code and you had code review stand up meetings, where you argued over the spacing.

I've been in those meetings, okay?

And then there's an after, with this tool, where you no longer spend any time on that, because you just have a standardized tool that just does all that for you.

So I like that. And I think that's one example of making things that developers love.

Patrick: Aside from beautiful code.

I always ask people, what's one thing you're loving right now?

Swyx: I'm loving Transistor.fm for hosting my podcasts.

I do run a couple of small podcasts, nothing like yours.

But it makes it very easy to host stuff and generates a website for you.

And it just takes away all the pain for me that I don't want to do.

So I will pick Transistor.

I guess I also pick Stripe, because it's such an easy--

I wrote a book and I run the entire fulfillment from beginning to end, and Stripe checkout was so such an easy thing to integrate that I happily paid them their 3% or whatever it is.

Patrick: Yeah.

Swyx: Not a very non-consensus pick. I have to pick Stripe. But I do have to give them credit.

Patrick: Well, you've been super generous with your time today.

We've covered a lot of really fascinating topics.

If people want to learn more about you and what you're working on, where online would you send them to go do that?

Swyx: Yeah. Thanks for having me. My Twitter is where I'm most active.

So twitter.com/swyx. And you can find my blog at swyx.io to get all my talks and book and whatever else you want to find out about these ideas.

Patrick: Awesome. Well, thanks so much for coming on the show.

Swyx: Thanks for having me.