Building technical communities, with swyx, Head of Developer Experience at Temporal

Transcript

Beyang Liu:

Hey everyone, welcome back to another edition of the Sourcegraph podcast. I'm Beyang again. Today, I'm here with Shawn Wang, also known as swyx online. Swyx is the co-founder of Svelte Society, which fosters the community around Svelte JS around the world. He also grew the team of moderators that runs the React subreddit as a prominent member of that community. And he's also a prominent member of the Learn in Public movement. And he shares his insights on learning and leveling up in code with everyone. He's the author of The Coding Career Handbook, a book about how to grow from a junior to a senior developer. And he's written a ton of great blog posts, some of which we'll hopefully get into, that range from topics like the state of the JavaScript ecosystem to the economics of API development. He's worked on developer experience at Netlify, AWS, and now Temporal, and he also has a great podcast and newsletter which you all should subscribe to. So, with that, swyx, welcome to the show.

swyx:

That was a great intro, Beyang, thank you. It's an honor to be on.

Beyang Liu:

Awesome. So before we get into all that, I always like to start out by asking folks, for you, the journey into programming in the world of code, how did that start?

swyx:

Yeah, I have one of those multiple stutter stop starts. So this is a complicated question for me and I'm not super proud of it, but it's just the truth. And I think there are a lot of people like me, so I'm happy to tell that story. I guess I first interacted with code when I was 12ish. We had a Basic, like a QBasic course in school, and I should have picked up on the clues because we were assigned to do like a Basic, like a stack interpreter or like a stack program where we could pop things on and off the stack. And I was the only one that implemented a graphical user interface on top of my implementation. Everyone else did just like a simple CLI. I made a CLI in the UI. So I made a UI in the CLI to visualize the stack.

Beyang Liu:

Oh, that's awesome.

swyx:

And then I stopped there because I was-

Beyang Liu:

You're like, oh, that was cool. That was a fun project.

swyx:

That's all I can do with it. And then I just went back to playing Gameboy or something. I should have just taken the hint that like I was interested in UI and I could go further than my peers. So I didn't really touch programming. I think the other thing that probably a lot of people also resonate with was that I just didn't see myself like the other hackers. I saw some of my friends who were programmers getting in very early and just hammering away on the terminal, right? And I didn't know all these Bash commands and I was just like, yeah, I'm not like them.

I don't know anything that they know. So that's probably not me. And so I fell into a different path, which was finance and that was my first career. And this was very much in the context of the great recession, just seeing how badly everything was mismanaged and how much we had to learn about finance and also wanting to be independent of the economic cycle because I kind of saw hedge funds as the only way in which you could profit from things going down.

Beyang Liu:

Like a downturn.

swyx:

Like most of the economy’s tied to just positive data. But in a hedge fund you can actually switch to negative data. So, I basically set from my high school days, set a goal for myself to work at a hedge fund. Over the next, like 10ish years, I achieved that. But in the process, like you also start to learn to code and this is a weird thing that's also becoming more and more true in the finance world.

If you're young in finance, you basically become a programmer just because the older people don't want to learn it so they throw all the coding related stuff to the juniors. And of course they don't have a budget to hire a dedicated programmer. So I started with VBA just to automate Excel and then in Excel you hit some limits and it's a very crude language so then you go to Python and then I was doing currency derivatives trading. So I did Haskell and people are always impressed that I learned Haskell and did production Haskell for two years.

And I didn't consider myself a programmer just because I didn't have a choice that the house language, the house library for calculating option pricing, was in Haskell. It was pretty funny because I think basically one guy got a job there and then just pulled in the entire Haskell core team to work there. And at some point, like instead of trying, the whole bank was just pot committed. They had built so much infrastructure and then they just couldn't. So it’s pretty funny how you embed a language community within a company and kind of don't give them a choice. This very similar thing that Jordan Walke did at Reason for ReasonML and Facebook. Now they're called Rescript because if you just use it to build production infrastructure, then they now rely on it.

And that's a very fun trick to grow a language. Anyway, I never considered, and just to be clear, like I did this, I built tools that I could use for myself, right. So I did not consider myself a programmer. Although I could code, it was like 5% of my job rather than like 90% of my job, right. So that's the way that I would frame it. And eventually, I think what I realized was that I was a script monkey. I would run analysis, do a lot of number crunching and then my boss would be like, “But what about this other scenario?” And then I would have to go do that, go do a different scenario again. And I realized that I was kind of the bottleneck for my code no matter how well I did. I was the sort of data analyst, so punching away at the thing. And I wanted to do user interfaces–that's the real unlock for turning business logic into products, essentially, that anyone could use.

So then I pivoted hard into JavaScript and that was actually harder to learn than Haskell, I would say, because it's a very incompatible and confusing ecosystem. Haskell has a very small user base. Everything is functionally typed. There's very strong guarantees. JavaScript is not that, right? Like when I was learning it, it was still like, is this ES5? Like we're going into ES6. But you transpile this here and then like there's Node, that's different from the browser stuff.

Beyang Liu:

It's just getting a dev environment set up, just so many options, yeah.

swyx:

I did freeCodeCamp to kind of learn it nights and weekends, and then eventually decided I needed professional help so I paid for a bootcamp and that started my dev career. I started out in Two Sigma. And when you do a career transition like that from finance to tech, the general advice I give people is to trade in your used experience for your new one.

So I managed to not start exactly from zero because I could tell a story of like, hey, I used to work in finance, but I want to switch to dev now. You can use someone of my background because I know finance really well, but I'm a newer dev. So that's what Two Sigma hired me for. And then completely did not use the finance experience. Like you tell one story to get the job and then they completely mismanage you. So I was very bored then. That's when I started the whole learning in public thing, because I think in finance, that's the other story as well, which is in finance, everything's very private because it's a very zero-sum field. You don't want to share your secrets.

Whereas in tech, it's fundamentally more open. And I was very frustrated within Two Sigma because we weren't moving at all. Not even like not fast enough, we just weren't moving at all. So I just started getting active in the New York tech scene and New York City is a big part of my coming up story, which is how I started doing talks and writing blog posts and generally plugging into what everyone else was doing.

And I generally view this as career advice for people as well. Like sometimes if you only depend on your mentors at work, then it's kind of like a roll of the dice of whether you have good mentors or not, but if you build a network externally, then you can pick your mentors and that's a much wider field. So that's what happened to me. I started doing a lot of work in React and so I got involved in the React subreddit and helped to grow it to from like 30,000 members to 220,000 and then I left. And then started getting to developer relations. So Netlify hired me to do DevRel and then I did that for two years and then AWS, and now I'm head of DevEx at Temporal. That's the long story of my life.

