Jeremy: I did a computer science bachelor's.

Swyx: [00:00:45] Nice.

Jeremy: [00:00:46] It's interesting seeing how you learned because when I went through school, I wasn't super passionate I think particularly because when I was going through school a lot of it was, data structures and algorithms and stuff like that, and it was a little bit disconnected from when I first started where I was like I'm going to make games.

I'm going to make cool GUIs and like when I get to school, it's like there's none of that. It's really on me I should have been seeking that stuff out on my own. It wasn't until a few years later after I had started working where I really started, enjoying the process, enjoying learning about the technologies and building stuff. Looking at what you were doing I definitely should have been doing that when I was going through school

Swyx: [00:01:34] Well, I mean, you're still figuring out what you want when you're still in college, Yeah. I went to school for finance and I no longer do that (laughs). But, yeah, I don't, I mean, don't live life with too many regrets it's not worth it.

I fell into this way of learning because of other people. All I'm doing is trying to spread the message and there will be more beneficiaries of this than me. I'm definitely lacking a lot of things that you learned in college.

I'm trying to make up for it. I really want to take an OS course. I want someone to force me to do a basic operating systems course. And I don't know what a syscall is, and I don't know the details on memory allocation and all that, like, but on some level, it doesn't matter because it depends on what part of the stack you want to work in. But I just don't have the option available to me if I wanted to go further down the stack. I just don't.

I still personally do wish that I did a CS degree. I'm just saying I definitely did not catch up with what you already know just from my bullshit web dev stuff. But, it's enough to get a job, which is absurd. This is the only career where, it's high paid and you can get up there in like three months ish. Maybe you won't be amazing. You're not going to be Jeff Dean or something at Google. But you can get by decently and you get paid the same as a doctor or a lawyer. And that's ridiculous.

Jeremy: [00:03:01] I found that to be pretty pretty insane. Though I will say, when you were talking about you can get a job in just three months or whatever. But your background it's really not the three month boot camp right? You had a much longer tail in terms of all the things that you've learned at your previous jobs. You said you had used Haskell right? That's before you went to the bootcamp

Swyx: [00:03:27] Yeah, I mean, I'm definitely not speaking for myself in terms of the three month thing. But I have seen my fellow bootcamp people get good jobs. Obviously there's a failure rate as some people don't make it. But it doesn't happen for medicine or law

Jeremy: [00:03:39] Yes. Instead, it's six years, eight years, and then like you've talked before, when people learn something, it's normal for them to share what they've learned.

Swyx: [00:03:48] Also we'll promote you for it if you do a great job. It's just fun.

Jeremy: [00:03:54] I think when I first heard about you is-- I read hacker news relatively regularly and I remember you had made a post and you were saying: I used to be in finance, I'm going to do this boot camp. And so I'm doing this podcast where I interview people in my class and just a few years later, now you're like all over the place. You've got all these blog posts. You're moderating the React subreddit, you were recently, a senior dev at Netlify and I was like, this is crazy. This guy who was talking about going into a bootcamp just a few years ago he's doing so many things. I think there's a lot of lessons that people can learn from your experience starting their careers, learning how to learn, and deciding how to progress in general.

Swyx: [00:04:45] Thank you. I don't know what to say that. Yeah. I'm trying to write it down. Basically I have a lull between jobs. I'm going to join Amazon by the time this comes out. This is the only time I feel like I can write a career advice book because after this I want to focus on other things.

I guess I had a relatively fast trajectory. I finished my boot camp at the end of 2017. Started my first dev job in January of 2018 and then just got hired at Amazon at an L6 level in March of 2020. That's a relatively fast trajectory for anyone.

I'm not completely new to programming. I have done some code before, but then also I do attribute a lot of that to the ability to just learn very quickly in public.

And a lot of people I think it's an alien concept. They vaguely know it's a good idea. I think they don't know how good. Just the relative rarity of people doing it means that being part of that population makes you stand out. And that's very beneficial for careers even before the current situation we are in, which is now everything's online.

So your professional profile doesn't have a physical presence anymore. You don't have to become a celebrity, a lot of people are like, ah, you have to be an influencer.

No. It's more about just like having a place that you call home online. And you as a developer have an abnormal amount of control over that and you should exploit that as much as possible.

Jeremy: [00:06:25] Yeah. When you talk about learning in public you talk about exploiting that, right? It almost makes it sound like the fact that you are learning in public is a big benefit to you. You're getting things from people, whereas, I think a lot of people when they think about, Oh, I'm going to write a blog post, or I'm going to make this tweet or whatever. It's like I'm going to be helping other people, but maybe a big part of it is the opposite as well.

Swyx: [00:06:52] Yeah, I mean, look it's a plus if it helps other people, but it's completely self centered (laughs). I think that's good that means that you have the motivation to stick in this thing for the long haul. I think a lot of people get started blogging or whatever, and they don't see much immediate result. And then they get discouraged. And that's because they base their self validation on others. It's not worth anything if no one else reads the blog or likes or shares it or whatever. And that's not very healthy in terms of the way that you should approach your learning. So you should learn for learning's sake. And then if other people benefit, that's a plus. It's not an act of altruism. It genuinely is the fastest way to learn. And you're growing in your knowledge but also your network. And it turns out that your network is also super important for your career. So it comes hand in hand and I don't have to separate them so I just do them together.

Jeremy: [00:07:45] I think one of the things about this concept of learning in public, a lot of people are not really sure where to start. They start with a blog or they start with a Twitter account and I think what a lot of people run into myself included is, you make a post and you don't have a lot of traction in terms of people viewing it. So you don't know if it's helpful to people and you're not really sure if you're writing the right thing. And so I wonder in your opinion, how should you approach that? How do you decide what to write and how do you get it in front of people so that they can help you out and help you learn and go from there?

Swyx: [00:08:28] Oh my God. I have so many responses to that. So I'm going to rattle off a few quick responses. First of all, it's not always about writing. You can also do speaking. You can do cheat sheets. Organizing instead of writing a blog post. I don't want people to equate learning in public to writing a blog. That's not the only category. In fact, I have five categories. I have a talk on learning in public and I had a bunch of them. It's not just blog more, although blogging is the minimal viable thing and it scales extremely well. So I do recommend that. The other thing is-- Oh God, so many responses.

Okay, let's just talk about the immediate first thing that you should do. I also really want to stress that it's something that you do for yourself, right? Whatever you're interested in then you should write about even if no one else reads it, it's fine. What we're really talking about here is an optimization step on top of just the formal act of writing down what you learned and organizing your thoughts in what you already know.

So the optimization step is how do you get attention when you have no following, right? I call this the cold start problem. It's a little bit of the chicken and egg. Everybody wants feedback. Even I want feedback, right? And that helps me load the trigger for the next action which is the next talk, the next blog post, and the next podcast interview. And that's hugely motivating. But when you're just getting started, you don't have that yet. So you need to find yourself in a situation where people have no choice but to respond to you right? And those situations exist. The way that I phrase this is, "pick up what they put down." So whoever it is you look up to, they are experts in their field. They're also extremely busy but they also have things that they want feedback on. They also have things that they don't have time to do. So if you follow them closely and you want to help just pick up on what they put down. It literally is: Hey, they have a new project out. Go try it out. Try out the demo there's probably something wrong there. Go fix the demo. If they have a new book out, go read the book, give feedback, whatever. Then you slowly work yourself into becoming a trusted collaborator because I guarantee you, no matter how popular that person is that you follow, no one picks up on all their stuff right? And I think we all have our own stuff to do. But if you have that time on your hands and you want guaranteed feedback, that's the way you do it. Because they need to be responsive to their early adopters. And guess what? That's you right? It's unfair. But it's a hack. I literally call it a hack. They have to respond to you because that's just the contract of: "Hey, I put out something. Someone gives me feedback, I have to respond to them." And it really works for any sort of project. It could be an open source library. It could be a demo product or book. It really depends. Even if it's a talk. I just did this new talk, do a summary right? Do it like a bullet point. This is what I learned. And then they'll immediately reshare it because you added value for them.

The one thing that you have that they don't like absent of any other knowledge, but one thing that you have that they don't is you have the beginner's mind. They're the expert. They've been in this for so long, and they lost the ability to relate to the beginners. But you as a recent beginner have the ability to communicate across that knowledge gap because you're bringing along people with them. The more in their heads you can get, the better. But that's a really good hack because they already have followings and they're likely to start to see you as a collaborator, especially if you prove to be a good collaborator. And that will kickstart your following in a huge way. I didn't really think about this when I was starting out, but if I was starting from scratch, that's exactly what I will go for. And it's pretty logical to see a straight path to like, okay, I will draft off of this other person.

