This week we're talking 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".
Today, we're continuing 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 2 with Swyx, we focus in on productivity, strategy and tactics of senior vs. junior engineers and what beginning engineers can do to level up in their career.
Thank you to New Relic for sponsoring today's episode!
Make managing and analysis of complex digital architectures work for you. Check them out at NewRelic.com to become a full access user with 100GB per month totally free.
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.
When you study highly productive engineers or top engineers, it's not so much the output that they, the raw numerical output, I actually have a quote from somebody at Google who talked about Sanjay, Yamawatt, and Jeff Dean, who are like the top individual contributors in Google. They actually are not that more productive than a SWE3, like a junior engineer at Google. The problem, the insight is that they really apply the productivity to things that matter. 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're your primary unit of output, it's not your tickets. We're trained to do that because that's how we're incentivized and managed. But really, it's about picking important problems. You just heard the voice of our guest today, Swyx. Soix was on in the last episode of Developer Tea. So if you missed out on that episode, I encourage you to go back, you'll hear a little bit more about his background, especially, so you can kind of see where Swyx is coming from. If you've ever wondered about the nuances between strategy and principles and tactics, then this episode is for you. And this episode is for you if you haven't wondered about those things because you will learn a ton about how the next step in your career might be to abstract your thinking. My name is Jonathan Cutrell, you're listening to Developer Tea. My goal on this show is to help driven developers like you find clarity, perspective, and purpose in their careers. Thank you so much for listening to this show. Now let's get straight into the second part of my interview with Swyx. The question that I think is hardest to answer for, let's say a junior or mid-level engineer, is how do they get to the right place to think about those things? Are they supposed to invite themselves to a strategy meeting? Where does that happen? What is the crossroads? Or they say, okay, instead of just picking up a ticket, I'm going to, for example, I'm going to push back against it and say, oh, I don't think this is the right time to work on this. What are those actual kind of concrete actions that I as an engineer can take to move me more into the strategy discussions? Okay, so what I was talking about earlier was more of like just being aware of what's going on, like staying informed. But what you're talking about here is how to add more actively incorporate strategy into your own work. I think that one is more of a self-driven approach, I think, because no one actually does this consciously. I mean, let me rephrase that. I don't think many companies sit their engineers down for strategy planning session. I think that you can probably more actively advocate for that in your water cooler discussion and your one-on-one meetings with your managers and actually have more of an active conversation. One of the very effective examples that I've seen is a friend of my Matthew Gersman who works at Dropbox. He actually started a JavaScript Guild. He was a software engineer, just like a lot of others in Dropbox, but he started an extra-curricular organization internal within Dropbox that focused on important topics within the JavaScript ecosystem. Then he ran that and was well known in his career for that. He ended up setting some of the JavaScript strategy for Dropbox. Nobody ever asked him to do that. He just came up with it on his own accord. But then once he did it, everyone recognized the value of it and then the company supported him financially. They were able to hold internal conferences where they could hold these discussions. It's a little bit of, you don't ask for permission, you can just do it. Because it's valuable because you're doing the right thing, people will recognize that and reward you. Yeah, don't wait to be asked. Yeah, that makes sense. I think it is a challenge because, like you said, there's a difference in becoming aware of this and actually doing something about it. There can be a conflict. And I've experienced this personally myself where I felt like I was, there was an imbalance between my awareness of a need for strategy and my leverage to make that strategy a reality. And I've been there before. And I think that that is really where the hard work comes in. It's stepping in and saying, okay, I'm going to take one step towards making the right decisions, the right strategic decisions. And eventually, theoretically, that should bear out in value for the product value for the user's value for the company. And assuming that your strategy is right. Is that your understanding of how that should play out? Yeah, I definitely agree with that. For sure, if you don't have that much influence, then actually your best strategy is more of career strategy rather than technology strategy. But that's also very valid and it's something that we should discuss. But I do think that engineers have more control over strategy than they realize. You are in consumerist strategy as well. The tech choices that you make are reflections of what do you think of other people's strategy. It's strategy on the way down. You can't really just say, don't have a say in this. You always do. And you should recognize your own agency in your own outcomes. And I think that's an important recognition. But for sure, I think when you feel like you have less influence, then probably the right focus is career strategy, essentially climbing up the ladders. And I've actually surveyed all the public company engineering career ladders out there. So you can check out my blog for that or I also have a chapter in the book. But yeah, it's something that's worth talking about where you don't feel like you're that empowered to pursue strategy. But definitely you can start training for it because that's when you're in a position to exert some influence over the company's strategy, you better have some practice. Well, it's a convenient transition here because you have the coding career handbook, which is at learninpublic.org for anybody who's listening. And interested in these topics. But I'd love to walk through some of the, like you've already mentioned, principle strategies tactics. I'd love for you to kind of differentiate for me here. What are the differences between these things? Principles, strategies and tactics in your mind or at least as you present them in the book. The principles are good rules of thumb to always have on in the absence of anything else. Like if they're just good defaults, they default behaviors that I find are more rewarding than other default behaviors. So I try to stress them as much as I can. Obviously you can, you don't always have to follow them, but they're just good ideas to be able to live by. And I even call them good algorithms to live by. After principles come strategy. So if principles are always on, then strategy is not always on because I don't expect engineers to be full-time strategists. That's a separate job. But I think that when you're making large, one-off irreversible decisions, then strategy starts to matter quite a bit because then it becomes the domain of more finite games than infinite games. And finally, tactics are one-off, but they're small instead of large. So there are just things that you do a lot of that you would like to do better and might positively impact your career. But there are sort of relatively commoditized skills like speaking or writing and marketing yourself. These are still important, right? But they're not in the domain of strategies or principles. So that's kind of how I break it down. And then at the end of the book, I actually draw a very helpful diagram, which I kind of very delete, but it's kind of on purpose because I think that you have to go through the journey in order to appreciate it. So tactics help you in your current job. Strategy helps you in your career, so a chain of jobs. And then principles help you in your life as a person. Yeah. But there's a one-to-one matching of each of those. So this strikes me that I think the way I've seen similar breakdowns to this is that you kind of choose, you go to the other direction in choosing principles that will birth your strategies and then based on your restrictions, you can choose tactics to accomplish those strategies. And it's kind of this like nested OKR style, you know, kind of. Yeah, you said true. Yeah, I'm interested in focus. Yeah, exactly. So like, I think a lot of people focus on tactics because those are more objective and more easy to share. But that's the lowest level. If you're doing, if you're overly focusing on tactics and you have your principles and strategy wrong, then you're not going to be as effective as if you focused on, you know, those more fundamental things. So yeah, I absolutely do believe there's some level of nesting there. You did mention something earlier that I want to bring into this discussion and see how it fits in. You mentioned the idea of a policy, right? This idea, and this is when we were talking about strategy. But I think what I'm interested in, I guess, is these guiding policies that an individual might choose, I'm wondering how you see values fitting into this picture, right? Because for some people, they might conflate the idea of principles and values as an example, right? For me, looking at this picture, I see values as kind of this filtering mechanism on all three of these. Or perhaps on, yeah, I'm not sure exactly how it fits, honestly. And that's what I'm wondering, how would you put values into this picture, if at all? I haven't really thought about it that much. I kind of conflate principles and values, if I'm being honest. So they're the same thing to me. I think a principle life is one that lives with values. But I don't really focus that much on it. And it's something I do care about, for sure, that what, you know, having a clear value stack and understanding what you value over others. And maybe it's a future version of the book. It's, you know, it's, this is my first year doing this. And it's a very uncomfortable thing to do because it's so widespread. Like it literally is, please spend all the non-tentical aspects of coding careers. But yeah, so far, I have it down to three things. In fact, so there was one entire section of book that I did not write, which is concepts. And you may have just given me an idea for fifth section, which is values. Well, I did talk about, so one thing I do stress in terms of my thinking is that when you do technology choices, right? So when you pick frameworks, when you pick languages, a lot of people talk about picking languages or frameworks based on performance features or like syntax, you know, things that you can sort of see in code. But again, actually, the more fundamental disagreements usually come from disagreements and values. And so if you don't value the same things as the community or the maintainers of a thing value, then you will eventually grow to dislike that framework on that language. So I gave some examples of, for example, the original creators of Node.js and Express.js, TJ and Rindal. They both left because their values conflicted with the community that eventually formed around the very things they started to create. Widow, Van Russen from Python, stepped down from being BDFL Python because he disagreed with the values of the community that he formed. It's a very, very common thing for creators, I guess. But also, I guess, when you choose a language or a framework or library, you're also choosing the values of the maintainers of those things. And eventually, you're going to suffer if you don't know who your values are. Yeah, or at least you're going to have to find common ground and deal with the differences. And that seems to be a difficult thing to do. I think there is a large enough gap between your values and the values of that particular thing that you've chosen. And I think I see principles and values at least overlapping for me. And some of that is because some of the principles that I choose are more about kind of heuristic, like you mentioned, they're kind of like good ways, good patterns of thinking. But those are only good patterns of thinking. If you also ascribe to this other kind of arbitrary value, right, that value is somehow accomplished by holding to that principle, whereas other principles are kind of derived principles, right? They're observed in nature or there's some kind of mental model that is outside of something that I choose. For example, a scientific approach or a scientific method might be, and I don't know, maybe it fits somewhere else. Maybe it is part of strategies or tactics, I'm not sure, but it seems like having a scientific approach or iterative approach could be considered a principle that is somewhat devoid of values. It could be. Yeah. Today's episode is sponsored by New Relic. New Relic is observability made simple. Monitoring a complex digital architecture typically takes a dozen different tools and they're all over the place. You have to keep track of all your logins, probably have multiple different ways of doing two-factor authentication and it just takes forever to try to track down an issue or bring together the stats that you need to bring together to create a report. Troubleshooting means jumping between all of those dashboards and data to get the information that you need and by the time that you do that, you probably aren't really responding quickly and kind of defeats the purpose of observability. New Relic wants to change that and they've designed everything you need in three products. The first is a telemetry data platform which creates a fully manageable, schemalist time series database of all of your data from any source. The second is a full stack observability for analyzing, visualizing and troubleshooting your whole stack and third is the brains of it all, the applied intelligence that seamlessly automates anomaly detection and incident intelligence correlation using AI and ML. Best of all, you can get it for free. There's no host base pricing, no constant upsell, just 100 gigabytes a month to one full access user for free. Check it out at newrelic.com. New Relic is observability made simple. So I think this is such an interesting way of thinking, but I'd love to talk about maybe one or two of the spots, spot checking here in the principal strategy tactics. Is there anything that you feel like is your strongest or most appreciated? Maybe your favorite principle or strategy or tactic that you talk about in the book? Yeah, I think I'm best known for the learning public principle and that's a essay that has been basically kicked off my weird non-tentical advice writing career. But the follow up to that is my favorite. It's called pick up what they put down and it's a prescription for people getting started learning in public because a lot of people get inspired by trying to do more stuff in the open, but then they don't know how to do it. And so this is a six word piece of advice that will guarantee you feedback, will help to focus and choose topics for you. And basically it's the idea that if you want to guarantee feedback, you should respond to what your mentors, your prospective mentors are putting out. People at the top of their field are by definition very, very busy, but they're also always putting out work. And a lot of times the feedback is very limited because everyone has their own lives going on and the majority of people are passive consumers. So it takes some non-laciness to be active, responded and participant. So what am I talking about? I'm saying whenever you listen to a talk or intent a podcast, you might want to write some takeaways and share it. Whenever you see them write out a blog post, you might want to go through that. If they put out a demo, you might want to go through the source code and give some feedback. You might even spot some bugs. And so on and so forth, if they put out a book, work through it and call out your top five takeaways. And what that actually gets you is that they'll probably read it because they're very highly attuned to early feedback. And that's where it's most valuable. So you're coming to them and helping them with the one thing that you have, which is a bigotors mind. And so you can get access to very top people out of their field that way because there's just not that many people would do it. So it's kind of a hack. And what's also great is that it starts off your content creation career because you don't have to come up the topics. You just respond to other people. And when people read your work, they don't really care who you are. So you don't have to be an authority or anything. You can just summarize other people's work. And it's valuable in that sense already. And so your authority is kind of derives from them. So eventually if you do this enough and you do a good job, then they start to regard you as a collaborator and eventually your friend and peer. And at some point, hopefully, you start to see their flaws and you start to disagree with them. And maybe you'll be your own expert in authority in that sense. But I think that's a very reliable and fast way of coming up in any particular field. Yeah. Wow. So what's so interesting about this, it's it's pack full of good advice. And I think a lot of going to built in wisdom. I like that it's a principle because it works as a heuristic. It's a way of saying, okay, if you're not sure what to do, just go go follow behind the people that you aspire to be more like, right? And listen to what they're saying and then consume and then respond to it. I think this is so insightful. And I think one misconception that people have right off the bat about their the people that they aspire to be like is that they're way too busy to ever see anything that they say, right? This is a very common misconception I think about anybody in the public sphere that's gotten more than the average attention is that they're too busy. They've suddenly become a super, you know, superstar untouchable kind of person. And that's simply not true. A very simple example is all of the podcasters that I know when they get messages from people, myself included when I get messages from people, it's very rare, believe it or not. It's very rare to get a message from somebody who is just saying, this is not me asking by the way for a day loose. Yeah, but it's true. It's true. It's not as often as maybe I don't know what it is that makes us think this, but it certainly is a pervasive kind of picture. And so it feels like a very distant place that that person is living in. And it's really not. It's really not. It's very likely that you could write an email to that person and they will read it like the same day. They're very much like the rest of us. So I definitely think I'm going to take this advice for myself even going forward. So thank you for sharing that. Is there any other point in the book that you would like to bring out in and maybe for the people who are skeptical that it's for them? Like say, for example, I'm a software engineer that turned into an engineering manager. What part of this book do you feel like is most relevant to people who would identify in that same role, the engineering manager role? Well, I would not feel qualified to make a judgment on that because I'm not an engineering manager. So this book was very much focused on the junior developer to senior developer transition and to get them up that curve in a sustainable, repeatable, healthy way, not to get them out fast. I think a lot of books and advice focus on speed. And I objectively did a fast job of it myself, but I think that what we care about is sort of things that last. So I care about lasting more than being fast. There's some sort of rhyme there which I was trying to work out. But I think that the final topic that I end on is kind of true regardless of who we are. And it's this idea that I call the operating system of you. It's a very catchy title. I was very proud of it when I thought of it. And I've given a couple talks on it, which I do you know we can send people to if they're interested. But it's this idea that all of the let's let's say you know there's some error rate on the principles, the strategies, the tactics that I published. So let's say like half of them are wrong, half of them are right. You don't know which one to follow. Whatever. So let's just assume for a second that we had from from God, from like whatever your absolute source of truth is, let's just assume that we had perfect advice, perfect information. The best courses, the best principles, the best strategies, the best tactics. Would you be able to incorporate it in your day to day life? And the answer maybe no. It would certainly be no for me because I don't have a system to process and incorporate that information. Right. We are so good at consuming information because we are we have a information overload in society. But what we need to do is actually have an operating system to process and implement those things which we think are good ideas. So it's very much it's very much like if I don't do this, then the preceding 39 chapters will be completely wasted because you would just have read a bunch of words. It would have gone into your short-term memory and then it will have left and you will be left with the shorter life. And that's not what I'm about to this is what I'm going for. So we need to take care of our operating system. We need to tune it. And we need probably need to spend more time on it than we do, which is not a lot. Compared to the stuff we love to talk about like, oh, how do we get promoted? How do we you know, how do we pick up what they put down? Like, oh, that's great. That's awesome. But are you sleeping enough? Are you taking care of your hands? You know, when when you survey the most accomplished and long-lived programmers, like when talking Bill Gates, when he talks about things he regrets from building Microsoft, he says he doesn't sleep enough. He did not sleep enough. And arguably he says that because he's successful, right? So it's like, all right. Yeah, yeah. But we survived. We survived. Yeah, maybe if he did not, maybe if he slept more, he would not be successful. We don't know that. But all we have is his own judgment of what he genuinely thinks. He's got nothing to sell here. He's got nothing to gain from us. He just genuinely thinks that at his point in life, he does think that he should sleep more. And maybe that's a reflection that we can take home. Scott Hanselman, who was big in the C-sharp.net world, his career advice is take care of your hands, take care of your back, take your vent neck, right? Like when you survey these people who have been in this game for like, you know, a lot of a lot of advice comes from people who have been in this for like five to ten years. But like, talk to the people who have been in this for 20, 30, 40 years, you have a very different set of results because they care about the being in the game the longest. And that's where you are, achieving the most impact and being being more successful. So I do think about that a lot. And obviously that would apply to engineering managers to round back to your engineering budget. So absolutely. So that's one part. So just to break it down for people, there's four parts of the operating system. You know, philosophically, there's the form where, right? Which is you are operating through physical devices. There's your memory, right? Like how do you store in your state? There's your scheduler, which is sort of prioritizing tasks and multitasking, right? You have a bunch of applications that you're running and helping between them. If you have a bad scheduler, then you're not as productive as you could be. And then finally, there's your kernel, right? The core underlying process that runs out all the other processes. And the kernel is kind of what I want to end with as well is basically your drive or your motivation to code. And I see a lot of people on Hacker News, they kind of just burn out. They're on paper, they're super successful. They would be like super senior staff, principal, distinguished engineer at Google. And they would have no joy of their job, right? They just don't feel like coding. So that is game over, right? For your coding career. So you want to stay in the game. You want to enjoy what you do. So I think those are things I wish that people would definitely think more about. I mean, people definitely do. It's just that it's not something that we talk about on a day-to-day basis. And we maybe should talk about it more. I totally agree with this. I think especially right now, a lot of people like me, you're kind of stuck in your home and the year has happened to you, right? In some regard, you kind of feel like things have kind of swept your feet out from under you. And it's very easy to focus on the minutia when this happens, right? It's why we can work until 7 pm at night. And check our email for the remaining time that we're awake. That's the minutia. And we're not paying attention to your point. We're not paying attention to our operating system. And certainly, that is the kind of thing that can wear away at that drive, at the kernel that you mentioned. And so it does make sense to take a step back and remember, in unlike computers, we are, all of these systems are deeply integrated with each other. So the things that are happening at the edges actually affect things that are happening at the core and vice versa. So I think we do have to take a step back and say, okay, what am I forgetting to take care of? That especially at that firmware layer, I think that is so often forgotten, when we're going through stressful periods, we're willing to put ourselves, our health especially on the line. And that can be really detrimental. So that's such a good reminder. I did watch that talk, by the way, excellent talk. A little easter egg for people. You do have this idea of virtualization. I don't want you to cover it right now because I want people to go and watch the talk to find out what it is. I basically ran as far as the analogy as I could. I know. I loved it. I thought it was great. In my head, I was like, all right. So what is HTTP in this analogy? You know, like, you know, we have communication protocols with other humans. Exactly. Right. What is the networking predator? You know, who's on my local area network? Thank you so much for taking the time today. I know we're running up right on our time. But I appreciate you sharing your wisdom, your thoughts with the engineers who are listening to this, the manager who are listening to this, and the people who have nothing to do at all with engineering right now who are listening to this, to this episode. I think they also probably gained some insight from you. So thank you so much for taking the time. Yeah. Thanks for having me. And you may be, you may be pleased to know I've been having tea while we did this. So I'm going to pass you a coupon for some discounts. I love putting on some 30% off discount for people who make it to the end of one of my podcasts. So hopefully that helps people over the hump in checking this up. Awesome. Do you have the, do you have it to bring out now? Yeah. It's learning probably dot org slash C equals, and then out to devT30. I'll type it in in in the description notes. Perfect. All right. Thank you so much for your time. Thanks, Sean. Thank you so much for listening to today's episode of Developer Tea, the second part of my interview of Swyx. If you missed out on that first, first part of the interview, I encourage you to go back and listen to it. It'll make the second part that much better. Swyx has very kindly provided us with a coupon for Developer Tealisteners. You can get 30% off the coding career handbook by going to learn in public dot org and using the promo code devT30. You can also find a link to this that will automatically apply that coupon. It's just using C as a URL parameter for those of you who want to enter it manually, but that is devT30 and you're going to get 30% off and it's any of the packages that you find at learninpublic.org. Thank you again to Swyx for joining me on today's episode of Developer Tea. And thank you for listening. This episode was made possible by today's sponsor New Relic. New Relic is observability made simple head over to newrelic.com to get started with a full access user 100 gigabytes per month totally free. This episode of Developer Tea and every other episode of this show can be found on any podcast platform of your choice. If you would like to ask me a question and it might even be a question that I can cover on this show. You can email me at Developer Tea at gmail.com. You can also reach out to me on Twitter at at Developer Teaor my personal Twitter and at jCutrell. This episode was produced by Sarah Jackson. My name is Jonathan Cutrell and until next time, enjoy your tea.