Beyang Liu:

That's such a whirlwind. I think the first question I want to ask is: going from finance to open source JavaScript communities–that's a pretty big leap. And I feel like finance is, I mean, it's a well-compensated field. A lot of people might be wondering, “How did you develop the kind of conviction or the courage to go and make such a big leap?” Especially since by a lot of people's standards, you probably had it pretty good, at least from a financial economic point of view.

swyx:

Yeah. I probably made more. So I think my first year at the hedge fund, that was at Balyasny, I made 350K. And I would be making much more now. And so I would have made more in my finance career. But I really genuinely realized that money wasn't everything. And I just wasn't enjoying the job. And I wasn't bad, but I wasn't going to be a rockstar in the industry. And so we had an analyst ranking and I came like dead middle. And I was just like, I'm working so hard, there's some nights I slept under a table. And then the real breaking point for me was I started having a heart palpitation about one of my positions where there was an earnings call the next day and I realized that if I had a heart attack and died doing this job-

Beyang Liu:

Oh, like you had a literal like-

swyx:

Palpitations.

Beyang Liu:

Oh wow.

swyx:

I just got so stressed out and I was alone in my bed and I was just like, okay, if this develops into a full on heart attack because of my unhealthy lifestyle plus stress, what's the point?

Beyang Liu:

Yeah. Health is everything.

swyx:

So that was really my breaking point. I was just like, okay, you know what, I've always enjoyed this, making the tools for finance for myself. And people have always said this is something that I contribute a lot of value on. And then the finance part, like it pays well, but I also don't super enjoy it and it's very high stress. Maybe I just go all in on the tech side. So that's one thing. The second thing is I spent a year as a non-technical PM at a FinTech startup before making the leap to full developer. I actually took this very slowly. A lot of people would have just gone cold turkey right there. But I did one year as a non-technical PM and I did freeCodeCamp to prove to myself that I could complete a coding curriculum before deciding to take the full-time leap.

Beyang Liu:

Awesome. So, methodical and with eyes wide open. I like it.

swyx:

Yeah. Well, I was giving up a lot with the finance career. I worked so hard since high school to get to a hedge fund only to arrive and realize that that wasn't something I really wanted to do. So yeah, I can still go back if I want to, but now I don't.

Beyang Liu:

Yeah. I'm super thankful and I'm sure a lot of other people who've learned from you are super glad that you made the transition. So thank you for doing that.

swyx:

Yeah. It's funny because you often think when people say, money isn't everything, you think they're full of it, but it's really true.

Beyang Liu:

It's like that meme where it's like the bell curve and it's like on one end it's like money isn't everything and in the middle it's like, oh yeah, make as much money as possible then like on the other end of it, it's like, yeah, money isn't everything. There's a lot to life.

swyx:

There's a lot of bell curves. I've actually written blog posts about how pervasive the bell curve meme is in a lot of parts of our life. And I don't know, I think basically what that entails is that there are countervailing factors that underlie the bell curve that contribute to the end result of the bell curve.

Beyang Liu:

Tell me about getting into React because one of the things I like about you is you have such a multidimensional aspect to what you do. You do development, you do community building, you do a fair amount of writing and talking about high level trends and ideas. So for you, as a person who's new to the JavaScript world, how did you get into the React ecosystem and specifically, how did you become one of the moderators for the React subreddit?

swyx:

Oh yeah. I can tell that story. So we talked about how I realized that building UI is kind of the unlock for creating products. And that sparked my eventual journey towards web development and JavaScript and frontend. And of course React is the predominant frontend framework. I actually started with Vue because I thought that Vue.js was just easy to get started with. It looks more like HTML but then I realized that I wanted React. So I just pivoted and learned the most popular framework. And that's really it. Yeah. React is the most predominant framework with the most jobs and the biggest ecosystem. So I figured if other people can learn it, I can learn it too. And eventually I got over all the learning hurdles. But I definitely say it was harder to learn than Vue.js and yeah, I think that got me my first job at Two Sigma and then getting into the community was a matter of me being bored at work and wanting more professional growth.

Getting involved in the React New York City meetups was really important to me. And then writing blog posts about the new stuff that was coming out in React. Like it just so happened that when I was starting to write blog posts, React had announced this new feature that was originally called Async React and now it's called Concurrent React. And it was a big deal at the time. No one really knew what it was. So all I did was, as a new person, just go over the demos line by line and really explain and understand these concepts and then repeating that for the next three years. Because it turned out that it wasn't going to be released for another three years. It's still not fully released today. But yeah, whenever I think people want to break into an industry, it can often help to focus on “new shiny” because there's just less competition and a lot of people, the downside is that you don't have as much context.

So you do have to do the work to go back in time and look at the history and look at old discussions to see where to place this in context. The upside is you have more time to spend on this new stuff than everyone else who's actually working on real production stuff. And so you have to respect that dynamic, which is that you're like a journalist trying to interpret what's going on as it happens and you're not going to know everything and that's okay. And I think the other part, which I accidentally stumbled into, there's this philosophy, which I call “pick up what you put down”–pick up what others put down. If you want to guarantee a response from people when you write blogs or tweets, just write about what they're doing. There's nothing people are more interested in than themselves or their work.

Beyang Liu:

Find someone else doing some piece of work that you find interesting and then just write your perspective on that.

swyx:

And it should be something recent because they'll be very keen to read what you think, what you came away with–even if it's wrong. And if it's wrong, they'll correct you. But what they won't do is ignore you, which I think a lot of people, when they create content, they struggle to get noticed. And so I'm not saying you should intentionally try to provoke people with sensational takes, but you should really be a partner, be a collaborator even. Start a conversation with the people working on interesting stuff, including startups. I make it a habit to shout out startups that do interesting work and I'm sure every single startup has a Slack channel that monitors their Twitter mentions.

I'm sure everyone reads it. And if they say something really good, you'll retweet it. And if it's something wrong, you'll just correct it. And that's just how this works. And if you do that often enough and you show that you're progressing with a good slope of learning, you become known as someone who just genuinely learns well and is a good member of the community. And then people are incentivized to work with you because you then amplify their message. Right? Like I'm trying to get some message out there, but you for example, you have the burden of knowledge, like you're an expert in this topic and you only use terminology that makes sense to you, that makes you look smart.