Jeremy: [00:12:01] I think the summary is a pretty good example because there's so many really great conference talks but if you look at the YouTube view counts for conference talks they're usually relatively low compared to a lot of other content, right?

But there's so much knowledge in these videos and if you can extract all of the high level facts or the big takeaways and just summarize that for people that helps so many other people, right? They can just look at the summary and figure out like, Oh, do I want to watch the video? Do I need to watch the video? That makes a lot of sense to me.

Swyx: [00:12:35] So Wikipedia calls this the 90-9-1 rule. It's like a 90 10 law. A lot of internet consumption is completely passive. 90% of people just view or read and never say a word. 9% will comment. And then one percent would actually create, so you automatically vault into the top 10% just by commenting on something.

And if you create something based on their work then they just have to respond to you. There's just no choice. You can guarantee yourself not only some response but you also get readership from people that you care about, which is actually the real thing.

Like, I don't really participate in this gaming of follower counts or anything. But I care about connecting with people who I can learn from who are my mentors, and who I might work with in future. That's really the main reason that I participate online and I think that's healthy because ultimately. Naval Ravikant who's one of these VC types says it's better to be rich and unknown than it is to be famous and poor. Or something like that.

You should only have a network to the extent that it helps to get shit done then. And, and once you start taking on more than that and starting to base your self worth and your income and your livelihood on being an influencer or a celebrity then you start being a product and you start being controlled by your audience. Anyway. That's, that's way far out from where we started, which we were just talking about getting started. I'm just saying play for the right reasons. Because this is a hugely rewarding thing cause people are out there wanting to look for and connect with good collaborators.

But if you start getting gamified, then you start to go down a really dark path. The point being the best way to get started is through that. If you care about getting engagement.

One of the people that I helped to mentor-- their first blog posts was about explaining man pages. Like the Linux bash bash command. And I'm like, sure. But I don't get up in the morning and go "I really wish I could read a blog post about man pages." It's not something that I really want. It's good to write about things that you're super interested in. It's fine. Just don't expect that to be the most popular thing or to get immediate feedback on that. But if it's something that's new and something is being put up by someone influential in the community and you want to collaborate and jump in, that's a pretty much sure bet.

Jeremy: [00:14:54] When you talk about jumping in and providing feedback or summaries, things like that. What's the best way to get that out there? Are you making a blog post and emailing the person? Are you @ing them on Twitter? What does that typically look like for you?

Swyx: [00:15:15] Typically it's going to be one of the social media platforms. You want other people to see it as well. So email doesn't really work for that. It's going to be a Reddit comment. It's going to be a hacker news comment. It's going to be Twitter reply or something.

I even leave good comments on YouTube just cause I want to encourage content creators that I like to keep to keep doing good stuff. So, I dunno. It's wherever that person hangs out the most. And for a lot of developers it is Twitter. But it is wherever you want to be.

If you want to host it on your own page, that's fine. Just send a link to it and people can reshare it and then you can start a newsletter of: here's the five coolest things that I did. And eventually, people will start noticing that you're doing that curation work and you're providing good summaries.

That's a really good way to bootstrap an audience. I think the point is though, that's a lot of like other centered learning. You know what I mean? You're reacting to what other people do and think. That's a good way to start. But ultimately you want to be more sort of inward, like self-directed, like what do you need? What do you focus on? And direct things that way. There's such a huge wealth of information out there, right? How do you survive among the deluge of-- you're in hacker news a lot, right? There's a new 20 posts every day. And you can't follow up on everything. So it's more about understanding what you want out of developer communities.

At the same time there's one global developer community, but then there's also a billion small little ones. Which one of those that you really want to plug into? Targeting in on the ones that are most helpful to you at that point in time.

So I think the third learning in public thesis is that whatever it is that you were interested in and want to learn-- If you put out content based on that they will find you. Cause you're going from passive and then slightly active commenter and remixer of content to someone who creates stuff.

And so you will be imperfect. You will put out stuff that you're not proud of. But, people will correct you because that's how the internet works. If there's someone wrong on the internet, they'll come and correct you. And once you've gotten things wrong in public, you'll never forget it. You just learn really quickly based on that. That's the whole thesis right there.

Jeremy: [00:17:29] Yeah. And if I understand correctly, it sounds like maybe when you first start out, I think you were calling it, picking up what others put down, right?

Swyx: [00:17:40] I really want a shorter word for that. I want a shorter word for that, but it's six words. So I have this thesis that every slogan should come down to two words. But I can't reduce that any further.

Jeremy: [00:17:52] So does learn in public count?

Swyx: [00:17:55] Yeah, because in there's a conjunction.

Jeremy: [00:17:57] Got it.

Swyx: [00:17:59] So learn, like always learn, and then public just reminds you that there's a choice. By default, we're trained to learn in private. and I'm not advocating for living life a hundred percent public. But it's possible to go from zero to 5% and and see a lot of benefits. I'm an outspoken advocate with that because it's benefited my own career so much.

Jeremy: [00:18:18] You start with remixing or summarizing or trying to provide feedback on things that other people make. And then maybe the next thing that you should do is figure out what you're interested in and just write about those things or, make videos about those things however you want to do it.

Put out takeaways of what you learned and bring that to communities where people who work on that type of project are, whether that's Reddit, Twitter, hacker news and so on. And that's how you start building up this community for yourself where there's people who are working on the same problems you are, who can provide feedback and that will help you learn whatever you're trying to learn.

Swyx: [00:19:05] Yeah, the first example that I really started doing this with was back in 2018 when Dan Abramov, who's like one of the most vocal members of the React core team, presented essentially the future of react at a conference. JSConf Iceland in March.

So that day it live streamed. And then everyone was talking about it. This was like game-changing for the react world. And I wanted to be better at react. So what I did was I stayed up that whole night, transcribed his talk, walked through the entire demo that he did with all the source code and commented every part of the source code and then posted it the next day.

Obviously he read through it, right? It was about his talk. and so did everyone else that follows him right? Cause I was the first one out with a full analysis. And I was a scrub back then. I didn't know anything. I got some things wrong and I was corrected. If people want to look that up, it's right there. It's just Google for my react suspense walkthrough.

I think that that's what you're doing now, right? You saw that I was working on a book. Then you were like, Hey let's have a chat on this podcast. And of course I have to respond and now I'm here and I'm not doing it out of a sense of obligation. I was just like, Hey, that's really nice that someone noticed and is willing to have me on his podcast. I will do whatever I can to provide a good interview and share whatever I can help with, you know?

And so I think it's just a mutual exchange of value. Even though you may look up to that person and you're like, what do I have to offer that guy? And, you do, you have a lot. Sometimes it's just your energy and your enthusiasm and then the platform that you're building and, everyone can do that, you know? It's awesome.

Jeremy: [00:20:47] Yeah. One of the things you talk about is deciding what to bet on in terms of technologies, as a part of your career, as a part of the things that you want to work on. What's your strategy for betting on technologies?

Swyx: [00:21:08] Yeah, so there's a whole chapter on this. First. My own strategy is, I guess it changed over time, but, I do like to be a little bit earlier on things than others. But it really depends what your risk preference is right? The earlier you are, the riskier the project is because it's going to be rougher, right? It's going to be less well tested. It just might flat not work out, and you might have invested a bunch of time and money on it.

First of all I think people overestimate downsides. You can learn a lot from a failure and still reapply it on the next thing. But I definitely prefer to be earlier. And there are a lot of other people. So Charity Majors who is the CTO of honeycomb. I actually interviewed her for a thing on my blog. She's fond of saying betting early on a technology that's emerging and clearly doing well, made her that person.

She was the Mongo DB person. For me, I was the React and TypeScript person for two years. And that really establishes your domain. Like even though that's not all of what you are, but being about a certain technology that's earlier on, and then people flock to you because you're kinda that community discussion point. That's very beneficial for your career. If you're early in your career and you're not really sure what to bet your career on something that's emerging that you feel has got a lot of potential. I think that's really something that is worth betting on in terms of your own projects.

I like to use what thoughtbot does. I don't know what they call it. I haven't been able to find a good source. I call it a strategy, like an innovation credit. Basically saying that you should have this tech stack that you're familiar with, right? But then in every project you're allowed to try new things on one part of the tech stack, and then everything else stays the same. So it contains the risk on the projects because, for thoughtbot, they're an agency, so they have to deliver by a deadline.

