In today's episode we talk to another person who is dedicated to learning in public. Today's guest is Shawn Swyx Wang and this week we're talking about his new book, "The Coding Career Handbook".
This week, we continue the discussion of learning in public with guest, Shawn Swyx Wang.
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.
Thank you to long time sponsor and friends of the show Linode for sponsoring today's episode!
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.
In today's episode, we talk to another person who is dedicated to learning in public. Today's guest is Swix. Swix 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 React.js subreddit mod for quite a while. And now, Swix has recently released his book, The Coding Career Handbook. You can find this at learninpublic.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, Swix 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 Cottrell, and my goal on 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 Swix. Welcome to the show. Thanks for having me. Thank you for joining me. I know that we have, we've 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, but I can't help but read the content that you write, especially and think, oh 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. Uh, I would like that too. Uh, I think a monoculture is not that healthy and maybe, you know, we all are drinking from the same well, you know, and, uh, so yeah, we, we, we can definitely explore some diversity of ideas. Yeah. I think, I think, uh, that monoculture is definitely a problem and it can be easy also on the, on the flip side, um, to. Try to reject culture just, you know, offhand, right. To say, oh, everybody's going that way. And it is certainly in vogue to, uh, choose a countercultural path, whatever that is, whether it's in a framework or, uh, in, you know, some personal belief or something. Just so you can maybe artificially increase the diversity of the pool. Um, what do you think about that? 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 you, what you think about that. There's a hipster streak in tech for sure. But, uh, 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'll, they'll just automatically hate it. Uh, sometimes that's a good thing. Sometimes it's not the quote that I always use is from, uh, I can't, I don't speak French. So I'm not. Yeah. I'm not a French. So pardon me, but it's Francois Rene de Chateaubriand and it's, you are not superior just because you see the world in an odious light. Meaning that, uh, you don't, you, you might feel like you're better than everyone. If you, if you just see that, if you just shit on their stuff, but actually you're just, you know, you're the, you're the bad person. So, I mean, yeah, it's just, you know, people have this, uh, sense of status, you know, they, they want to show that they're smart. They're, uh, they, you know, they, they, they, they make different choices in the majority. Um, but just don't put others down, you know, that's, 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, uh, you know, towards the majority and the wisdom of the crowd, um, general mindset. But then there's also this other part of me that says. Well, maybe I'm just being the, the old guy who says, get out of here with your new stuff. Right. And so I, you know, 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. There's also, uh, an element of fashion. So, you know how. Uh, the songs that we listen to are mostly. Shaped by what was popular when we were in high school or college. And, and then we listen to that essentially the rest of our lives. Uh, there's also this, this tendency of people to think that what they learn when they learn to code is essentially the correct state of things. And then, uh, old stuff is, is obviously bad. And how did it, how did anyone ever use that old programming paradigm? And then new stuff is just terrible. Yeah. It's just terrible. Uh, real programmers would do exactly what they do. So, uh, it's a very generational thing. And, uh, uh, I, you know, so, so that's a, 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, uh, law, which is like a human law. It's not a, it's not a physical law, uh, called Maver's law L A V E R S. And it's this idea that, uh, things that are a little bit ahead of their time. Look a bit odd to us or offensive, but then, uh, things that are old, we suddenly venerate as beautiful or, uh, or, or, you know, and, and it's just, uh, we gotta be mindful that we are, we're just at a point in history. And, uh, we are knows we are nothing special. Like there will be whatever's hot now may not be hot in the future. So we should basically just stop judging everything as much. I'm curious. I'm curious if you think there's some, some degree of personality involved in, you know, how much you wait those things that the progressive side of things or the, the new uncomfortable, uh, 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 timescale. And so what's old to me is not necessarily old to you. Yeah. And what's new to me is not necessarily new to you. Yeah. 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, uh, one of the things that you wrote about recently that I want to talk about is actually your naked emperors in tech, uh, post. And this is, this is such a cool, uh, I say, cool. It's such a thoughtful, uh, piece that you wrote. And one specific. Uh, uh, 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 in tech, if that's okay. Yeah, sure. Uh, 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 emperor's new clothes, which is a classic children's tale where, you know, there's, uh, there's people who took the emperor into, into wearing clothes. And, and he tells them. And, and he tells the emperor that, you know, these clothes are invisible, uh, to those who are stupid or incompetent. So not wanting to appear stupid or incompetent, he doesn't say anything. The advisors around him didn'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 closest and it's invisible. So they don't say anything. And it took a child to look at the emperor and not, not know anything and just say, Hey, the emperor's naked. And then, and then it just broke this wall, right? Like, uh, everyone realized that it's not them. Uh, it's just that everyone was also operating on there, this sort of illusion. And the moment someone said something, it kind of broke that, um, Nash equilibrium. Sorry to bring in some gay theory, but, uh, it, it kind of broke that, uh, trade off. And, and, and then everyone. Where was, was able to acknowledge the truth that was staring them right in the face. And, uh, I think there's a lot of naked emperors in tech. Yeah. Because there are a lot of things that people say as if they're true, uh, just absolute truths. And they say them over and over again. And, uh, and then we hear them a lot. Therefore we start believing it in ourselves, but then they also fall apart, uh, 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 are, we're pretty exacting people normally. Uh, it's just that when we communicate, we, we tend to be very lazy. Uh, because we're humans. So, so I tried to point some of these out. Uh, I, it's definitely a cover for some of my hot takes, but I try 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 do want to look rude. Um, they're just thinking, thinking about it, but then they say the thing that they're supposed to say. But it's, it's harmful to people who come in and take those things as gospel truth because then, then they feel like they're, they're, they're, uh, you know, they're trying to point out the naked emperor, but then they feel like they're, they're just new. So maybe they just should just shut up and, and, and deal with it. Like everyone else around them is dealing with it. Um, so I think that's, it's harmful from, from that point of view. So, so I try to, I'm trying to make the case that we should point out more naked emperors. Yeah, this is really interesting. Uh, yeah. The one that hit me the hardest was certainly the five wise because, uh, it is the Toyota method. It's this thing. If, if, if there's listeners, if you're not familiar with this idea, it's that you continue asking or, 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. Well, you can continue tracing that back and eventually you're going to get to something more core, uh, 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, uh, this isn't always true. And, and almost certainly there's more than one answer to each of these wise. 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. Uh, but also, you know, something I did not point out in my post, I mean, have you tried working with someone who tries to apply the five wise religiously? Uh, they always work back. It would probably be pretty annoying. It would be pretty annoying. Uh, and they always work back to like, oh, the system's ruined. We need to like throw a tear up everything and rebuild the system from scratch. Like what are we supposed to do with that? You know? Like, like if you're, if you're, if you're a fifth, why is like, there's no ethical consumption under capitalism. Then like you're, you're in a pretty bad and depressing place and no one wants to work with you. Um, and, uh, so it's not very constructive is what I try to say. So there there's that. And then there's this overly simplistic thinking that there is a single root cause for everything. So, uh, I lead to John Alls up. I don't actually know his name. It's kitchen soap. His, his, uh, his, his blog posts. Uh, but where, where it's, where it's basically saying complex system is complex. Failures have complex causes. Um, 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, 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, different things. At the same time, evolution brings evolution, evolution brings evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution evolution is some of them are just platitudes. Like there are no stupid questions. The idea that we should always, the second one or the third one is regret minimization framework. The idea that we should always choose the option that is most likely to avoid regret. And the many different things that we say in tech that are absolutes. And 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 simple. They are much more complex than that. There's certainly a gradient of answers or gradient of realities within each of these things that we talk about here. Yep. Thank you. Thank you. Thank you. Thank you. Thank you. You know, 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 T and click on the create free account button to get started. Thanks again to Linode for sponsoring today's episode of Developer T. So I want to take a step back and ask you a question I 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 people... I appreciate 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 the things that... Tech strategy? 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, you know, oh, look at this functional pattern, this design pattern. You know, this reduces... This reduces errors. That's great, you know. 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, you know, making money from your code. Like, you know, so I feel like that's something that should be very interesting to people. But, you know, it's consistently... It's... These are things I write about, you know. It's the one... It might... In my book, I have a section on principles, a section on tactics, and a section on strategy. And I get a lot of questions about principles and tactics, but not so much on strategy. And I think that's people shortchanging 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, you know, it's up to... 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, you know, this is what I started doing. And I've, you know, at this point, I'm in... I'm in a managerial position than I was in a software engineering position or than I am. And my question is, you know, 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, you know, a number of reasons. There's no five whys. But one of them would be, for example, that it is hard to prove. Like it's not, you can't just run it in a terminal and see the result. It's a, it's more of a fuzzy, like economics. It's hand wavy type of thing. So people don't like that because, you know, you can have conflicting answers and not know which one is right until you try it. And then even then it's probabilistic. Like this is 20% more likely to be right. What are you going to do with that? Right. Whereas, whereas I think in code it's a lot more clear sometimes. Not always, but sometimes. So, so yeah, I think that's, 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, then you start to think about that. And then the, you know, the people who are in, uh, you know, management or senior ICs just don't talk as much. Um, I mean, they do, they do talk. It's just, they're not as. Frank or open sometimes. So, uh, there's just less people who, 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 company. Yeah. Yeah. With a computer. A short three years later, people are asking for you to be, you know, concerned with much higher level things. Uh, I say higher level, a higher layer of concern. And in your mind, or at least this, 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, uh, that playful sense rather than the, what seemed like a more. Yeah. Serious idea that I had to turn around now. And instead of using this for play, it's now, you know, I'm, I'm a grownup now, right? I have to, I have to use this for, 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, you know, sequester their concerns away for, uh, 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, for a minute. And, uh, look at, um, 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 that. There's. Okay. Okay. Okay. Okay. Okay. Okay. Okay. Okay. Okay. Okay. Okay. Okay. Okay. Okay. Okay. Okay. Okay. 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 outnumbers information. And the rules are constantly in flux. With 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 rerun 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, the raw numerical output. I actually have a quote from somebody at Google who talked about Sanjay Gamowat and Jeff Dean, who are the top individual contributors in Google. They actually are not that more productive than a SW3, like a junior engineer at Google. But the insight is that they really apply their 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 of output is not your tickets. And we're trained to do that because that's how we're incentivized. And we're trained to manage. 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 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. We're not good 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. It's actually something that comes from a bunch of people who study strategy. So I'm kind of just rephrasing what they have. You need a mental model of present reality. So 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 for getting from here to there. You need a vision of the future where you want to go. You need a plan for 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 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 easiest one is the mental model of present reality. Like are you looking around you and having a clear-eyed 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 Swix. 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 to my YouTube channel. Make sure you subscribe to whatever podcasting app 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, Linode. Head over to linode.com slash developer tea and click on the create free account button to get $100. That's $100 in free credit that goes a long way on Linode. Thanks again to Linode for sponsoring today's episode. Today's episode was produced by the brilliant Sarah Jackson. My name is Jonathan Cottrell. And until next time, enjoy your tea. Thank you.