Whereas I don't have any of that ego. I can look as stupid as I want and use terminology that would make sense to a total beginner. It's a really interesting phenomenon where you can turn ignorance into power instead of knowledge.

I definitely find a lot of that theme in my work.

Beyang Liu:

Yeah. And this kind of feeds into the whole value of learning in public too. And I like that aspect of it because I think when you're building something, you just want to share it with the world. And you obviously think it's the best thing in the world, but the whole world also knows that you're the one who created it so you're clearly biased.

When someone else comes along and reacts to your work in any way... And as long as it's good faith effort on both sides, chances are you'll find some sort of agreement or alignment of interest there. And that is just so powerful when you have that first kind of external person, the person who's not involved with your project in any way, but tries it out, spends their time, and shares it with others. One endorsement from someone like that is worth a 100 of your own tweets or self promotions, however well-intentioned or good-natured.

swyx:

Exactly.

And I think it should be thoughtful as well. You can't just go, "I think Sourcegraph is great," and then, end of story. You should go into a bit of why and what makes a difference. Put some thought into it. But that kind of feedback really helps, especially in the early days. So of course, when I was doing this for React, React was not early, but that part of React was early. And I think you can find parts of this in any ecosystem. I could go into Rails and do this exact same thing.

And yeah, I think it's just a career hack. I think it's going to be kind of bringing this to the book and the learning in public stuff. I think that when people start out in tech, we always want to hire seniors. Every company in the world just wants independently capable senior engineers. But there's a lot of people coming out of boot camps, or self-taught, or coming out of colleges and they don't really have that path from junior to senior. So I think this is a hack, just trying out stuff from senior engineers and just doing that for a couple years. And eventually, soon enough, you're working with them at least on an informal basis and pretty soon they'll turn it formal.

Beyang Liu:

Yeah, that's awesome. Pick up what others put down. That's such a great maxim.

swyx:

I mean, it's one of two acronyms that we use in our Discord. So, we have a small, private Discord for the book. And yeah, P.U.W.P.D. We just kind of put it in there. Everyone knows what that means. Which looks like the beginnings of a cult. But hopefully, it benefits people.

Beyang Liu:

All for good. You said it was a private Discord, like you're supposed to-

swyx:

Yeah, it's a paid discord.

This is the other insight that I had. When people read books, when people watch movies, when they listen to podcasts, there should be a way to continue the conversation, because it kind of sucks to read something really good or listen to something really good and then turn around and no one else around you has read it. You have to look for community. So I always think that every book should essentially come with a Discord and that's what I did for my book.

Beyang Liu:

So anyone who buys a book and reads it can join this discord and chat with others who... Is that the idea or?

swyx:

It's currently a second tier, so...

Beyang Liu:

Okay, got it.

swyx:

There's two reasons for that. One is basically I just wanted to see if I could make a difference here for the book. But secondly, it is my live time. I'm in there every single day. Whereas the book is kind of a one off thing, so... It was weird. How do you put a value on your own time when it's potentially multi-year? So I just made up a number and I said, "It's 40 bucks." Whatever. And then, just threw it in there. Yeah also, Discord isn't really geared for any sort of paid access. Actually, any member in that Discord could create an invite and just get their friends in. But I'm kind of relying on the fact that you get out what you put in, right?

Beyang Liu:

Totally.

swyx:

Just getting membership isn't enough. You have to be an active participant. I have to chat with you. I've helped someone go from junior to senior actually within their career in that Discord. And I think their pay went up 80% just in the process, because we also talked about negotiation stuff. And it's just really great.

Beyang Liu:

Probably the best 40 bucks they ever spent.

swyx:

Right. I think that he's pretty happy. But yeah, and others just kind of lurk and they don't get any value out of it. So, I don't really mind that much.

Beyang Liu:

What is it like to moderate an online community of... What is it? It went from 20,000 to 200,000. The React subreddit while you were a moderator. What was that like?

swyx:

Oh yeah, I forgot to mention how I got involved. Essentially, I was a redditor before I was on Twitter, just because I like talking about games, TV shows, movies, that kind of stuff.

And then, I discovered there's programming stuff on Reddit and it's actually pretty active. And essentially, I think there was a flame war one day between frameworks, you know how people get really religious about frameworks. And Dan Abramov, because I had been corresponding back and forth with him on the Async React stuff was like, "Hey! Next time you see this, can you shut it down?" And I was like, "I'm not a moderator. I don't have the ability to shut it down." And he went away for five minutes, came back, he was like, "Now, you are."

Beyang Liu:

Nice.

swyx:

That was the application process. I think some amount of trust and the React team definitely cares about its community. It's not part of their job, but it definitely is an extension of work.

Beyang Liu:

It's so important. Yeah.

swyx:

So yeah, I think growing it is a matter of setting examples, setting rules, and then just showing up for a long time. It's the unglamorous part that people don't really get. The glamorous part is being able to throw events, getting people hired, having people launch demos and libraries in your community and having a positive response.

That's a really awesome thing to support creators and promote projects that are worth that attention. But then, the unglamorous part is dealing with people who are kind of mean. Reddit is a pseudonymous community, so people don't necessarily feel the need to be nice to each other. And then, also, the fact that people just kind of don't stick around. A lot of people join and leave or they join and lurk. I think we had something like 1.6 million page views, but only on the order of 2 to 3000 comments a day.

Beyang Liu:

Interesting.

swyx:

So, there's a lot of lurkers and people want free information and that's just kind of how it is. And so, as a community manager, you don't have the power to make people do things. You just have to make it an inviting environment where there's a reasonable expectation that if you put stuff up, you get a good response. And then, just let people bubble up through there. That's kind of how I view it. It's just a role. It's definitely more of a service role than a job in my mind.

But I definitely think this idea of a technical community–people are taking it more seriously because ultimately that's the moat, right? Around any company. Anyone like AWS can come along and clone any of your features eventually. But they cannot steal your community if you've built it strong enough–including your paid customers if you have a strong relationship with them and so on. One of my posts around this has been this idea of a technical community builder and how more and more startups are trying to hire around this. I'm curious if you are actively building for this role as well.

Beyang Liu:

Yeah. I mean, we're trying to spin up a community around Sourcegraph. We're kind of weird because our early adopter market was fairly large engineering organizations and enterprises. I think that's just due to the nature of code search. A lot of these companies were experiencing the pains of the giant code bases so much so that they were looking at building their own internal code search by the time that they found out about us. So, it was kind of a much easier sell into those organizations.