If they pick something that's too volatile and it just blows up their project, then they don't meet their, their client deadline right? So that's, that's, that's unacceptable. The core idea is that you should have one stack that you're very familiar with. That you can get most things done and then keep innovating because you're definitely not at the best possible point in your tech adoption curve. Things are changing so quickly. That's the managing risk section where you give yourself an innovation credit and you only pick one or two technologies to use. Then the other thing that I covered in that chapter cause I've already written this chapteris a little bit about like, know, what's missing.

So for me problems last longer than solutions. The core problem of writing apps on the web lasted before React. It will last after React. Our understanding of the problem that will last is more important than the actual solution to solve their problem.

So I think when you pick technologies-- if you have that mental list built of the problems that really need solving then you can really start spotting when a new technology comes along that solves the thing that you really need better than what we have right now, then go for it.

Otherwise it's just an endless parade of names and logos, right? And you can't tell one from the other. But if you have an evaluation criteria that involves something that you really experience and use then that's really helpful. You're not just looking through hacker news for hacker news sake, you're actually using it to skim and see if something's come up that really solves a problem that you have.

So the one way I do it, because it's hard to know what problems you have when you only know one system. So you often need to learn a competitor, a competing framework. Not learning like full immersion, just dabble. If you're in Rails, you should look at Django. If you're in Django, you should look at Laravel, something like that. See how the other half lives. I call this exposure therapy because you'll probably find that a lot of things that are the same, you probably find that some things are worse. You're like, why do you do that? It's so easy in my thing, but you'll also find some things that are way easier in other platforms than yours. And you're like, why? Why don't we have that? And that's probably a good question. Just cause no one's done it yet. That's an opportunity for you. You can go write that thing or you might say, "Oh, this is so core that I might actually switch stacks just to have that for this particular solution, for this particular problem when it comes up." That's how you start to get into right tool for the job by having that exposure. So other languages, other frameworks. That's really powerful especially as you get more senior. To know that the thing that you started with is probably not the end all solution. And there's probably better out there and you just have to be exposed and it's pretty easy to get exposure. I listened to SE Radio and SE Daily, and I watched conference talks and I I don't have to go through the full tutorial to get to understand the ideas behind what they're teaching. I skim a lot of things, but then go deep on some. That's pretty important. Have you heard of Redwood JS?

Jeremy: [00:26:04] I have. Yeah, yeah.

Swyx: [00:26:06] There's this guy on Twitter who was like, yeah, I looked at Redwood. It's not as full featured as rails. I don't think it's going to work out. And I'm like, dude, Redwood just launched this year and Rails is 16 years old. Like, it's going to be worse. I'm sure Rails look like shit compared to whatever came before it at the point of Rail's inception.

It's very common in technology usually a lot of things are worse when a new thing comes out. A lot of things are worse than their predecessors. They're worse in every way but one, and that one, depending on how critical it solves a real need. That one is the one that actually works out. And then the rest of the ecosystem comes in and fills out the rest. So I think that's super important.

Jeremy: [00:26:47] For people who aren't familiar with Redwood, could you give a really brief explanation of what it is?

Swyx: [00:26:54] Yeah. It's Tom Preston Warner's project. He's co founder of GitHub, so he's super well off and he still wants to code. It's his attempt at building the Rails for JavaScript that everyone wants, but it doesn't exist. There are other attempts at it.

Meteor was the most recent one that didn't really work out. It's his attempt and he's building on top of a whole new stack of serverless technologies and other technologies.

To me, there's too many innovation credits in that stack. Too many things that are immature. But he's taking a longterm view because he's a billionaire so he can do whatever he wants. But, I think it's an interesting idea.

I think it has innovations for react. I had a blog post about how Redwood is actually the first framework that comes up with single file components for React. But I do think that a lot of technologies inside of it are still too immature. It uses Netlify, and I used to work at Netlify. I even think Netlify is still not mature enough, for the ambition of what Redwood, becomes. But I don't diss it. I don't dismiss it right away because I know this is what year one looks like in a project. It's shaky.

Jeremy: [00:28:02] I mean, if you think about rails, I think what excited people about rails initially was that demo DHH gave the creator of rails. Create a blog in 15 minutes.

Like you were saying, if you compared it to I think there probably would have been spring I think was the web framework on the Java side, and it probably was a lot more mature. But I think what excited people about Rails was, DHH showing you hey, you can build this blog and it has so little code compared to what came before. You can get up and running really quickly. And so I think when there's new technologies for me I'm looking for what is the big benefit going to be more so than here's this thing that we had in another language and now it's in this language. That's a little bit less interesting, but I was curious what your thoughts were on that.

Swyx: [00:29:00] Yeah, I mean, like I said, it solves a real problem that people had, which was the verbosity of spring. I've never messed with spring, but, compared to that 15 minute demo, everything looks like crap. It was really a good demo. And I'll be honest, I don't think Redwood meets that bar yet for the 15 minute demo.

I think it's true that it resonated with a lot of people just because it demonstrated that something was possible that people didn't really know was possible with more opinions and the flexibility of Ruby and all that. He definitely got it right.

I think, I think I also want to talk about the people factor. When you bet on technologies technologies are driven by people. Yes, Redwood isn't there in year one but because of the caliber of the team that's working on it, people are more confident betting on it because they're like, Oh, I've seen this guy built github and github is a pretty big deal, you know?

People behind the projects are the projects. You know what I mean? The code almost doesn't matter. Are these people solid maintainers of things, do they respond to ideas do they push out features in a reasonable fashion?

I think a lot of people treat technologies as faceless things that are just logos and github projects. But really there are people behind them and they're working on, these things and they have motivations and they have dreams. They have other things that they want to work on and evaluating technologies involve all of that.

What's the context of this project? How did it spring up? What problem was it created to solve? How does it plug in with the rest of the ecosystem because of the people that are working with the project?

That's how I think about the people factor. And as part of the people factor there's also you. You are one of the potential people. And I think a lot of people treat technology as a hands off thing. Like, Oh, it's not ready now. I'll just give it a couple of years and come back and look at it.

They treat technology statically. It's like a living organism that will just get better. Maybe, hopefully without your involvement but you can be a big part of that improvement and tying your career to an early part of that development actually is hugely important for some people's early careers.

So I have this list. Jesse Frazelle with Docker, Charity Majors Mongo DB, Ryan Florence with React, Kelsey Hightower of Kubernetes. All these people did not start those projects, but they got involved super early and made it what it is today. They could have just as easily made that call and just say like, okay, it's not ready now I'm just going to go away and then wait a few years. But then they wouldn't have a name in the industry. So in terms of betting on technologies with your career, I think there's that active you could get involved component, which I think a lot of people don't see themselves as qualified to do or don't even think about it cause they're, they're just like, Oh, someone's going to do it for me. I'm just gonna lean back and read tutorials when it's out. That's a valid and it's a perfectly fine strategy. I do that a lot, but I'm just saying if you want to make a big bet get involved. Best way to predict the future is to create it, you know?

Jeremy: [00:32:00] When we talk about bets, where we're talking in terms of like which one do we think is going to succeed, and I guess what you're saying is that potentially you could be a person that helps it succeed, right?

Swyx: [00:32:12] Yeah. Look, it could fail and you could spend a whole big chunk of time on nothing. But everyone remembers the passion and quality of work that you did in that project and that transfers man. It doesn't go away just because the project failed. People have a long memory and your association with people will outlast companies and projects. The downside of betting on tech is not that low.

I have one more point on this which is values. Values are destiny in the sense of there's the code and then inside of that there's the people. And inside of the people, there's the values. And the values are what drives the ultimate destiny of the project. Because that will involve every single decision that they make in terms of code, but also in community maintenance, in terms of marketing or whatever. Brian Cantrell who was CTO at joyent and super involved in the early NodeJS community. There's this list of values and every language, framework, library, whatever. Every developer community embodies some of these values to different degrees and there's a preference stack of values, right?

Some prefer simplicity over security, like if you have to make a trade off, which one are you going to choose? Are you going to choose the less secure option, but it's simpler so you get more adoption? Are you going to choose more security at the possible risk of less adoption?

So picking values that you agree with in technologies is like the ultimate, first world problem. Like ahh so many technologies, I'm going to pick the one where I share the same values.

