Swyx is best known for being the Reactjs subreddit mod, and recently released the book, "The Coding Career Handbook".
In this part 1 with Swyx, we discuss his background and how he got started in engineering.
Simplify your cloud infrastructure with Linode’s Linux virtual machines and develop, deploy, and scale your modern applications faster and easier.
Listeners of Developer Tea can now enjoy $100 in free credit! You can find all the details at linode.com/developertea.
If you enjoyed this episode and would like me to discuss a question that you have on the show, drop it over at: developertea.com.
If you're enjoying the show and want to support the content head over to iTunes and leave a review! It helps other developers discover the show and keep us focused on what matters to you.
Transcript (Generated by OpenAI Whisper)
And today's episode we talk to another person who is dedicated to learning in public. Today's guest is Swyx. Swyx used to work in finance and then he kind of went to a boot camp, eventually found himself at Netlify and now at AWS, he is known for being the ReactJS subreddit mod for quite a while and now Swyx has recently released his book, The Coding Career Handbook. You can find this at LearnandPublic.org. If you listen to this episode and the next one you're going to get a coupon code that will get you 30% off that book, so stick around. I guarantee you Swyx has a lot of wisdom to provide for you in these episodes. Thank you so much for listening to Developer Tea. My name is Jonathan Cutrell and my goal in this show is to help driven developers like you find clarity, perspective, and purpose in their careers. Let's get straight into the interview with Swyx. Welcome to the show. Thanks for having me. Thank you for joining me. I know that we have kind of gone back and forth on Twitter just a little bit and I appreciate you committing to take the time with me and talk about a lot of things. I've got some really good questions for you. I feel like we have some very similar ideas about the world, which is a very big topic to have similar ideas about. I can't help but read the content that you write especially and think, man, I feel like he's in my brain a little bit or I feel like I could have written this same idea, maybe not as eloquently as you have, but that I could have walked down these same pathways. So I'm really excited to talk about some of those ideas with you and hopefully we'll find something that we disagree on. So it's interesting. Yeah, I would like that too. I think a monoculture is not that healthy and maybe we all are jicking from the same well. We can definitely explore some diversity of ideas. I think that monoculture is definitely a problem and it can be easy also on the flip side to try to reject culture just offhand to say, oh, everybody's going that way and it is certainly invoked to choose a countercultural path, whatever that is, whether it's in a framework or in some personal belief or something, just so you can maybe artificially increase the diversity of the pool. What do you think about that idea, the idea that we are intentionally trying to go against the grain? It's not anything new, but I'm interested in what do you think about that? There's a hipster streak in tech for sure, but I think most people are doing the right thing by being part of the majority. There's definitely people who like to dunk on things a lot and just because it's popular, they're all just automatically hated. Sometimes it's a good thing, sometimes it's not. The quote that I always use is from, I don't speak French so pardon me, but it's Francois René de Chalto-Briong and it's, you are not superior just because you see the world in an odious light. I mean that you might feel like you're better than everyone if you just see them that, if you just shit on their stuff, but actually you're the bad person. It's just, people have this sense of status. They want to show that they're smart or they make different choices in the majority, but just don't put others down, that's kind of like a baseline. Yeah. I feel like this also goes through multiple evolutions where you swing back and forth, especially as I get older. I feel like I've swung back towards that, towards the majority and the wisdom of the crowd, general mindset. But then there's also this other part of me that says, well maybe I'm just being the old guy who says, get out of here with your new stuff. So I don't think that I will personally, that I will ever find the, oh here's my one way of doing things. And I think that's, at least for me, I think that's a good thing. I think it's okay to kind of flip back and forth between those mindsets. Yeah. It's also an element of fashion. So you know how the songs that we listened to were mostly shaped by what was popular when we were in high school or college and then we listened to that essentially the rest of our lives. There's also this tendency of people to take that, what they learned when they learned to code is essentially the correct state of things. And then old stuff is obviously bad and how did anyone ever use that old programming paradigm. And then new stuff is just terrible real programmers would do exactly what they do. So it's a very generational thing. So that's a mental bias that people need to overcome because it's a very natural one. And then the other element that I always like to pull in is this law, which is like a human law, it's not a physical law, called lavers law, L-A-V-E-R-S. And it's this idea that things that are a little bit ahead of their time look a bit odd to us or offensive. But then things that are old we suddenly venerate as beautiful or you know, and it's just, we got to be mindful that we're just at a point in history and we are, we're nothing special. There will be whatever is hot now may not be hot in the future. So we should basically just stop judging everything as much. I'm curious if you think there's some degree of personality involved in how much you weight those things. The progressive side of things are the new uncomfortable things being kind of gravitating towards that versus gravitating towards the old things that like you said we see as beautiful. Is there some piece of personality in that or do you think we all kind of have, we're all just on a different point on that time scale. And so what's old to me is not necessarily old to you and what's new to me is not necessarily new to you. Yeah, I agree with that. These are exactly the reasons why I feel like we see a lot of things very similarly. You talk about these various laws and biases and one of the things that you wrote about recently that I want to talk about is actually your naked emperors and tech post and this is such a cool, I say cool, it's such a thoughtful piece that you wrote. And one specific emperor or naked emperor that you talk about is the five wise. But before we get into that, I want you to kind of explain what you mean by naked emperors and tech if that's okay. Yeah, sure. It's a little bit of a clickbait title, but I just like the sound of it. But it's actually a reference to the emperors' new clothes, which is a classic children's tale where there's people who trick the emperor into wearing clothes and they tell the emperor that these clothes are invisible to those who are stupid or incompetent. So not wanting to appear stupid or incompetent. He doesn't say anything. The advise is around him doesn't say anything and he goes out on a parade around his town or city. And everyone knows that only the stupid or incompetent would see the clothes as invisible. So they don't say anything. And it took a child to look at the emperor and not know anything and just say, hey, the emperor's naked. And then it just broke this wall, right? Everyone realized that it's not them. It's just that everyone was also operating under this sort of illusion. And the moment someone said something, it kind of broke that national equilibrium. Sorry to bring in some people there. But it kind of broke that trade off and then everyone was able to acknowledge the truth those staring them right in the face. And I think there's a lot of naked and present tech because there are a lot of things that people say as if they're true, just absolute truth. And they say them over and over again. And then we hear them a lot, therefore we start believing it in ourselves. But then they also fall apart with a little bit of inspection. So I think that people, especially developers, should be more demanding of the truths they hold dear because we're pretty exacting people normally. It's just that when we communicate, we tend to be very lazy because we're humans. So I tried to point some of these out. I definitely cover for some of my hot tics. But I tried to focus on things where there's a real chance that everyone is thinking something and not saying it because it's either not polite or they don't want to look incompetent or they want to look rude. They're just thinking about it. But then they say the thing they're supposed to say. But it's harmful to people who come in and take those things as gospel truth because then they feel like they're trying to point out the naked emperor. But then they feel like they're just new. So maybe they just should just shut up and do with it. Like everyone else around them is dealing with it. So I think that's it's harmful from that point of view. So I try to make the case that we should point out more naked embers. Yeah, this is really interesting. The one that hit me, the hardest was certainly the five wives because it is the Toyota method. It's this thing if listeners, if you're not familiar with this idea, it's that you continue asking or inquiring down a single line of reasoning. If there's one reason, one primary reason that you can come up with that something has happened or one reason, primary reason for making a particular decision. You can continue tracing that back. And eventually you're going to get to something more core, whether it's core to your humanity or core to the problem, the idea is theoretically that you can find kind of the root, the root cause of a problem or the root cause of a behavior. But as you point out, this isn't always true. And almost certainly there's more than one answer to each of these wives. It's much more like a tree of wise rather than it is five wise. But I'm curious what you think about that. I'd say that's true. But also something I did not point out in my post. Have you tried working with someone who tries to apply the five wise religiously? They always work probably back pretty annoying. They always work back to the systems ruined. We need to tear up everything and rebuild the system from scratch. What are you supposed to do with that? If you're a fifth wise, there's no ethical consumption under capitalism. You're pretty bad at depressing place and no one has a work with you. So it's not very constructive, it's what I try to say. So there's that. And then there's this overly simplistic thinking that there is a single root cause for everything. So my lead to Jon Hall's op, I don't actually know his name. It's Kitchen soap, his locals. But where it's basically saying complex system is complex failures have complex causes. They need a number of things to go wrong all at once. And it's not the fault of any individual thing. It's just a combination of all of them that cause complex failures. And most of the things that we work on are complex failures. So five wise does work if you're assembling a car on a manufacturing line. But maybe let's not apply that analogy so strictly to you know, devolver pro organizations to dependency chains that are thousands of modules wide. It's not so simple and that's not, it's not pretending that it can be so simple by repeating things that have been essentially out of date for like 60 years and we still repeat them. Right. Yeah. And you know, for what it's worth a lot of these things that you point out are not so much a method like the five wise is some of them are just platitudes. Like there are no stupid questions. The idea that we should always, the second one is the third one is regret minimization framework. The idea that we should always choose the option that is most likely to avoid regret. And you know, the many different things that we say in tech that are absolutes. I think the common pattern here is that the absolutism is likely. It's the thing that makes it easy to say, right? It's the thing that says, oh, this is here's a black and white rule or a black and white platitude, a thing that you can always follow and always rely on. And things just aren't that that simple. They are much more complex than that. There's certainly a gradient of answers or a gradient of realities within each of these things that we talk about here. Yep. Today's episode is sponsored by Linode. Linode, you can simplify your infrastructure and cut your cloud bills in half with their virtual machines. You can develop, deploy and scale your modern applications faster and easier. Whether you're developing a personal project or managing larger workloads, you deserve simple, affordable and accessible cloud computing solutions. You can get started on Linode today with $100 in free credit for listeners of Developer Tea. You can find all the details at linode.com slash Developer Tea. Linode has data centers around the world with the same simple and consistent pricing, regardless of your location. You can choose a data center that's closest to you or closest to your customers or both. You also receive 24, 7, 365 day customer, human customer support. No tiers, no handoffs, regardless of your plan size. You can choose shared and dedicated computing sensors or you can use your $100 of credit on S3 compatible object storage, manage Kubernetes and more. When I think of having a side project or a project at my home, I immediately reach for Linux and if it runs on Linux, it runs on linode. Head over to linode.com slash Developer Tea and click on the create free account button to get started. Thanks again to Linode for sponsoring today's episode of Developer Tea. So I want to take a step back and ask you a question I'd like to ask all the guests who come on the show. What do you wish more people would ask you about? Oh, that's a great catch all question. I wish that next time. Oh, shit that. So I've only ever been asked this once on a podcast. I've done quite a few podcasts. But I've only ever been asked about tech strategy once on a podcast. And so you know, one of one of the things that tech strategy, technology strategy, so developers are very keen to define themselves and to discuss technical issues around code. But then they're very uninterested in how people make money from that code. There's obviously a subsection of people who are very interested in money, but developers are very strangely not very interested in the business impact as a whole. Developers are not very interested in the business impact of the code. They are very keen on, oh, look at this functional pattern, this design pattern, this reduces errors. It's great, but there's only so much that the outside world actually cares about that. And there's definitely a lot more that impacts our careers and our incomes to be quite honest when it comes to making money from your code. So I feel like that's something that should be very interesting to people. But it's consistently, these are things I write about in my book. I have a section on principles, section on tactics, in a section on strategy. And I get a lot of questions about principles and tactics, but not so much in strategy. And I think that's people short-changing themselves or just not seeing themselves in the total context of why they're paid so much and how they can make some more. Those two things are not at odds because developers are very valuable things. But I think it's up to you to figure it out. No one's going to tell you because we're too busy figuring it out for ourselves. And so I feel like I have a unique perspective because I used to be in finance. I used to be a hedge fund trader. I used to invest in tech stocks. And I constantly think about this. So yeah, I do wish people asked me more about that. Well, I have a question as a developer, as a career long, this is what I started doing. And at this point, I'm in one of a managerial position that I was in a software engineering position, or then I am. And my question is, what do you think is the reason for this? Or maybe a better way to phrase that is, do you think that engineers are actually disinterested in this? Or do you think that there's something else going on? I think yes, they are disinterested in this as a whole. Again, there's very significant exceptions. I, you know, as I explained why it's a little bit difficult. It's probably a number of reasons. There's no five wise. But one of them would be, for example, that it is hard to prove. Like you can't just run it in a terminal and see the result. It's more of a fuzzy, like economics, hand-wavy type of thing. So people don't like that because you can have conflicting answers and not know which one is right until you try it. And then even then it's probabilistic. This is 20% more likely to be right. What are you going to do with that? Where is I think in code? It's a lot more clear sometimes. Not always, but sometimes. So yeah, I think that's definitely one of it. And then there's the other part, which is that there are a lot more juniors than seniors. And for junior developers, you are not concerned about any of that yet. You're just trying to make a living writing code for a living. So it's perfectly fine to not be aware of that. But I think as you go up, then you're evaluated more and more in your business impact. And then you start to think about that. And then the people who are in the management or senior ICs just don't talk as much. They do talk. They're just not as frank or open sometimes. So there's just less people who are publicly discussing this stuff. Yeah, it strikes me that software engineers in particular can climb into very high level positions in companies very quickly. And so what you were doing three years ago, because you loved it and because it was fun, it was like putting, you know, it was the first time that you had a chance to create with a computer. A short three years later, people are asking for you to be, you know, concerned with much higher level things. I say higher level, a higher layer of concern. And in your mind, or at least this was my experience, in my mind, you know, I was still enjoying the coding product. Like I was still enjoying and learning and feeling like that playful sense rather than the what seemed like a more serious idea that I had to turn around now. And instead of using this for play, it's now, you know, I'm a grown up now. You're right. I have to use this for real money. And I think the perhaps false promise that a lot of developers buy into is that, hey, you can come and play for the money, right? That's you can come and do the thing that you really love doing. And money will just find its way to you. Right. There's other people who are responsible for it. They're going to funnel it your way. They're going to pay you to do the thing that you love. And while that in some ways has borne out to be true for a lot of people, right? A lot of people actually do get to kind of sequester their concerns away for a lot of people who want to make this a long-term career. They absolutely would benefit from saying, hey, wait a second. Let me take my layer of concern up out of the code for a minute. And look at, I don't know, and we can dive into this a little bit more about what it actually looks like to think about strategy. I'm curious to, you know, what are those kind of pieces? Well, what are the types of questions? What are the things that I should be looking at to go from those more tactical things, those code design things to strategy? I present this problem in a few steps. So I hope that you can follow along with me. There's a loose logical chain. So where I like to start is that most developers are familiar with strategy games, and they think that that's strategy. But we are kind of being sold a bit of goods there because strategy in games, they kind of offer you infinite runs of the finite game. There's a start and an end. And you can run them over and over again to get better and better and better. But strategy in life gives you one run of an infinite game. Misinformation, out numbers, information, and the rules are constantly in flux. Where strategy in games, the rules don't change and you have almost perfect information. So we're very, very poorly prepared. And by the way, strategy in games is an analogy for programming, right? We like statelessness. We like to be run things. We like reproducibility. Life doesn't have any of that. And so it's a very, very difficult thing to transition to. And I think one of the reasons it's important is that realizing that when you study highly productive engineers or top engineers, it's not so much the output that they are in. The bra, like numerical output, you know, I actually have a quote from somebody at Google who talked about Sanjay Gamelat and Jeff Dean, you know, where like the top individual tree with a contributor is in Google. They actually are not that more productive than a SWE3, like a junior engineer at Google. But the problem, the insight is that they really apply the productivity to things that matter, right? And it's about choosing problems more than being like a code wizard that just blows through 100 times more tickets than other people. It's not, you know, your primary unit or output is not your tickets. And we're trained to do that because that's how we're incentivized and managed. But really, it's about picking important problems. So strategy, my definition of strategy, is the problem of choosing problems. Strategy answers what should we be doing? Strategy defines where to play and how to win. So that's kind of where I want to, you know, set the level. Like we are not used to playing this. The rules are very different and we are so used to solving problems that we're not good at all at choosing problems. And so I think that the four tools that we kind of need to tackle that, and this is not my definition, is actually something that comes from a bunch of people who study strategy. So I kind of just rephrasing what they have. You need a mental model of present reality. So like where you, your competitors and the larger technological landscape are, you need a vision of the future where you want to go. So where you are, where you want to go. You need a plan from getting from here to there. And then you need a policy for choosing what to do and what not to do with a clear rationale and understanding of trade-offs. So that's kind of like the four part breakdown of strategy. And then you can try to map that to things that you can actually do to execute that. Does that make sense? Yeah, can we go back through those four things, just in a straight list? Yeah, the simplest one is the mental model of present reality. Like are you looking around you and having a clear eye view of where you are, where your competitors are, and where the larger technological landscape is going? Is that too much? Thanks so much for listening to today's episode of Developer Tea, the first part of my interview with Swyx. Hopefully you found it as insightful as I did. I'm excited to roll right into the second part of this interview in the next episode of this show. And if you don't want to miss out on that, make sure you subscribe and want to repost casting it up. You're listening to right now. This episode and every other episode of Developer Tea can be found at spec.fm. Thank you to today's sponsor, Lynneau. Head over to Lynneau.com slash Developer Tea and click on the create free account button to get $100.00 that's $100 in free credit that goes a long way on Lynneau. Thanks again to Lynneau for sponsoring today's episode. Today's episode was produced by the brilliant Sarah Jackson. My name is Jonathan Cutrell and until next time, enjoy your tea.