And so that's where we started, but we always had this vision. The original vision for Sourcegraph was just to build this single portal where all the code in the world and the code that you're interested in or might be interested in specifically is accessible from a single search box. And so, a big effort for us right now is kind of warming this community back up because it was just not a focus for our company for a number of years. But we think it is central to our mission and what we want to do. And I would love to hear your advice for both us and other developer tool creators and founders here about how to build and foster that strong technical community.

swyx:

Yeah. I don't have zero experience, but I'm also not the world expert on this thing. So I should probably list out the stuff that I've done, right? So, I helped to grow the React reddit from 30 to 220,000. And then, I left React and started Svelte Society from zero. I helped from the first meeting. And we're about to hit 10,000 people.

And then, I was part of Netlify as we established the Jamstack community. And now, we're trying to grow that at Temporal as well. I think that we have a similar issue with Temporal as you do. We're adopted by people with microservice orchestration problems, which is generally large companies. So, it's a different topic for a frontend community where you can be productive with just a single person on a browser. The advice that I typically give to people, because a lot of people definitely reached out to me after that blog post is: hire from your community rather than trying to install someone with a proven track record in a different community, because I don't think it transfers that well. Because they might just fundamentally not get the community. And you want someone who already embodies the kind of person that you want more of, right?

So I always say, "Pick the community member who you would most like to clone." Because essentially, if you make that their whole job, then they will start cloning themselves in whatever way. It could be from product decisions, marketing messaging, to just the networks that they're already in. They serve as a beacon or lighthouse for people like them to come on in. And so, there's good and bad. You will necessarily exclude some people just as a result of unintentional consequences. So, you do have to pick somewhat carefully. But what I'm basically saying not to do is say, "Okay, this person has 10 years managing community at, name your other startup. Let's just hire them. They've done it before they can do it again here."

I don't think that works because they may not get it.

Beyang Liu:

Because so much of the qualification for the role is just understanding your specific tool and how it impacts the users' lives, right?

swyx:

Yeah.

Beyang Liu:

So, that’s the most important qualifier is what you're saying?

swyx:

Exactly. Same thing for developer relations, by the way. The joke that I have is: don't hire an experienced DevRel person from some other community and then expect them to npm-install audience–just like, "Okay, let's look for the highest follower account and then just hire that one and then..."

It's silly. They're there as a part of their community and you really need to screen for "Do they have the relationships and the fundamental background to be an evangelist and to connect people?"

So coming onto the difference between DevRel and community, community is much more about getting members talking to each other whereas DevRel's kind of content creation from one to many, instead of many to many.

Beyang Liu:

I see.

swyx:

And there's definitely some overlap, DevRel performs part of community membership. And that's mostly because community building is not so much of a recognized career path or discipline within tech companies just yet. We had a community support manager at Netlify and there was no career path for them. They just kind of managed the forums and it was just kind of off at the edges.

But I definitely think what's happening right now is more people are realizing that community should be a bigger informer of product decisions, marketing decisions, anything like that. And so, it might be true that communities are basically moving from the periphery where it's like, "Okay, let's do everything first and then inform the community," towards more of a community at the core where, "Let's see what's going on in the community, what they're telling us," and drive those marketing or product decisions off of that.

Beyang Liu:

I think more and more people are starting to recognize the value of communities. It's one of those things where it's difficult to put a number on it or to measure it in a traditional corporate setting. And so, a lot of it is kind of just trust based. You have to find someone who gets your community and who you kind of trust to do right by the community.

swyx:

I have a couple other thoughts. I just want to make sure I mention them before we get too in the weeds on one angle. The other angle is I always like is the idea that people are there for something bigger than themselves. And so, the traditional element of this is a very marketing driven idea of category creation, right? At Netlify, we created the category of Jamstack and got a lot of people, including competitors, to join this movement. And that's beneficial for you because if you let it and you coined it, you have a much better shot of owning this growing market.

And so, people also like talking about this idea better because they don't necessarily promote you as a company. So you can remove that corporate interest because this idea is bigger than you. And it's much easier to join a community like that than to say, "Join the Sourcegraph community or join the Temporal community."

Beyang Liu:

For sure.

swyx:

Because it's kind of more awkward to do free work essentially. If someone asks a question, "Should the assigned support engineer do it, or should I as a knowledgeable community member?" If it's the Sourcegraph forum, I'll just wait for someone from Sourcegraph to do it.

Beyang Liu:

Right.

swyx:

But if it was an open source framework or a movement that's bigger than any one company, I'm more inclined to do that, because I want to be a prominent member of that community. There's just more for me at stake.

Beyang Liu:

Yeah. I mean, the way we think about it, and maybe we should just be more explicit about this as well, is for us as a business a lot of what we do is not so much promote Sourcegraph, but promote the idea of code search, because I think it's one of those ideas that is still at kind of the... I think–we all think–it's going to be nearly ubiquitous in the next couple years. Five years from now, people will look back and say, "How did we ever do development without code search everywhere?" But right now, it's still kind of this best kept secret sort of thing where there's a certain segment of developers who are just completely sold on it like people who worked at Google, or Facebook, or another big tech company that had a great internal code search.

And then, there's everyone else who has never used it before and just don't get it. They're like, "Well, how's this different from ‘I can just grep for stuff.’ I check out most of the code that I interact with day to day in my local editor. So, I don't get it."

And so maybe, that's the key insight for us. Code search, that's the thing that we want to make ubiquitous. And we should just push that because we think that's going to be this great thing for the world. It's going to unlock the world of code and make it accessible and valuable to so many new people out there especially as the world of code is growing itself. You have all these new people getting into the industry, getting into the world of code now. Anyways, this is kind of turning into a sales pitch for Sourcegraph. So, I'll stop there.

swyx:

No. Well obviously, you work on it every day and if people are listening to the Sourcegraph podcast, they signed up for this. It's rare to have a CTO podcasting, so kudos on doing this. But people are signed up for the journey, right? They want to see your thoughts evolve. And if they have something that they want to contribute, they can listen to what you just said and say, "Okay, I can get in on that. Or here's how I think about it differently." And it's very much building in public and I think that's always to be celebrated. You shouldn't be embarrassed about that. But no, I definitely think promoting the category makes more sense. There's another thing. So it's not just about being so unafraid of competitors that you're like, "Just come on in. I don't care. Let's just make this a thing." And then, the other thing is having people expect to be part of your community longer than any current employment. That is a real community, right?