The original creator of node left node, the original creator of express left express, and they all went to Go because they shared those values more.

Brian Cantrill himself left JavaScript to go to Rust. People pick communities because they're going to have a much easier time making decisions together. You're picking up technology at a point in time, but then also you have to live with the technology for like, I dunno, 10 years, hopefully if you're lucky. That's a community of values that you're buying into.

As developers we don't like to talk about these soft wishy washy things. But it's real when your PR gets rejected cause it doesn't agree with you, you just fundamentally don't agree with the maintainers, and something that means you just don't have the same values and you may probably want to pick up different projects that reflects your values.

Jeremy: [00:34:40] And when you're talking about values, that's how that community runs itself? Is that what you're talking about or what do you mean specifically?

Swyx: [00:34:48] Yeah. It governs every decision and every action that the community makes. It could be how do we RFC for new features? Is it an open process? Is it fully democratic? Everyone has a vote or do only maintainers have a vote? How do we fund development? How much corporate shilling are we going to allow?Wwhat happens when one part of the maintainer team starts being a bad actor. What's the process for removal of that person? Or if the community is just split halfway how do we resolve conflicts? Stuff like that.

For new projects, it doesn't matter. But when money is at stake, well it's not money as such, it's not just money. It's like entire companies are built on this thing. It gets really, really heated. What license do we adopt? Oh my God, we started this open source thing and it was just for fun. But now Amazon's coming in and competing with like our thing. We just need to change our license. How do we do that while not screwing over our existing customers? These happen. And there's no right answer, but having a clear understanding of the community and that maintainer's core values means that you can help to predict or resolve those issues ahead of time. And as long as you agree with them, then you're probably going to have an easier time than if you disagree with them. And you just have to be dragged kicking and screaming along. I'm so sorry. Super long winded and not very relevant for most day to day decision making, but for the really core ones, you're gonna have to think about all this stuff right.

Jeremy: [00:36:17] Yeah. I mean, I think when a lot of people think about picking technologies they're thinking more-- does it do the thing that I want? And, is it popular? Are there a lot of stars on GitHub or something like that. But there's a lot more nuance.

Swyx: [00:36:34] Stars are a proxy of at first it's like, okay, the quality of the project, but then after that it's like, okay, this maintainer's done cool shit before he's a celebrity, so we're just going to star everything else that he does and it's not, it's not very indicative of anything.

Jeremy: [00:36:50] Right. Looking more at some of the more surrounding things, like you said, the values, how do they treat contributions, looking at the people who are a part of it, what did they work on before looking at the community, are there people actively using it and are they helping one another and things like that. And that helps you build this picture of whether this is something that is worth checking out or not.

Swyx: [00:37:17] Yeah. Ultimately, knowing what you want out of technology, is gonna guide you to the right decisions every time. Because, there's technology for every type of use case in people, personality and community out there. And there's no way that you're fit for all of them. So you just gotta figure out what you want.

Jeremy: [00:37:36] And how about deciding what things to jump off of? One of the things I know that you worked with previously was meteor, which it still exists, but is not as popular as it once was. What are the decision points where you decide okay, maybe I'm going to go try something else now.

Swyx: [00:37:56] Yeah. Meteor is a slightly complicated thing because I know Scott Tolinksy and some small part of the people that I know still use and love Meteor. The problem I had with it-- So it's twofold. So the most immediate problem was that, Meteor chose this very antagonistic approach to package management.

They invented their own package manager and basically everything that you use has to be within that ecosystem or else, you know? And that's very hostile to the rest of NPM and JavaScript in general. And that was very annoying. It's like, Oh, I need a Meteor version of this. Sorry. whatever. And then the other thing was that it was too opinionated. It had its own front end framework on top of having its own backend conventions. And those were unnecessary layers to debug. And it was just unnecessary magic over and above existing technologies, which I already did not know well. So the solution to that was to strip away that abstraction and just to go one level lower and learn those things well and return to Meteor if I ever needed it, but then I never needed it. So that's why I went away from it. And ultimately I think from my early career it was a right choice. Both mercenary, which was biased towards whatever the job market wants. And the job market wasn't asking for Meteor. I didn't go for it, but have a contract. I did do it like a freelance thing for a Meteor consultancy once. and yeah, it was great. Meteor does a lot of things well, if you stay within its path. I guess it's like that rails idea. But, once you want to do something that it doesn't plan for then you have a hard time bending things. At least that was my impression at the time. I've never gone back and I know it's under new ownership now. But in terms of jumping off, like when you start feeling that frustration, there's probably something else out there that fits you better or you can just jump down one level of abstraction and just roll things yourself and that's perfectly fine as well.

For example right now, I'm in a weird transition between react and svelte, right? I served as a moderator of the react Reddit community for two years. I have recently stepped down from that and I'm ramping up my efforts on the svelte community side of things.

And I straddle it cause react has a lot of company demand, but I think svelte solves problems that I deal with in a really elegant way. But react is still important for cross platform. So it's kinda this weird, like if X, then I'll use one thing. If Y I'll do the other thing.

I don't have a one hammer fits all policy anymore, but I think that the reason I jumped off-- coming back to your original question was, the reason for jumping off was realizing that there's better out there and it doesn't have to be this hard. So yeah.

Jeremy: [00:40:38] Okay. So the big decision point there is in the projects that you work on, and even if you have a technology that you know and know well, once you start feeling like you're fighting it or it's just very difficult to do what you're trying to do, that's when you start looking at other options and seeing like, okay, is there this other thing that I can jump to when I do hit these types of problems then I can use that other thing instead?

Swyx: [00:41:03] Yeah. A hundred percent

Jeremy: [00:41:05] Another thing I'd like to ask about is, you've left Netlify and you're going to join Amazon. What was the process like for you and I'm assuming you interviewed with a lot of different companies, how did you decide what was going to be the right fit for you?

Swyx: [00:41:20] Ah, it wasn't a public search. It was actually more I just put the word out in different companies that I was interested in. And then other people heard. I didn't do a wide search. And honestly, like Amazon had it from the beginning because about a year ago I wrote this idea down for how to do offline apps with GraphQL. It was a gist I kinda drew out the idea and I was like, I don't have time to work on this, but I'm just gonna put it out there as an idea. And then last November, Amazon announced it at re:invent as a feature.

Then I was like, Oh, interesting. Somebody at Amazon thinks the way I do. And I was like, this is fascinating. I never thought that I would agree with Amazon on anything, but someone thought about it enough not only to agree with me, but then also build it to Amazon standards, which, is a significant investment. Because they never, close anything. They always support things all the way back. That was the point at which I which I reached out to Amazon. and I think the process was just more to see if it was a cultural fit. I interviewed at other companies as well. And the cultural fit wasn't necessarily there as much as Amazon was. It was also like, there's definitely an attraction or validation. I'm not too shy to admit it, that working for a FANG company is a big deal on a resume. I always worked at a small startup, scrappy startup, and the way that we think about enterprise usage, enterprise users and customers is wholly different from like a big cloud enterprise. Like that's real enterprise, you know? and I was basically interested in learning more about how did the big boys do it? I don't know if that's a valid concern or not but there's always this imposter syndrome of I don't have a traditional background. I never worked at a big, FANG company so I think this was just a nice attraction. I think I'm very drawn to the idea that Amazon is now for open for front end developers as well. As a front end developer myself, I never really felt welcome on the AWS console. And now that it's investing so heavily, in terms of all these frontend services, I thought that was very interesting.

And it's out of the box, more full featured than what I was working on at Netlify. I basically thought of the job as exactly what I was doing at Netlify, but with infinity more to learn. And, in terms of like what I wanted to be learning and what I wanted to be sharing with people, I thought Amazon was a good fit. I expect Amazon to outlive me. So knowing things that are, that are long lasting. I call this Lindy compounding. So do you know what the Lindy effect is?

Jeremy: [00:44:10] No, I don't.

Swyx: [00:44:12] The Lindy effect is-- you're probably more familiar with it in terms of the phrase, like, the longer something has been around, the longer you can expect it to last. You know what I mean? Usually sometimes people put it in a bad sense like, if you've been waiting for the bus for two hours, you can expect it to

Jeremy: [00:44:31] To not come.

Swyx: [00:44:33] To not come for another two more hours. Right. And then it grows instead of declining the longer you wait. But the Lindy effect is important for things that we work on cause, in technology. A lot of things that we do have has a very short half life. like it has value now and then it declines, right. And it's fine. Everything declines, but, the longer we can make something last, then the more we can build on top of it.

