Software Sessions
Software Sessions
Jun 17, 2020
Learning in Public with Swyx
Play • 1 hr 31 min

Swyx is a senior developer advocate at AWS, an instructor at Egghead, and the author of The Coding Career Playbook.

We discuss:

  • Getting help without having a big following
  • Remixing and summarizing what others create
  • Creating Friendcatchers
  • Betting on technologies
  • His new book "The Coding Career Playbook"

Music by Crystal Cola: 12:30 AM / Orion

Related Links

Transcript

You can help edit this transcript on GitHub.

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'…

More episodes
Search
Clear search
Close search
Google apps
Main menu