They're not just joining a support forum for a vendor. This is literally like, "I identify with this thing more than my current job."

Beyang Liu:

Yeah. And that's so important and it has to be an authentic thing, right? Because I feel for me at least, every time I evaluate a community, or a piece of technology, or even a blog post, there's this detector in my mind. It's like, "Is this a real post, or is this content marketing to sell me something?" It's just such a sharp distinction. And I often think that writing the good posts, the thing that's broadly educational, informative, insightful, is better in the long-term than just taking a shortcut and trying to quick-sell someone on a thing.

swyx:

I do a lot of thinking... And so this is one of the unresolved areas for me, what role do company blogs play?

Beyang Liu:

Well, it's an ongoing discussion for us right now too. Are you familiar with Dan Luu, his writing?

swyx:

I've read his blog, yeah.

Beyang Liu:

He has a post on what makes a good corporate blog.For those listening, I highly recommend that, because he's got some good takes.

swyx:

It's also very much his take, right?

Beyang Liu:

Yeah.

swyx:

At the end of the day, sometimes you need to speak to non-engineers, and a company blog is a really good way to do that. Dan writes for engineers and so he biases towards, hey, GitLab had an outage and they live streamed their outage. That's fantastic. And then they put their postmortem on their blog.

Most sales, marketing people, “That's cool. Transparency around your downtime is fine, but it's not going to sell me on your thing.”

Beyang Liu:

Yeah. Let's talk more about the work you're doing now at Temporal, because I think it's really interesting. Maybe can we start with why you joined them in the first place because I think that there's an interesting backstory there?

swyx:

Yes. I don't know if we talked about this, because I say it to a number of people. But it's something I haven't shared enough about. It's like, what is a frontend guy like me doing at a backend place like this, essentially?

Beyang Liu:

Yeah.

swyx:

I've never worked on a giant distributed system and it's a very strange journey. But essentially, going from frontend to backend is essentially the process of diving deeper and deeper into platforms and developer experience. I started at Two Sigma as a frontend engineer. And then I joined Netlify working on Jamstack, which is essentially like DevOps as a service for frontend developers where you rely on creating a lot of single-page and static-site apps in the frontend, and use serverless functions to stitch together the rest.

The problem with serverless functions is that they're very limited in what they can do. I joined AWS with the hope that we would be able to do more, and AWS is starting to innovate on this. They have service containers with AWS Fargate.

But there's still this idea of lacking a central brain, and basically the real wow moment for me was watching DHH demo Rails–that famous 15-minute talk. If anyone is in the Rails ecosystem, if they're in a Rails ecosystem, they've seen this talk.

And just realizing that I cannot do that with today's technology. I cannot do the full CRUD comments, live updates with today's serverless and React and fancy GraphQL. I don't care what you throw at me. You can't do what Rails did and we lost something.

Right? We moved from the monolith to some distributed system with our frontend fancy app and serverless, infinitely scalable functions, but we lost the developer experience of the monolith. That's it. And it's not just about developer experience. It's about development speed.

Basically, I wrote this blog post about like, okay. I'm basically a salesman for serverless technology right now at Amazon, at Netlify but serverless isn't good enough. We haven't replicated everything that we lost from the good old days of just... I don't know, run a container or run a rack of servers somewhere.

And I was just listing the jobs to be done. If you look at it from “What do I need out of a platform?” and start listing.

And basically right at the top was a central scheduler or orchestrator of all these things, because everything else you can break down into single serverless functions. And that's what I was eventually working my way towards, but I just didn't have the background or the words to phrase this. I wrote up a blog post with something like, “here's what I think is missing in the service ecosystem or that we need to reconstitute the monolith.”

And someone commented and the VC that was funding Temporal read my blog post, thought it was stupid or something and then read the comment. The comment is really smart, tried to correct me, right? Hired the guy to be head of product for Temporal. And the guy turned around and hired me to do DevRel. Out of one blog post, two jobs arise.

Beyang Liu:

That's amazing.

swyx:

I'm currently in his house and that's what learning in public does for you, I think.

Beyang Liu:

Yeah.

swyx:

Seriously, think about the biggest gaps in your space and write about it. And then that serves as a beacon for other people who are also interested in that space to find you and offer you jobs to work on it.

Beyang Liu:

I love that because it's multiple instances of this reacting to what someone else created. You were reacting to the existing landscape and you wrote it and then he replied to the comment and then out of that, just because all that was public, you were both discoverable to this company that was doing exactly... It sounds like what you were both envisioning.

swyx:

And I always say that I got my last three jobs this way. Right? Learning in public has changed my life and that's definitely why I continue to preach it to people, even though I feel very repetitive saying the same stuff again and again, but I will do it because it's really changed my life. And I'm only in year three of this.

And so imagine doing 30 years of this, and I think that's a lot of how the legends in computer programming got going. They just write down what they think and they iterate on it over years.

And it's not about the immediate reactions and like counts and whatever, but really about developing your mental model and relationships with people also interested in that problem. Yeah. I don't know if I should... Should I talk about what Temporal does?

Beyang Liu:

Yeah. I think it'd be at least worthwhile just to go into... Just so people can place it in context. What does it do? And what is the sales pitch for why people should care about it?

swyx:

Yeah. It really depends on your background because I can explain it probably three or four different ways depending on your background.

The general introduction I can go with is that you need to... The most important work at any company involves asynchronous work that ties together multiple services. And when I say service, it could be a microservice, could be a mega service. It could be a serverless function, don't care.

It's just an external dependency that ties into the next external dependency that ties into the next...

Beyang Liu:

Sure. When you say async, you're talking about the pipes or the things that connect these different services?

swyx:

Exactly.

It's beyond the 15 second limit of AWS, the default limit of AWS Lambda doing request and response, right?

Beyang Liu:

Yeah. Yeah.

swyx:

Those tend to be relatively trivial or whatever you can squeeze into a 50 second processing window. But if you think about all the valuable stuff… So I'm talking about one of our customers, Checkr–they're running background checks on gig economy workers, right? Some of that involves making a trip to the court system to pull their criminal records and stuff like that. That can take multiple days or if you think about the origins of Temporal, which was started at Uber, how do you track an entire journey from booking a trip? Say, I want to travel here matching with a car, getting on the car, dropping them off, emailing the receipt, doing the rating and so on and so forth like that, that whole journey.