And we can grow by compounding upon the work that we did before. That's a fundamentally sensible way to run things. That's why I'm very interested in things that last. And that's why I write. That's why I try to do podcasts cause people a year from now, two years from now can still come by this thing and still get value out of it. There's a lot of people who pivot into like, Oh, here's the news of the week. That lasts a week. Exactly a week. That's not even your half-life. That's your full life. And it's terrible. The idea of Lindy compounding is that you compound by working on things that last for a long while. And one way to bet on things that last for a long while it's just, you look around for things that have been around for awhile. So it's like the diametric opposite of betting on new technologies. I've done that part. Let's do the things that have been very stable and very long lived for now. I think that's a very interesting way to compound the skills that I have. Because probably your knowledge of S3 will last your entire lifetime. And that's, that's the thing. That's awesome.

Jeremy: [00:46:01] I was talking to, Daniel Vassallo on another episode, and he worked at AWS for awhile and he was saying there are certain services within Amazon that you can totally rely on because they've been around so long like the example you gave S3 right? Or DynamoDB and so once something has been around long enough people can trust it and it further puts it in stone that people can keep using it. And I wonder one of the other things that I thought was interesting as you were talking about how Amazon previously wasn't really, I don't know what the word would be, friendly to front end developers, but it's

Swyx: [00:46:45] Yeah, I'd say that. Yeah.

Jeremy: [00:46:46] Yeah. And you go to that AWS console. And I would argue like not even just for front end developers, but for full stack or backend developers. As somebody who has worked with rails we're accustomed to being able to go to Heroku and push like our code and then Heroku puts it all up and sets up the database. And the web server and all that stuff and it's all abstracted away. But yet when you go to Amazon and you look at the menu, there's a hundred services or whatever, and you're kinda like, I don't know. I don't know where to start. And then there's what's it called?

Swyx: [00:47:25] IAM

Jeremy: [00:47:26] Yeah, all the IAM policies where you have to set up the security and you have to hook up all the different services together. Is Amazon going to be able to move into the space that a Heroku or a Netlify or, a Vercel these companies that are building on top of Amazon and providing like these really nice, developer experiences. It sounds like you think Amazon's going to try and move into that space

Swyx: [00:48:01] Yeah, I think it's about two years into this move. It's apparently going well. That's what I'm told. I'll really see when I join, but, yeah. I'm a little bit casting in my lot and saying I'll be a part of that, you know? Like I said before you have to be an active participant in the thing that you're trying to promote.

I don't kid myself that Amazon will ever compete with Heroku or Netlify or Vercel on the limits of developer experience. Amazon will never win a design award. No one will ever gush about the console or anything. It doesn't have to, it just has to be good enough.

And then there's the other benefits. There's a trade off to all that start up awesomeness, which is that you don't have the majority of the rest of the platform and when you need to scale, you can't, you just have to migrate. And that's, that's unfortunate, right? That's just how startups have to have to make their way with things. I think Amazon has some potential as the only underlying layer to let people onboard, and scale as it gets a certain size. So I think that's an interesting thing to bet on. I'm personally not even betting on that. I just think it's fascinating that Amazon's even trying in the first place and I'd like to be a part of that. But then also just learn everything that I can and share with people. Because people fundamentally want to learn Amazon. I've just realized this after a while despite all of its messiness and complications. Yes, onboarding sucks and yes, the initial developer experience sucks, but you know what else also constitutes the developer experience? Whether the service sticks around forever. Whether it has really good uptime, whether it has a predictable pricing that never goes up, it only goes down. Amazon has a 20 year track record of that. So I'm like, yes you can always do a lot better on the initial experience, but then it's not just the initial experience as well it's also the subsequent experience of I need this thing and, oops, the platform that I chose doesn't have it. And that's fine. That's a trade off that everyone has to make for themselves. But it's nice to have a platform that just has everything by default. And the thing that you suck on is the initial experience, which is fixable right? so that's how I view it. I may regret these words later.

Jeremy: [00:50:35] It'll be interesting from your perspective once you get into it, right? And then you actually start to see, okay, what is the process of getting a feature built at Amazon? And getting to figure out, okay, are there ways that we can improve that onboarding or improve that developer experience? Or are there just a bunch of things that are happening that you're just not aware of yet and those things are what makes it so difficult to have that great experience from the start.

Swyx: [00:51:09] Yeah, I mean on the company process side of things I'll tell you everyone in the Valley, everyone in startups idealized the way that Amazon works, right? Like, have you heard of the two pizza teams?

Jeremy: [00:51:22] I have. Yeah.

Swyx: [00:51:23] Right? Have you heard of the, the six pager, the Amazon PR six pager thing?

Jeremy: [00:51:27] so is that where like if you have a new feature, then you, you write six pages

Swyx: [00:51:33] You write the press release before you actually code.

Jeremy: [00:51:37] Got it. Yeah.

Swyx: [00:51:37] Right? So these are just accepted. These are best practices, which, I'll be honest, at Netlify, we didn't even do that. But everyone understands that these are just good ways of working.

I'm like fascinated, I just want to see it in practice. I want to go to the source and just see because as badly as Amazon does a lot of things, they get a few things right. And this is what, Steve Yegge, I don't know if you've heard of it probably not, but, Steve Yegge has this, Google platforms rant.

I'll send that to you because everyone should read it. It's amazing. But basically he's like, yeah, Google does everything right. Amazon does everything wrong except for one thing. And then he's lists a bunch of things. That's a little bit out of date now, but, I think fundamentally true that Amazon is very strictly run according to a few small set of principles that, I personally strongly identify with.

So the interview was completely not a challenge for me because I love this stuff. Which people make fun of cause one of the principles is just ridiculous. One of them was like be, right a lot. Like, great.

Jeremy: [00:52:48] Okay?

Swyx: [00:52:49] Yeah. Yeah. It's like-- Do I choose to be wrong? No. But anyway, I think they live by the principles and one of them is the two pizza team thing. This is like the six pager thing. Even as an outsider, I've already been inundated by like, yes, this is a real thing. And yes, we live by that. And customer obsession is interesting. Because it doesn't show up in the design for sure, but it shows up in like other things that matter, like uptime and pricing and, availability zones and what have you. It's just like a new thing for me and I'm just joining in everything's new and I've gone from working like-- the biggest company I worked at, it was 200 people and now it's like 800,000, you know? I definitely look at this as like, I don't even know fully what I'm getting myself into. And that's exciting to me. Cause I definitely think of that as a learning experience.

Jeremy: [00:53:46] Yeah, that's a good point in that when someone's looking into taking another job or taking another position, your background is, you've worked at a lot of startups that have been relatively small teams. And so when somebody is thinking about making a move, like they might consider Oh, maybe I do want to try like a giant enterprise, or I want to try a FANG. Just so that I get to see how people there work differently than what I'm accustomed to. Because you may go in and you may hate it, right? But you won't really know until you jump in and see how things work. So that's an interesting sort of, additional factor to think about when you're picking a job.

Swyx: [00:54:27] Yep, yep. For sure. I'm also viewing this as, me generalizing a bit. So, at this chapter. I guess one of the questions in people's tech careers is: how much of a specialist versus a generalist do I want to be? And for me, I think the advice I have landed on is when in doubt specialize. You don't really know how to get past that and get past the trough of like, Oh, I don't know anything to like the, mastery level where you start making the tutorials that other people depend on. I understand the front end fields enough. Obviously I don't know everything, but it's enough that I can probably figure out how to do whatever I need to do at, any given stage. I want to generalize a bit beyond just being a front end guy to front end and serverless and AWS stuff and possibly anything beyond that.

Maybe one way to phrase this is that you have a lot of lateral transfer opportunities within a large company compared to a small company where you're just asked to perform one function. I think that's an interesting way to think about career trajectory as well.

Cause a lot of people think about like, should I do startup versus big co? Definitely the household recognition helps, brand name recognition helps. Once you've been through such a rigorous interview, like I, I don't know if you've interviewed at Google, but like Google does do very rigorous interviews.

So like, once you are ex-google, no one really questions your ability to code. So that's great. And then you can do other more speculative stuff with your career. Whereas if you're always from a small, small startup, you're always going to be interviewed with a whiteboard question for the rest of your life. Which is fine, but it's annoying.

Jeremy: [00:56:17] For somebody who is coming out of university or coming out of a boot camp-- given your experience, do you think it's better for them to start with a startup or do you think it's better for them to shoot for an enterprise or a FAANG?

