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, the raw numerical output. I actually have a quote from somebody at Google who talked about Sanjay Yamawat 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. And it's about choosing problems more than being like a code wizard that just blows through 100 times more tickets than other people. Your primary unit of 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. You just heard the voice of our guest today, Swix. Swix 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 Swix 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. You'll learn a ton about how the next step in your career might be to abstract your thinking. My name is Jonathan Cottrell. You're listening to Developer Tea. My goal on the 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 Swix. 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 where 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 those 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 more actively incorporate strategy into your own work. And 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, you know, sit their engineers down for a strategy planning session. And I think that you can probably more actively advocate for that in your, you know, water cooler discussions, 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, a friend of mine, Matthew Gerstmann, who works at Dropbox. He actually started a JavaScript guild. So he was a software engineer, just like a lot of others in Dropbox. But he started like an extracurricular organization internal within Dropbox that focused on important topics within the JavaScript ecosystem. And then he ran that and was, you know, well known in his career for that. And it ended up setting some of the JavaScript strategy for Dropbox. And 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. Like they were able to hold internal conferences where they could hold these discussions. So it's a little bit of, you don't wait, you don't ask for permission. You just kind of do it. And then, you know, because it's valuable, because you do, you're doing the right thing. People will recognize that and reward you. And yeah, don't wait to be active. Just ask. Yeah. Yeah, that makes sense. And I think that 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... my leverage to make that strategy a reality. Yeah. Um, and I've been there before. And I think that that is really where the hard work comes in. Right? 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, you know, theoretically that should bear out in value for the product, value for the users, value for the company. And, uh, uh, assuming that you're sure that you're going to do it, but you're not going to do it. Yeah. And assuming that your strategy is right. Is that, is that your understanding of, of how that should, you know, kind of play out? Yeah. I mean, I definitely agree with that. I, for sure, if you don't have that much influence, then actually your best strategy is more of career strategy rather than technology strategy. Uh, but that's also very valid and it's something that we should discuss. Um, but I, I mean, I, I do think that engineers have more control over the Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. more control over strategy than they realize like you are consumers of strategy as well like the the tech choices that you make are reflections of what do you think of other people's strategy like it's strategy on the way down and you can't really you can't really just say like i you know don't have a say in this like you always do and you should recognize your own agency in your own uh outcomes and i think that that's an important recognition recognition but for sure like i think when you're when you feel like you have less influence then probably the right focus is career strategy uh essentially climbing up the ladders and you know i have a i i you know 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 um but yeah like it's something that's worth talking about where you you don't feel like you're that empowered to pursue strategy but um definitely that's you know when when when you have when you're in a position to exert some influence over over the company strategy um you better have some practice well it's a convenient transition here because you have the coding career handbook which is at learn in public.org for anybody who's listening um and interested in these in these topics but i'd love to walk through you know some of the like like you've already mentioned principal strategies and tactics i'd love to for you to kind of differentiate for me here what are what are the differences between these things principal strategies and tactics in your mind or at least as you present them in the book yeah the principles are good rules of thumb to always have on in the absence of anything else like if if they're just 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 live by um you cannot even call them good algorithms to live by after principles comes 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 that's a separate job but i think that when you're making large one-off irreversible decisions you're not going to be able to do that because you're not then strategy starts to matter quite a bit because then then it becomes the domain of more finite games than infinite games then finally tactics are one-off but they're small instead of large so they're just things that you do a lot of that you would like to do better and might positively impact your career but they're sort of relatively commoditized skills like speaking or writing and marketing yourself these are still important right but they're not 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 i kind of bury the lead 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 there's a one-to-one matching of each of those so so this is it strikes me that i think what the way i've seen similar breakdowns to this is that you kind of choose you go 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 yeah interesting yeah exactly so like i think a lot of people focus on tactics because those are more objective and more easy to uh to share but that's the lowest level if you if you're doing if you're overly focusing on tactics and you have your principles and strategy wrong then you're not gonna 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 and see if you may want toension yourij discussion and see how it fits in. You mentioned the idea of a policy, right? 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. Having a clear value stack, and understanding what you value over others. And maybe it's a future version of the book. Possibly. 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 like, please span all the non-technical aspects of coding careers. But yeah, so far, I have it down to three things. In fact, so there was one entire section of the book that I did not write, which is called concepts. And you may have just given me an idea for a fifth section, which is values. I did talk about, so one thing I do stress in terms of my thinking is that when you do take technology choices, right, so when you pick frameworks, when you pick languages, a lot of people talk about picking languages or frameworks based on like 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 thing, you're not going to be able to the same things as the community or the maintainers of a thing value, then you will eventually grow to dislike that framework or that language. So I gave some examples of, for example, the original creators of Node.js and Express.js, TJ and Ryan Dow. They both left because their values conflicted with the community that eventually formed around the very things they started to create. Weedo Van Roosen from Python stepped down from being BDFL Python because he disagreed with the values of the community that he formed. It's a very common thing for creators, I guess. But also, I guess when you choose a 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 agree with values. 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 if there is a large enough gap between your values and the values of that particular thing that you've chosen. And I, like you, 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 values. And I think that's a good thing. I think that's a good thing. I think that's a good thing. 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 the reality of the world. And I think that's a good thing. I think that's a good thing. 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. And 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 schemaless time series database of all of your data from any source. The second is a full stack observability for analyzing, visualizing, and monitoring. And the third is a full stack observability for analyzing, visualizing, and monitoring. And the fourth is a full stack observability for analyzing, visualizing, and monitoring. And the fourth 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-based 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 principle, strategies, tactics. Is there anything that you feel like is your kind of strongest or most, I won't say 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-technical 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 I think it's a good way to start learning in public. 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, you know, I'm not going to do this. I'm not going to do this. And so I think it's a good way to start learning in public because a lot of times people are by definition, very, very limited because everyone has their own lives going on. And the majority of people are passive consumers, right? So it takes some non-laziness to be active, respondent and participant. So, you know, what am I talking about? I'm saying, whenever you listen to a talk or intense podcast, you might want to write some takeaways and share it. Whenever you see them put out a blog post, you might want to kind of go through that. And then you can also write some takeaways and share it. And then you can do that. Or like if they put out like 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. Right. Like if they put out a book, work through it and call out, you know, 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 beginner's mind. And so you can get access to very, you know, top people out there feel that way because there's just not that many people who 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 with 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 on 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 that. So eventually, if you do this enough and you do a good job, then they start to regard you as a collaborator and eventually a friend and peer. And at some point, you know, hopefully you start to see their flaws and you start to disagree with them. And maybe you'll, you know, 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 packed full of good advice and I think a lot of kind of built-in wisdom. I like that it's a principle because it works as a heuristic, right? It's a way of saying, okay, if you're not sure what to do, just 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 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... Yeah. 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's just saying, this is not me asking, by the way, for a bunch of delusion messages. Yeah. This is true. This is true. It's true. And often is 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, right? They're very much like the rest of us. Yeah. So, I definitely... I 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? 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, you know, healthy way, not to get them out fast, right? I think a lot of books and advice focus on speed. And I, you know, 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. 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, you know, we can send people to if they're interested. But it's this idea that all of the, let's say, you know, there's some error rate on the principles, the strategies, the tactics that I publish, right? 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 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 may be no. And 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 have an information overload 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 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 a shorter life. And that's not what I'm about to do. That's not what I'm going for. So so we need to take care of our operating system. We need to tune it and we need we 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. You know, that's awesome. But are you sleeping enough? Are you taking care of yourself? 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 I'm 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, right. Yeah. But a little bit of survival, survival or survival. Yeah. Maybe if he did not. Maybe if he slept more, he would not be successful. We don't know that. Yeah. All we have. 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 at this point in life, he does think that he should have slept more. And maybe that's a reflection that we can take home. Scott Hanselman, who is big in the C Sharp dot net world. He's his career advice is take care of your hands. Take care of your back. Take care of your 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 I talk to the people who have been in this for 20, 30, 40 years. You get a very different set of results because they care about being in the game the longest. And that's where you are achieving the most impact and being more successful. So I do. I do think about that a lot. And obviously that would apply to engineering managers to round back to your question. So. So that's so that's one part. Like. So. Just just to break it down for people. There's four parts of the operating system. You know, philosophically, there's the firmware, right? Which is you are operating for physical devices. There's your memory, right? Like, how do you store your state? There's your scheduler where 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 the 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. You know, 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 at their job. Right. They just don't feel like coding. So that is game over. Right. For your for your coding career. So you want to stay in the. In the game. You want to, you know, to to 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 a bit 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. Um. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. can work until 7 p.m. at night and check our email for the remaining time that we're awake. That's the minutiae. 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, and unlike computers, 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? Especially at that firmware layer, I think that is so often forgotten in the world of software. And so I think that's the kind of thing that we need to take a step back and remember, especially 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 with 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? Yeah, we have communication protocols with other humans. Exactly. Right. What is the networking protocol? Who's on my local area network? Anyway, 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 managers who are listening to this, and the people who have nothing to do at all with engineering right now who are listening 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 pleased to know I've been having tea while we did this. So definitely doing some developer tea. I'm going to pass you a coupon for some discounts. I love giving. Oh, wonderful. Yes. I'm giving out some like a 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 learningpublic.org slash C equals and then I'll just dev T 30. I'll type it in and you can put it in the show notes. Perfect. All right. Thank you so much for your time. Thanks, John. Thank you. Thank you. Thank you. Thank you so much for listening to today's episode of developer tea. The second part of my interview with Swix. If you missed out on that first, uh, first part of the interview, I encourage you to go back and listen to it. It'll make the second part that much better. So it says very kindly provided us with a coupon for developer tea listeners. You can get 30% off the coding career handbook by going to learn in public.org and using the promo code dev T 30. You can also find a link to this that will automatically get you a coupon. So if you're interested in learning more about 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 Thank you again to Swix 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 developertea at gmail.com. You can also reach out to me on Twitter at at developer tea or my personal Twitter at at Jay Cottrell. This episode was produced by Sarah Jackson. My name is Jonathan Cottrell. And until next time, enjoy your tea.