How do you model that? Right? You can model that with a bunch of cron jobs and schedulers and there are different teams responsible for each part of this stuff.

But you need some way to tie all these things together. The traditional way, this develops in a microservices hairball, is that each service is responsible for calling the next service. But that tends to have a very exponential complexity. And you want to centralize everything into a linear complexity with a central orchestrator tool, which a bunch of different companies have built.

Temporal is basically spun out of work that was done at Amazon, Microsoft, and Uber to solve this orchestration problem between services. And that's the first opinion. The second opinion is event sourcing. Deriving everything from an immutable log of histories, rather than having a central, immutable states thing.

Beyang Liu:

Is that getting rid of a database or what do you mean by...

swyx:

Deriving your state from all the events that have happened up till now.

Beyang Liu:

Okay.

swyx:

Imagine if you develop your source code without Git, and you would just zip up your files.

Beyang Liu:

You can't revert... Yeah.

swyx:

Exactly. You can't revert. You can't really audit what happened. And if you stop your work and you transfer to a different machine, it's very hard to resume in the exact same state because you don't have that precise replay mechanism. Git is a similar analogy, right? You have the log of all events. You don't necessarily need that full log, but it's there if you want it. But more importantly, you can replay anything that happens and restart from any system.

That's how you make the central orchestrator, because the problem with introducing the central orchestrator is that you've now introduced the central dependency to every part of your system.

And so you need to make it foolproof to that central system going down. And the way you do that is you derive everything off of your logs. Every state has to be logged or it didn't happen. Right? That's the second opinion which is event sourcing rather than database and optional log or a secondary log as a second concern. No, the log is the source of truth.

Beyang Liu:

Got it.

swyx:

And then the final opinion is the programming model. A lot of orchestrators that are out there... The competitors are things like Apache Airflow, AWS Step Functions. And there's a bunch of other alternatives. Google has a workflows product as well that they're pushing.

All of these are based on JSON and YAML, right? Which is very amenable to low code, drag and drop. If this and then do these things in parallel and then get the results from here and then tie them all together and send them to one final service.

You end up writing these very complicated JSON and YAML setups for anything beyond a trivial "if this then that" workflow and the central thesis is that the best language for doing all this is a real programming language, meaning Go, Java, Python, Node. And all the other SDKs that we're doing because if you try to stay within JSON and YAML, you end up inventing a DSL.

I think it's Greenspun's law, any configuration language has a half implemented version of...

Beyang Liu:

This list.

swyx:

I'm misquoting this, but I really believe it's true. Look at Google Workflows' orchestration language.

And you have an if, and its curly brace, and then you're writing the AST of a language that you should be writing. And so write things in familiar languages and use the libraries that you're familiar with, but also test them using the standard testing tools that you know and love. Those are the three main opinions I think of Temporal, which is... I'll recap.

The first is that you should have an orchestrator rather than choreography, which is the other terminology.

Second is event sourcing and third is to use a real programming language.

Beyang Liu:

Cool. That's pretty cool. If folks want to try that out, do they just go to temporal.io?

swyx:

Yeah. Yeah. It's open source so you can run it yourself and not pay us a single cent. And then we run the hosted version just like any other open source company. Yeah. It's weird.

The other thing as well is there are components to this underlying. It basically solves distributed transactions for you as well. People use us for that and I'm having to learn all this as I go, because I'm technically responsible for DevRel and content and stuff like that. But it's good. I think if you develop a reputation as someone who can pick up anything, then that's a very transferable, valuable skill.

Beyang Liu:

Oh yeah. For sure. Do you have any impressions going from being mainly frontend focused to now, diving into all this backend stuff? What are your thoughts on the backend world?

swyx:

Oh, so many. So many. It is a different culture. I actually love it. I really, really do. The hot take... I'll put this right at the top is that backend engineers make more money. I have a higher career ceiling than frontend engineers. Straight up, how many CTOs are frontend background versus backend background? Right?

Beyang Liu:

Interesting. That's your claim? That would be your assertion?

swyx:

Yes. And I think there's some empirical evidence, but there's no industry survey or anything of CTOs that asks "how many of you are frontend?" It just is a natural assumption that if you look at a frontend engineer, you don't see a CTO in there in general.

Beyang Liu:

Why is that, do you think?

swyx:

Why is that and obviously this is not generally true.

Beyang Liu:

We're just thinking out loud here.

swyx:

Yeah. I think the assertion is that backend engineers command more dollars. At the end of the day, power comes with money and backend engineers command infrastructure. If you pay AWS $3 million, that person's going to be in charge of your tech.

Beyang Liu:

Right. Right.

swyx:

Okay. You pay what? Your pay React nothing.

Beyang Liu:

Right.

swyx:

Deal with browser inconsistencies. That's going to be, politically, in terms of internal office politics, smaller.

And that's just the reality of the industry. Part of my own migration from frontend to backend has been in recognition of this fact, that frontend is not a very valued skill in the industry, partially because it's been so open source. There's nothing proprietary to this. Everyone can learn it, which is good. A lot of people make frontend very accessible. Right?

Beyang Liu:

Yeah.

swyx:

But partially, because I think the experience doesn't scale. Your job is to make the experience look good on every device. Right?

Beyang Liu:

Yeah.

swyx:

And make performance fast, add really good, new features.

Beyang Liu:

Yeah.

swyx:

But backend has a benefit to centralization. Owning the backend for a giant company gives you experience that no other person can independently bootstrap. Whereas in frontend you can self-teach all of it.

Beyang Liu:

Interesting. But wouldn't the converse be that if you learn one of the popular frontend frameworks, that's very transferable. But if you go on the backend side, what you're doing is working... It's more bespoke or specific to one particular company, but maybe less transferrable from company to company. Do you buy that?

swyx:

That could be the case. I don't want to overstate my claim here. This is just a theory.

Beyang Liu:

Yeah. Yeah.

swyx:

Whatever it is, I definitely see the case that backend developers have a higher career ceiling and spend more money. Let's put it down to this: open source projects, right? People struggle really hard in frontend to fund open source. Whereas in backend, my favorite example is Mike Perham from Rails–he runs Sidekiq. As a solo developer, he maintains Sidekiq, the free open source project, and then he sells support contracts for Sidekiq Pro. Guy makes 2 million a year as a solo developer. That does not happen in frontend, it does not. Why? Right? And it's basically because people run more money through backend work.

Beyang Liu:

Interesting.

swyx:

It's all money. It's power politics.