Swyx: [00:56:34] Ooh.. It really-- I don't know. That's an interesting question. I'll talk about my personal preference. I probably would have preferred a big co to start with because the validation especially from a bootcamp you're not qualified goes away once you join a big co, whereas for a startup, the question always sticks around.

I did not have that opportunity. I interviewed with Google 15 times, but actually, yeah, 15 times. There was two on-sites and they just packed a lot in there. Actually, no, not 15 times, nine times. I'm sorry. I don't know where the 15 came from.

That's almost like a superficial thing because at the end of the day it just matters where you grow the most. And it really depends on your personality and how much you fit with the team. A good mentor at a small company, beats a crappy mentor at a huge company, you know what I mean?

So, it's not always about career image, it's also about how much can you grow at that specific position and how much you're excited and fueled by it. For sure it's not gonna be your last job, you know? So you do have to think about that day one that you land on that first job. You're also thinking about do I enjoy this? What else exists out there? How can I keep sharpening my skills and broadening my interests? To really find the thing that I wanted, cause it's probably not going to be the first date that you find someone that you're gonna marry for the rest of your life. You know? It's kinda weird cause the process of finding a match and we just have a lot less tries at it than in real life dating. We're expected to find our first job and then just fall into it.

But, really there's a lot more out there and we might not find the right fit for awhile. I do think a lot of people in their mid careers there's like, some sort of mid career crisis that some developers go through, because they realized they're not that passionate about the thing that they've been typecast into from junior to all the way to senior. Like keeping a wide focus wide angle of what else is out there is important, especially as you start out. I don't care that much where people start. I just care that it's a good environment for them to grow. And that they start growing their network as well. Cause I think when you're early on it really is about your coding ability, but as you go almost senior, it's less and less about your coding ability and more about the communities that you're involved in, the architectural decisions that you've been through and understood. And the people that you know and can hire to to work with you is also important.

Jeremy: [00:59:08] Yeah. And so when you're at your positions, like you joined a new job, what are the ways that you can optimize your time there? Like whether that's trying to make sure that you can learn the most as possible from your coworkers or try to get mentorship or what are the strategies that you would ask people to consider?

Swyx: [00:59:31] All right. So I split this as like junior dev versus senior dev. I haven't written the senior dev part, but I have some ideas. The junior dev part, this is your time to not know anything. you should ask all the air quotes, stupid questions as possible because they're there. That's the responsibility of your managers to train you. And some people have screwed up. Some people have destroyed their production database on day one of the job, and guess what, it's not your fault. It's the fault of the managers for not building a resilient system, to recover from that or to prevent you from being able to do that in the first place.

The other strategy I think I like to encourage people is to pair program. there's just so much that you can pick up just from osmosis of like having a mind merge while you code and then someone can watch over you and then just, Oh, or you watch over them coding, right? And then you can see all the little tips and tricks that they do and that levels you up very quickly. In fact, some companies like pivotal actually always pair program. And that's very high stress cause it's a lot of talking.

Jeremy: [01:00:27] That sounds exhausting.

Swyx: [01:00:29] Also like, it's just like really you just don't have a distractions cause someone's looking over your shoulder. But it was great. I pair programmed a few times at Netlify and it was awesome.

And then once you, once you start being able to get other people in your head, that's one way of like emulating them. Like you start having a senior developer in your head, right? And you go like, what would they do? What would X do? What will I do? When you come to a similar situation.

And that's valuable, at least for the code review, where when you send in code, you can step back from yourself and have an out of body experience, and go like, okay, now I am the person reviewing my code. What are they likely to say?

And you can review your own code proactively and show them that you're learning. Show them that you're picking up, not just the ability to code, but the, the ability to integrate with and mind meld with the rest of your team. and that's, that's a really awesome way of thinking about that. In terms of like finding a groove.

Then there's also trying to add value and essentially I try to phrase it as you should be a problem sink not a problem generator. This is hard to do at the start, but basically like, people should be able to give you problems and you solve them.

There should be no new problems generated from your work otherwise you're just adding problems. The buck stops with you in that sense. And so the more capable you are, the more people will realize that when they have stuff to do, they can assign it to you and it will be done. That's probably the most immediate value. You can be proactive about that. And so you don't always have to sit there and just wait for things to come your way. You can actually ask to be assigned to projects that you want to work on.

Often it's doing the things that nobody else wants to do that ends up making you indispensable because A) it has to be done anyway, and B) nobody else wants to do them. So if you're the one doing them, then you now own it and you're indispensable now because you're the person that owns that. And guess what? You can make anything interesting, the most mundane things. Like, let's talk about tests like, the best thing, the best way to start a new job is to write tests because you cannot break the code base. In fact, you're doing the opposite of breaking the code base. You're making it more resilient. You're not just writing tests, you're also removing and changing outdated tests. Your coworkers will be grateful. There's never enough tests whenever you have to ship versus writing more tests, you ship, right? And then you go to the next thing. So as much as we all like to say that we believe in tests we don't always test everything. And as someone new, you can always contribute more tests, you can learn the code base and you can learn the product. So you probably as a user, you have used a product that you're working on, but you only see things from your perspective and you don't see all the hundreds of edge cases that you're also handling for, let's say, enterprise clients.

Writing tests is a non intrusive, noninvasive way of like contributing value to the code base. I think that's a highly profitable thing. I have some links from people who use this strategy at Netflix and Ionic and Paytm, and I'm sure there's a lot of other companies where people have used this and they just didn't see my tweet at the time.

But I basically said write tests when you're trying to join a code base. Once you find your group you're basically starting to go from reactive like things come into you and you work on them to proactive, you start to ask to be assigned on strategically important projects where your profile will rise according to the project they work on.

That's one way of like ensuring that you have impact. Because if you look at all the engineering calendars out there, so, I actually went through and collected all the public engineering calendars that people put out. Also blog posts. but basically if you look at all of them, they all evaluate engineers based on business impact, which is weird because you don't really have any control of that. You just write code. but you have control over the projects that you work on and it's up to you to position yourself. It's a little bit of politics. How much do you understand what the company's core business is and how much do you support that effort?

And obviously you contribute more value if you work on the company's most essential projects so you want to do that. Then there's all the other like meta learning stuff around the actual work. So there's reading technical books, reading framework source code, learning more languages, following people over projects.

So the projects that you use. Probably just projects to you, but then there's people who work behind them start following them. You should also be working on useful side projects. So basically I have like this whole long list of things which are probably super unrealistic for any real person to do, but these are just ideas that people can pick off like: Hey, I feel like I should be doing more. Here's a list.

I do strongly encourage people to do talks because doing talks is the ultimate skin in the game of learning because your face is there when you do the talk. When I say do talks obviously there are no conferences right now, but you can do meetups. You can do brown bag lunches at work or to your family or to your dog, to your YouTube channel. I don't care. The process of going through and teaching and speaking really solidifies it in your brain. It's that whole learning in public process but you can do it at work and people really appreciate you for that.

In fact, Matt Gerstman one of my friends in New York he started the JavaScript Guild at Dropbox. He got it to a point where he organized an internal conference for a thousand of his colleagues and they all flew in and he did talks and he definitely raised his profile at Dropbox just because of doing that.

And it wasn't his job. He just did it. But like, he's now viewed as the internal JavaScript expert, which is a huge position to be in for a company like Dropbox. That's, that's awesome. There's other things like guest writing for industry sites, blogging, answering questions.

Ooh. So answering questions you don't know what you don't know. And one way to get past that is to answer other people's questions because then you get exposure to the things that other people who are not you run into, and then you're like, Oh, I did not know that. You know what I mean? There's no way I could have figured that out if I didn't answer other people's questions. So, on the react Reddit we have 500 Q&A's every month of beginner questions and you want to get good at react just go in and answer every question (laughs) , right?

You scale by just the number of people who are throwing stuff at you and so if work isn't challenging enough there's unlimited questions on stack overflow and twitter and reddit and github issues and you should just dive in and help out.

Jeremy: [01:06:42] For sure. Yeah. That was an interesting twist in terms of the JavaScript Guild or the internal conference at Dropbox where you've been talking about this idea of learning in public, but learning in public could also include the company that you work for, right?

Swyx: [01:07:00] Learn at work. I mean, some companies are tiny, so there's not much public to do, but when you're the size of Dropbox, I think they had like 10,000 people then. Yeah. It's the same thing (laughs).

Jeremy: [01:07:10] Yeah that's cool. One of the things about your career and your learning is that you have picked up so many different technologies and learned so many different things. When you were learning, what were the resources that were the most helpful to you?

Swyx: [01:07:28] Wow. That's broad (laughs).

Jeremy: [01:07:31] Maybe it's too broad (laughs).

Swyx: [01:07:32] More recently I think I just really got into a groove of reading technical books from cover to cover. I think people don't do this enough. Senior developers spend years of their life working on a book and then they sell it for peanuts.

You can buy their expertise and just read it. That's amazing. I learned typescript that way. I learned CSS that way. I learned DynamoDB that way now, cause I just did Alex DeBrie's DynamoDB book. Yeah, technical books are super underated because no one has the patience to sit through a long form book.

But as an intermediate developer, that's what you gotta do because, tutorials are targeted at beginners, right? Beginners, want to go from zero to hello world as fast as possible. And then experts don't need a tutorial. They just need to know what changed. Like, give me the changelog and then, and I can figure it out. But the intermediate people they know some things, they don't know everything. So what's the best way to fill in the gaps, which is read the docs or read the book. I don't care.

Yes, you will find a lot of things that you already know you can breeze past those, but you'll probably find a lot of holes that you weren't really sure about. You think I'll get to this someday. You never go back to it. Read technical books or read the entire docs or read the entire source code if you're ambitious. I don't recommend that for everything, but books you can definitely handle, right? Because books are made for you to skim through, like probably take you a week, two weeks, whatever. That will be a very high leverage thing because the amount of hours that went into preparing that is so different from podcasts or any of the popcorn stuff that we do on a day to day basis, right. Again books are Lindy compounding. They took a while to create and they'll probably last longer than hack a day blog posts that we get, does that make sense?

Jeremy: [01:09:19] Yeah. Yeah. No, that's actually a really good example because, wwhen I look online for how to do something, like you said, you'll find all sorts of blog posts a lot of the time they usually stay at the very beginner level and sometimes you're not even sure if they're up to date or what they're teaching is still relevant.

Swyx: [01:09:40] Yeah. Cause Google wants you to believe that all knowledge is one Google search away. but you get to a blog post and you're like, this doesn't exactly match up cause the version's a little bit out of date. What do I do now? You're totally lost because you're not learning from first principles.

You're just copying, pasting. So what a book or some form of long focus study gets you is the conceptual understanding to figure out anything that you need in terms of coming from first principles instead of just following instructions. And that's when you become more of a software engineer rather than a software user.

Like I had this post "the day I became a software engineer." My job title was software engineer. I was not a software engineer because I was still following other people's instructions. I didn't really have a conceptual connection with the thing that I was doing. But once I started to look at source code, when I started to understand conceptually what I was doing and figuring it out based on first principles, then you're really doing software engineering, right? You're not just following instructions, you're not using other people's software the way they tell you to use it. You're really interacting with it on a conceptual level.

Jeremy: [01:10:40] Yeah, books are a really good example because, when I'm looking for things online, a lot of times I wish there were more, intermediate resources or maybe even advanced resources because you'll have a thousand posts on how to make a blog or something like that but maybe not a post on how to do this complicated thing in graphQL. I agree with you I think books are definitely underrated. A lot of people don't even think to go see if there is a book they can go read. I'm wondering from your perspective, are there also other things that you think people could be creating? Whether that's, more technical blog posts or courses. Like what do you think that people should be creating or should exist in the world that would help people that are at that intermediate level or that advanced level?

Swyx: [01:11:34] Workshops are a thing. One resource that definitely helped me was Frontend Masters they basically do books in video form, They just have the creator of the technology teach a four hour, eight hour workshop on their technology, and that covers it.

Obviously it doesn't have as much room for nuance as a book does, but, different formats will appeal to different people. I definitely respect that. Some people just can't sit still for a whole book. So you can definitely create different forms of content for that.

It's just that books are well understood. They've existed for, I dunno, 4,000 years, and we know how to deal with books. The other forms of media are a lot newer.

I have this theme of like open source knowledge as well. That's a principle that, I'm expanding as well. So, for example, my React in TypeScript cheat sheet that I started, it's not a book. It's a repo that anyone can contribute and basically just gets better over time. A book it's something that one person or two people work on for an extended period of time. And then there's a definite end date and then they ship it. And then maybe it's out for awhile. And then, it gets updated at some point, but like it's not as live it's not as current as something that's just always on and like Wikipedia is just like constantly updated, right?

Wikipedia is like the ultimate version of what open source knowledge is basically like we used to have encyclopedias that was curated by an expert team and those things just got destroyed at a fraction of their costs by Wikipedia, right? Because everyone could contribute.

And so that's the idea of open source knowledge. We have open source code and we understand that by open sourcing code, more people can look at it. More people can contribute and write issues and it just is better after many eyeballs are on it. But why don't we open source knowledge?

And books are closed source knowledge right? I'm the author of this book. I will make all the decisions. But like, maybe there should be something more collaborative, that everyone can mark up and it just gets better over time and everyone can access that.

So I do like this idea of a more collaborative form of books. It's still a book basically, I just call it open source knowledge.

Jeremy: [01:13:45] Yeah. Maybe that could be the the docs for a project, right? The docs for a framework where the docs are so good that they get you the knowledge that you would have gotten from a book, but it's in the form of a git repo that other people can contribute to.

Swyx: [01:14:05] I mean, people tend to think of docs as something that is officially maintained by the team. You can only write for so many audiences at once and you're going to make some people unhappy. There's an unlimited space for community docs, essentially for like, X for Y, like MongoDB for JavaScript people. MongoDB for Ruby people and then it's just going to really focus in on those use cases and do a good job of it.

Again, not to go back on my example too much, but it's the one I'm most familiar with, but when I was trying to learn TypeScript, The react docs did not have TypeScript docs because they supported flow. And TypeScript did not have react documentation because TypeScript was focused on being TypeScript. So it's that intersection of people like me and like the technologies that I wanted to learn.

There's an unlimited space for those. Every project has only one official documentation, but then there's this unlimited space for unofficial documentation for different audiences, and people can, do that (laughs).

Jeremy: [01:15:01] Yeah. That's an interesting point about people all bring different context, right? Like they've worked with different languages or different frameworks before. And when somebody writes a book, like they have to sort of sit down and decide okay, what is my audience going to be?

I'm going to write this book and there are going to be people where this is great for them and there's going to be people where the level is too high or the level is too low and it's impossible to satisfy everyone. I like your idea of there being different communities building their own public knowledge of this is what we as a group learned, and it may not match you exactly if you just find it on Google, but there is going to be a community that does understand that and can contribute and it can be a living document, like you said.

Swyx: [01:15:54] Yeah. In fact, I think we could all do a better job of saying at the start who this is for and like if it's very clearly not for you, then the reader can move on and we can be all happy. But like everyone tries to write for everybody and it just like, is a random mismatch of like stuff. And we as readers, we're wasting time cause we were trying to evaluate whether this is the right thing for me or not. we should always just like, this is for X. If you're not an X, these are other resources that you can go to. We'd probably be better off as a community (laughs).

Jeremy: [01:16:23] Yeah. It reminds me of looking up a tutorial for I don't know, rust, and then you get to the tutorial and they go like, okay, this is what a variable is, or this is what a for loop is.

Swyx: [01:16:41] (laughs) Like, ahhh! Come on! Exactly. The TypeScript tutorial when I started, was teaching people ES6 JavaScript, which I didn't need cause I already knew it, but it was like, trying to colocate these things at once, just trying to be beginner friendly or whatever. And I was like, I'm sorry. I'm not a beginner and this doesn't help me at all.

It just argues for a diversity of docs and more people should be writing everything. So there's just an unlimited amount of things to get people involved in contributing but also learning in public.

It's a beneficial thing for them. And for the community. I can't say enough good things cause, Okay. So first of all, the point I wanted to make was that, the other feature of opensource knowledge is that because it's evergreen, it's always updating.

It starts to have Lindy compounding effects, right? So it's not just a one off blog post. You're actually maintaining and keeping it up to date. I like that as a form of concrete form of learning in public, cause you're not creating and throwing away your work. And that's, that's really awesome.