Beyang Liu:

This is one of the things I appreciate about you as well, because you have this dual tech finance background and you often have a very analytical and strategic way of thinking about the economics of tech. And you actually, you wrote a blog post on the API economy, the economics of... Can you talk a little bit about that? What is your analysis of... because we live in this age where it seems like every other week there's a new API company that's spinning up. Oh we're going to build a new service that's an API to this functionality or this form of data.

swyx:

Yeah. Talking in terms of bell curve again, the really dumb 80 IQ version of this is Stripe for everything. Right? Look at Stripe. They're so successful. That's like API-fy every industry.

And that actually works.

Beyang Liu:

That's the takeaway.

swyx:

That's the 80 IQ takeaway that, hey, developers are very powerful. And if you make more of the world exposed through an API interface that's manipulatable by programmers then you can essentially build your own new real estate or a very valuable company–basically digitizing offline services, right?

Beyang Liu:

Yeah.

swyx:

A lot of web one to web two was like this and I'll definitely classify the economy in web 2.0. The 120 IQ take, which goes past the 100 IQ peak of the bell curve, is that: what happens to the people who stay above, the people who cannot stay above the API? Essentially, we are coming towards a two state, two class economy where either you tell machines what to do or machines tell you what to do. The Uber driver is below the API because a machine tells them where to go and what to pick up. They're essentially servants to the machine, whereas if you stay above the API, you're obviously, you're an Uber customer or whatever, but as above-

Beyang Liu:

Are you following what the algorithm is telling you to do versus are you writing the algorithm? Is that kind of the-

swyx:

Exactly.

Right. And it is more machine learning helps to dictate our decisions and content consumption. That's definitely the case. A lot of our media consumption is already below the API.

So you have more economic power if you stay above and what happens to those below? Should we have universal basic income to take care of them? Blah, blah, blah. Then the 140 IQ take is if you want the most economic power, you manage the people who manage the API. As much as people complain about it being hard to hire developers, if you can manage developers and point them towards a business problem, you have infinite power in this economy.

Beyang Liu:

Yeah. I like that. Can I push back on some aspects of that?

swyx:

Sure.

Beyang Liu:

So is it necessarily that there's this kind of two class hierarchy because I would argue that for any given person, there's probably things that you do above the API and also below the API.

My media consumption–a lot of it is like Twitter or Reddit these days. There's algorithms behind all that deciding what to show in those feeds, but then I go and write code and suddenly, I'm writing an algorithm that helps automate some piece of logic or some rote task that may affect what someone else does downstream, but it's not like I'm on top of them at that point. It's just, algorithms are becoming embedded in every part of life and so they're these things that we interact with now where previously, there was no logic there. It was just a lot of more humans in the mix or just no interaction at all because it was too inefficient to do that.

swyx:

So the pushback is you're not below the API all the time and sometimes you’re above-

Beyang Liu:

Yeah. The two class description of that world seems very bleak to me.

swyx:

I mean, I acknowledge this in the post. It is very bleak, actually. It is a problem, but yeah, we are not always above and not always below, but you definitely spend more time above the API than some others, and you see the economic benefits of that. It's pretty clear which part has economic value and which part is less economically valuable, and that's just a general statement about how power flows through the economy and if you play this, we've only had maybe 10 to 20 years of this. Play this through like another 100, 200 years, we're talking the scale of we're changing our DNA because an API's deciding who we date.

Beyang Liu:

Right. I mean, as someone who met his wife through an app, I guess our marriage is technically below the API in this case.

swyx:

Yeah. It's really, I talk about the economy, but it's actually about civilization and it's really, I don't know what to do about it apart from just raise awareness, but it doesn't have to be a problem, but I think we should, as people who design APIs, be aware of the awesome responsibility of what we do. We should have people at the table who are represented because if it's just a bunch of white and Asian guys sitting in San Francisco designing the experience of the world, then something has to break.

Beyang Liu:

Well, I think a lot of what you're doing is helping with this by learning stuff in public and teaching others and helping with developer education. I think that is one of the pillars of the path forward here, which is algorithms and code, they give you a lot of leverage to make an impact in the world. The more people we can give access to that coding ability, the more people will be in this above-the-API position, or be able to be above the API.

swyx:

Yeah. The manager version of this is above or below the Kanban board. So just to give you that terminology there. Who's above the Kanban board and who's below? It's just another thing. So my role currently is more in product than as a developer. So I've also moved further and further away from the developer career path and that's partially in reflection of this. I don't want to get people too depressed. It's still a great job. We're not going to solve this within our lifetimes, yada, yada. I definitely just encourage developers to think more about the economic underpinnings of their careers.

We stress out so much about clean code and frameworks and argue over code style and stuff like that and don't really worry about, “are you working in the right company?”

So a third, a full third of my book is career strategy, and part of that is tech strategy. Are you working in a company that will scale, or is it just, are you selling dollars for hours, and that has really long downstream effects if you do this for years. So when I think, with tons of people about career choice, it's all of this context building in the macro into the micro decisions of what job you choose.

Beyang Liu:

Yeah. Can we talk a little bit in the brief time remaining about strategies for learning in public because that seems like it's paid off for you a lot, but there's so many different ways that you can be public about your work these days, different channels. There's Twitter, there's Reddit, there's newsletters, which are becoming more of a thing now. There's video content and streaming. From your point of view, do you have thoughts or recommendations for someone who’s just getting into code or someone who’s trying to level up their career, which one of these forums or channels are good and for what types of learning in public?

swyx:

I have a few thoughts on this. This is a great prompt, by the way. One of the reasons I'm so excited to talk with you is you clearly think about these things, which are not technically your job.

Beyang Liu:

Well, thank you.

swyx:

But you're generally very curious. Okay. So here's my state of thinking. First of all, pay attention to the Lindy effect, which is how much things tend to stick around and stay relevant. The half life of content on various platforms is drastically different. A Twitter post stays–you should roughly know these figures. A Twitter post stays relevant or discoverable in people's feeds for roughly four hours. A YouTube post, something on the order of six months to a year, and blog posts and newsletters stay relevant for about two to three years. When you spend your time, you want to essentially build up a content base or a luck surface area of the maximally amount of still relevant work.

Which is how people find you and how you can still build up knowledge. So try to bias towards things which are more Lindy is the general conclusion, but that is also too strict, I think. So you want to, if you only work on things that will last forever, then you may never ship and so I really like to encourage people to do work-in-progress stuff. So I've also started to promote this idea, which I actually just published, that is just called the particle wave duality theory of knowledge.