Oh, the other thing is, having things in your life where you know that you cannot possibly overshoot is a luxury. It means that you can invest infinitely in that thing it's always better. Again, this is how much I admire Amazon's principles. So a lot of people ask Bezos about. What do you think is going to change in the next 10 years? And for him, he's like, everything's going to change. What's more interesting is what is not going to change? Those are the things that you can invest in because everything else, if you invest in them and then things change on you, then your investment is wasted. But the things that don't change are the things that you can really invest in for a lifetime, and that's kinda what he did.

So for him, the examples were like the dumbest one, which was customers are always going to want lower prices. They want lower prices and faster delivery. They're not ever going to say, Hey, I want higher prices, or I want slower delivery. And based on that he built Amazon and Amazon prime. For me, this idea of like everyone can do a little bit more in public. It's something I can not overshoot (laughs).

Jeremy: [01:18:33] Yeah, sure.

Swyx: [01:18:35] So I can just say it all day long and not get sick of it. Cause I know that the more I can get people to do it, the more it would be better for them and better for me, frankly. As a participant in the dev community, I would want to see more people doing it. So, having things you can't overshoot is really good.

Jeremy: [01:18:49] Right cause there's never going to be a point where people are going to say like, Oh, there's too many tutorials. There's too many guides.

Swyx: [01:18:56] There are people who say that, there are, I think, that can be true. But you're probably like paying too much attention to beginner level stuff because I get it, like I'm an intermediate or advanced person and I see a bunch of beginner tutorials all day long on my Reddit but it is helpful for someone out there who is a beginner. and all I have to do is ignore that and find better sources of info for myself. Just got to get better at curating your own info stream.

Jeremy: [01:19:23] Yeah. It's not that there's too many, it's that maybe the fact that there are a lot makes it harder to find the ones that you care about. And that's, like you said, more of a curation or a search problem. And I'm not, I'm not sure how, how we solve that.

Swyx: [01:19:39] Look like, don't center your entire basis of learning on tutorials all the time. That's it. If your learning strategy is someday the perfect tutorial will come along and I will become a better developer because of that. Stop just, that's not how you get better. Go read books. I'll tell you, there's not enough books, you know? So yeah.

Jeremy: [01:20:02] Yeah. yeah, that's a good point. Like you can't always hope that somebody is going to have put in the work to do that tutorial or answer that stack overflow question for you. Like you, you do need to build that, that solid base. And then, once you figure it out, then hopefully you'll write the tutorial.

I think that's a good place to start wrapping up, but are, is there anything else that you do wanted to mention or you wanted to plug?

Swyx: [01:20:27] no, I'm still working on this book. It was supposed to be a two week project and then I like started really getting into it. So I don't really have a book to plug. I just hope that people try to go from a hundred percent private to, putting something out there.

It's now more than ever, that, you start to, be able to market yourself as a as a senior developer. If you're a junior, you want to market yourself as a senior. And you want to disconnect your income and your influence from your hours. That's wealth. Basically, you're building wealth by so that everything that you leave in public out there, works without your presence being required anymore. As developers, a lot of us sell our time for coding right? But we never really think about the people who buy all our services with money and use that to do something more valuable than what we have. And they use it, for example, to write sites and apps and we should try to build for ourselves as well in whatever form.

For me, it's been content. I've been relatively successful with writing and speaking. but for others it might be an app like a side project or whatever. But we should always think about how to make most use of our developer talents. And it's almost a guarantee that you're being undervalued by your employer, because that's just fundamentally how this works. They pay you less than they get from you, which is a fair trade. Now, don't get me wrong, but like, you should always be thinking about how can you be improving on that? So hopefully people can figure that out for themselves. I'm still figuring it out.

Jeremy: [01:21:59] So it sounds like maybe a, maybe in a year or two we'll be seeing Swyx incorporated?

Swyx: [01:22:05] I mean, I'm committed to Amazon for at least four years. I think this book thing has some legs though. I've been blogging for a year ish but like people understand that I put out quality work.

When I announced I was launching this book, I didn't have a book to sell, but people understood that I was going to put out something of quality. Basically. What I'm trying to say is I sold an empty PDF for $4,000. There's something there where everyone can have some sort of side hustle where they monetize their, ability to write and to teach.

I've done some egghead tutorials and that comes in I think like 500 a month. I haven't really done that much, but you could do something as an instructor, as a professional developer, someone finds your coding ability of value and you can definitely share that more widely.

Jeremy: [01:22:55] For sure. Yeah. And then that also hopefully builds your ability to communicate and to write and that can apply to any type of position or any type of work you do in the future.

Swyx: [01:23:08] Yeah. Yeah. Yeah. The trap that I find myself in is that I don't want to give everyone the impression that they need to go down this path because this is very much like a person who writes books and is a developer relations person. And the vast majority of developers are not that, but I think their own careers and their own learning can be enhanced by doing this stuff, even if they don't have direct financial benefit from it.

Like, I call some of these blog posts that I do, friend catchers. Which is basically things that earns you friends in your sleep. Like this podcast is a friend catcher, because after I'm done recording this, you're going to put it out and people a year from now will hear about it.

They'll know who I am, they'll contact me. And that's decoupled from my time. Right? So this is a good use of time because of that and I think everyone can think about ways in which their workflow can be improved by having some decoupling from their time in their income. That's all I have to say on that.

Jeremy: [01:24:05] Yeah that makes a lot of sense. I mean, like you said, whether it's podcasts or conference talks or, or blog posts, that sort of thing. Those are the kinds of things that can keep helping people, long after you finished them and can get you in touch with new people so that, that makes a lot of sense.

Swyx: [01:24:24] Oh, I got one more for you. Sorry. I know. I don't want to take too long to close out. But, basically I had this whole section on strategy, like business strategy. So as a developer you spend a lot of time learning about the art and science of coding, like art and science of creating software.

But, you should also spend some time learning about the business of software, like how people make money off of your work. So I have the section on the basic business models like advertising agencies, marketplaces, SAAS. People should understand the economic imperatives of what these things are, not least because you want the company that you joined in and have options or RSUs to do well. But you also want to be able to put yourself on strategically important projects that will have impact, right? You want to be able to suggest features that say like, Hey, this would be really easy for me to implement. So it's like, it's not technically your job because your PM is supposed to do that, or your CEO's will do that, but you as someone who touches the code have enormous power over what the final output actually looks like, because you're like, Oh, this is low hanging fruit. I can actually put that in there. You control so much because you control the tech stack, you estimate the cost of relative projects, you can actually say, this is really easy compared to the relative impact it's going to have on the business. So I think everyone should understand business strategy to some extent. Cause it directly affects your career. You want to be in something that is strategically important to the company. You want to invest in mega trends that are going to last your entire career so you you're at least early on them.

So yeah, these are all things that we discuss. I realized this only like halfway through because I was like, Oh, I'm like in this weird spot of being in like a really good position to write about this because I'm a developer. Plus I used to invest in tech stocks from a hedge fund point of view, and I have a finance degree and all that. I should probably write this down cause no one else talks about this, right? I've looked at other career books and I was like, I was like, yeah. Preparing a portfolio, writing your resume. No one actually talks about strategy.

Jeremy: [01:26:19] Yeah. It's the next step from people when they work on a project, they want to build something that's going to be useful to the customer, but then taking it one step above that and going what is the thing that is going to be bringing my company money so that I can pitch this to my manager or my technical lead.

Swyx: [01:26:41] And I think there's a founder in all of us. We're all looking for what we want to do next, and obviously there's important strategy there. Look, I'm not the authority on any of this, right? I'm just like random dude, writing my thoughts out.

At this point in my career and I hope 10 years from now I will think I'm a total idiot and disagree with like majority of what I say. Cause then that means I will have grown. But I hope that these topics are at least brought up in people's minds and they can at least start exploring it for themselves and figuring out what they, what they decide. And I'd love to have this discussion with anyone on this.

Jeremy: [01:27:16] Very cool. Swyx, thank you so much for chatting with me today. I think there's a lot for people to unpack and a lot for people to think about in terms of learning in public and what to do in their careers. And I think people are gonna really enjoy it.

Swyx: [01:27:31] yeah, we went two hours. Holy shit (laughs). All right. Thanks, Jeremy.

Jeremy: [01:27:38] And that was my chat with Swyx. If you want to see a good example of someone who documented their learning process, I highly recommend you check out a post by a previous guest, Federico Pereiro about how he writes back ends. Many people from around the internet, reviewed what he wrote and gave him productive suggestions.

Alright, that's gonna do it for this episode. We talked about a lot, so don't forget to check out the software sessions website for transcripts. All right. See ya.