Beyang Liu:

That sounds cool.

swyx:

Right?

Beyang Liu:

Can we do another episode on that?

swyx:

This is another one of those 120 IQ things. I don't know if I'm getting too big for my britches or something, but this stuff really interests me. Essentially, so here's the gist. If you publish only giant massive masterworks that you spend 40 years to make, people don't really get the benefit of engaging with you and there's just so much content out there. It's hard to engage with really monster masterpieces, and so that's why people like to drip feed things over time and in fact, when you learn stuff, you drip feed over time. You don't learn in one giant leap. So that's sort of the wave, the ongoing stream of consciousness of: here's what I learned today.

Here's what I worked on today, input and output, and you kind of pair that with something more monolithic where you say, okay, here's the big thing I'm building towards, and you can start here and end here and that's a complete journey.

So I think basically, there should be almost like a two-phase commit for all knowledge that you learn and all knowledge that you produce. So you need the continuous stream form, which can be Twitter. It can be Discord chats where you say, here's what I did today and then you also need the async knowledge base of here's everything slotted in its correct, proper place and it's substantial and it's useful as a reference, but you can't build that up in a stream of consciousness way.

Beyang Liu:

So it needs to be multilayered.

swyx:

I think it's exactly two-layered. Find a stream to update. So it could be your newsletter. It could be your Twitter and you can use one for the other. You can use them for the others. A YouTube post can either be a vlog or it can be the definitive talk on something.

Both are possible, but essentially, try to always do things twice. Try to do the update somewhere in your daily journal or in your public tweet stream, and then also store it in its place somewhere else where you can access it in context, and I think that's my learning in public insight.

I'll expand this out for you. If you blog what you learn, it's really hard to follow because no one's going to read through the whole sequence of blogs, but if you build up a wiki, which is what I've done. When I learned Typescript, I didn't learn day by day and blog about my journey as I went. I built a public book about Typescript and that became useful for other people to learn as well.

Beyang Liu:

I see.

swyx:

So different formats are useful to different people. Again, and there's a reversal of this. If I'm an expert, I already know everything. I just want to know diffs. So you just send me the diffs, a continuous stream of diffs and that's fine, but if I'm a beginner, I want the nicely presented, formatted, contextualized body of knowledge. So that's what I mean by particle wave. Knowledge can be presented as both a distinct particle or a continuous stream.

Beyang Liu:

So you have two kinds of two streams. One is quick, daily or weekly, frequent updates, and then the other one is your long running magnum opus, the big thesis or the big idea-

swyx:

Source of truth.

Beyang Liu:

Source of truth, and what you're saying is that you can't derive the source of truth from the daily updates. It's like, you want to have an idea of what the source of truth is, or the big idea that you're working on, and then you just kind of release your, almost like serialize the production of that big work, and that is the daily update that will capture people's attention and be easier on ramps to the big idea. Is that the idea or?

swyx:

I don't care which is primary, which is secondary. I just care that you do both.

Beyang Liu:

Got it.

swyx:

If you build, if you only do one of them, then, for example, if you only do the stream, it's very hard to follow that stream and it's very hard to know what you currently think now.

It's not that useful, and so forth. So there's a database version of this, which is do you only store the logs or do you have materialized views, and I think materialized views are very useful because they reflect the current state of things. Sometimes you want the history as well.

Beyang Liu:

Yeah. Nice tie back. That's great. Okay. Well, so just real quick, what's your example of your daily stream and your longer running source of truth?

swyx:

Yeah, yeah, yeah. So this is how I kind of write my book right now. I published version one last year and especially the community is the ongoing diffs to that book, and then I'm going to tie up my book and so people pay for that. People pay for the book and they pay for the diffs, and then when I published version two, I essentially gathered up all the diffs and published an even better version two.

Beyang Liu:

I see.

swyx:

And to me, that produces so much value for people because they can consume it either way, and for me, it was also much easier to write because it's not this big, heavy lift. I've been working on this book the past year while doing other stuff, and it's just a really great way to be a knowledge worker, I think, and so I'm talking about writing my own book, but you could apply this to work. You could apply this to building a company.

There's this dream, which people who are interested in or who follow the story are interested in, and then here's how to get started from scratch, your docs.

So I definitely think about this in a very fundamental way that permeates. It's a whole view rather than just like, here's the tactical method of: you publish a blog post, then you tweet about it, then you wait seven days and you tweet about it again. That's what a social media strategist would do for you, but the social media general would just be like, here's the allocation of resources and here's why.

Beyang Liu:

This is such a great conversation. Sorry. I'm just jotting down some notes later because I think it's giving me some ideas for the next couple quarters of planning and...

swyx:

I think, yeah, it'll be interesting to apply this to customer relationships as well.

Beyang Liu:

Yeah. I mean, the whole learning in public and building in public thing totally applies to companies, especially when you're building developer tools.

swyx:

It is a very concentrated form of knowledge work and what we are really forming towards is like a theory of knowledge work. How to get this done, how to do really quality focused work, but also keep people involved as you go along, which kind of is more authentic marketing than anything else you could be doing.

Beyang Liu:

All right, man. I wish I could keep talking to you for hours and hours, but you're busy and I want to let you go. Any kind of final parting thought or maybe a call to action for listeners or viewers of this?

swyx:

People always are inspired by the learn in public story and then they write their first blog post and then they tag me on it and they want me to give them kudos, congrats, pat on the back, good job, first blog post, but just understand that this is a journey and a lifestyle. The benefit is all back-end-loaded in the sense that you have to do this for a while. You have to find your voice and find your audience, and eventually, the benefit starts to compound and that's the problem with compounding. It looks like it doesn't work at the start.

Beyang Liu:

It looks like this. It looks like a flat line.

swyx:

Exponential curve. So I definitely try to bootstrap people by talking about “pick up what they put down.” Focus on organic interactions with individuals rather than building up a general faceless audience because then you start to not care about numbers because you only care about did I have a good interaction or not, and you build up enough of those over time, then you will get numbers, but if you start out with that as your goal, I don't think you have the right mindset to achieve the results that you want.

Beyang Liu:

That's great advice. All right, man. This is great. Thanks so much for being on the show.

swyx:

Thanks so much for having me. I've been enjoying the podcast and I'm just glad that you invited me on because I love having chats like this.

This transcript has been lightly edited for clarity and readability.