Shawn Swyx Wang opens up about his new book The Coding Career Handbook: Guides, Principles, Strategies, and Tactics from Code Newbie to Senior Dev. His book shines a spotlight on career patterns and practices that many had to learn the hard way — you know, up hill in the snow both ways 🧓 chantastic asks about his favorite lessons in the book but there are so many more that they don't cover. If you have an appetite for more, get your copy of The Coding Career Handbook at learninpublic.org.
We have a YouTube channel for React Podcast 🥳
Watch the livestream of this chat with Swyx and Subscribe for future chats!
Shawn Swyx Wang — Twitter, GitHub, Website
chantastic — Twitter, GitHub, Website
AWS Amplify is the fastest, easiest way to develop web and mobile apps that scale.
Get started building a React app today, check out the tutorial on AWS Amplify today, visit awsamplify.info/react.
In over your head with a React or React Native app?
Infinite Red can help.
They are React Native core contributors who've been designing, building and shipping apps for over 10 years.
Learn more at reactpodcast.infinite.red.
Please join us in donating to the Equal Justice Initiative
As an Amazon Associate I earn from qualifying Amazon purchases.
Chantastic: Swyx, welcome back to React Podcast. [laughs]
Shawn Swyx Wang: Thank you. Thanks for having me back. I think we do this once a year maybe. [laughs]
Chantastic: It was right before React Conf in 20... 19?
Shawn: '19. Yeah, and then also 2018. [laughs]
Chantastic: Was that also at React Conf?
Shawn: That was React Rally, which is community React Conf.
[laughter]
Shawn: At that time we were not sure if React Conf was even going to be held because apparently it went dead for a bit, but no, it's alive and well.
Chantastic: I'm curious if they're going to do anything online this year or if you're just going to take the path, and do it next year. Get another year out of not having official of concurrent mode.
Shawn: The time is over, though, one fun thing I do for the Reacts -- the subreddit -- is that I track anniversaries, and next week is the 3rd birthday of React 16. 26th of September...
Chantastic: Oh, wow!
Shawn: ...that's when React 16 came out, three years ago. It used to be like, "Hey, this library..." You could take it as a good thing and a bad thing. React is not progressed that much, at least not changed that much, at least since Hooks. Then also it's more of a micro-stability. Then they went out and put React 17 just to spite me...
[laughter]
Shawn: ...so I can't say that anymore.
[laughter]
Shawn: I suspect they're going to drop it on the 3rd birthday, just to go like...
Chantastic: [laughs] .
Shawn ...let's not take this too long. It's pretty funny because Sebastian has gone on the record saying that they need to break things faster. This last stretch for concurrent mode has been pretty challenging one, so I don't blame them. I got more better things to do than bump numbers, so...
Chantastic: Yeah. I tend to agree with that. I think that a lot of people who [laughs] are invested in React and are just popping-up to complain about how hard it is to keep up with new features, would prefer some of these big headline features be tied to major versions of React.
I do hope that they start to break things more and get closer to the vision that I know they all want, which is something that is a little bit more through and through connected to their vision, instead of supporting all of these legacy concepts.
Shawn: Yeah, I would encourage anyone who is interested in front-end and then in general to check into the CSS4 debate. It's pretty interesting because it's a completely artificial version number that they're going to throw on top of CSS, just as a marketing tactic, but version numbers matter in terms of communicating for progress. I think that's what they're trying to go for.
Chantastic: Interesting. Where would, if anyone was interested, where would they check out the debate around CSS4?
Shawn: CSS-Tricks. I think they have CSS4.
Chantastic: OK. All right, cool.
Shawn: It kind of summarizes the state of the debate.
Chantastic: Yeah, it's super fascinating. There is something important and I think we forget about this from an engineering standpoint. We think about numbers very literally, like is this just a patch? Is it a minor? Are we adding a feature? Is it a major?
We forget that humans love flags. We love to have something that we can rally under and be like, "I'm on version x of this thing." Everybody knows that version x is the encapsulation of these five flagship features.
There is something very human about acknowledging like, "Hey, maybe there isn't technically a breaking change, but there is a breaking mental model," or like "We're investing in a different way of thinking about this thing." The best practices have changed, and that is enough to say this is a new thing.
Shawn: Yeah, I think Dan Abramov is pretty animated whenever he talks about Semver as a social contract.
Chantastic: [laughs]
Shawn: I basically just parrot him every time this topic comes up.
Chantastic: What is that?
Shawn: It's a social contract because Semver, people get really upset when you break stuff. You call it a minor when they think it should be a major or whatever. Really, Semver is as specific as what is this piece of software supposed to do.
Given enough users and enough scale, all software is underspecified. Therefore, we don't really know what it's supposed to do. Therefore, Semver is just a communication between [inaudible 4:43] and users.
Chantastic: Yeah. It's not a legal contract. You've been busy at work and I'm just going to make a hard switch. We could talk about React all today, but that's not why we're here.
[laughter]
Chantastic: I'm really excited about the work that you've been doing because it actually transcends some of the reasons that we usually get together, which is to talk about technical stuff. You're talking about how people actually make a career around coding.
All of the things they would need to know, all of the avenues in which they could take to get there, what it looks like in different styles of work and different technologies, and how to choose stuff.
I want to ask you. For anyone who's not familiar with it already, tell me a little bit about the "Coding Career Handbook" and what it has meant to you over the last years specifically but maybe even three years before that.
Shawn: Thanks for giving me the opportunity to talk about it, because it's really awkward to pitch my own career advice.
[laughter]
Shawn: It's better to have someone to talk it through with. It's also weird to talk about it given that everyone knows that I haven't been in the software industry that long. I've objectively done well, but there's still a lot of stuff that I don't know. It's a very weird thing to write.
The main reason I wrote it was, A, the "Learn in Public" essay that everyone knows me for is objectively the most impactful piece of writing I've ever done. When I thought about like, "What else do I have to say about this idea?"
There's a lot that goes beyond just learning in public. That is the more interesting stuff that I always want to talk about. The more you get familiar with programming, with frameworks, with libraries, with languages, you realize that what probably matters on a longer-term basis is meta-skills, the skills around the coding.
I got this phrase from Charity Majors. She says, "The coding is always the easiest part of the coding career." Charity Majors is the CTO of Honeycomb. She used to work at Facebook and was early employee at Parse.
Another founding ingredient for why I was like, "OK, this is a project that I should work on," was I did a survey of every public engineering career ladder. Time to time, some companies publish what they use to evaluate their own engineers and promote.
I have a list of 30-ish engineering career letters. Actually, not that many. There should be more. Anyway, this is not confidential. We should normalize making it public. Anyway, I studied all of them. I realized that the way that people evaluate their software engineers, especially the more senior you get, only about one in four, the criteria or technical in terms of your competency, leadership.
Everything else is about working well with teammates, having business impact, understanding the bigger picture. Quite frankly, 75 percent of what you're evaluated on as a software engineer is nothing to do with code.
[laughter]
Shawn: You have to have technical knowledge, but then you have to apply it to your organization, your team, and maybe at the more senior level, your industry. That's an interesting insight. At the end of the day, we are code-enabled humans. We try to apply that to other stuff.
It's that realization. Then there's the question of, "Why now?" You know what I mean? It was an observation that...I had two months off between leaving Netlify and joining AWS, where I am right now. This is the only time that I will ever write a book like this.
Mostly it's focused at this idea of, "Let's target this junior-to-senior transition and try to nail everything that people should have this understanding of as they transition from junior to senior." The reason that there aren't as many books that exist in this process is that people don't stop to write books about it. [laughs]
There's a lot of books about technical interviews and cracking the coding interview and all that. You get the interview. You're starting off, and then there's a void.
[laughter]
Shawn: Then you get senior architects writing about -- I don't know -- clean code and whatever. There's no in-the-middle books to help you make that transition. That's really strange, so I thought I'd just give it a go. This is the first version of it. I just put it out this year.
My intention is to refine it every year. I know it's not as good as it could be, but with the help of now over 1,000 readers that I have, try to make it better every year. Maybe it's not the best book for juniors and seniors this year, but in 10 years, it could be.
I'm trying to live that whole philosophy that I'm describing, which is you will never be perfect on day one, but you just make a small step, and then you keep pushing the boundaries as you go along.
Chantastic: I love it. Something that has always struck me about this notion of learning in public is, speaking personally, antithetical to the way that I live. I am one of those people who just want to, get it all polished, get it all nice. Then have this thing wrapped up in a bow and, put it out there.
That is an old way of thinking about things because the way that you think about stuff is so well suited for right now. Where people want to. You've mentioned that you feel a little bit nervous, I guess, about being the person who's writing this book. About the junior to senior transition, because this isn't a story that happened, like 15 or 20 years ago.
It happened relatively recently. Embodying that philosophy people, get to see that, this is real. This isn't something that you've rewritten in your head to sound better than it is over the past 10 years. It's fresh because they saw it happen.
They saw what things look like a year ago, six months before that. Seeing that progression, people seem to be invested in...They have peace in your success, and know that it could also work for them as well. Have you seen that in the people who have enjoyed your book? That they've actually enjoyed seeing the progression of you, over these years?
Shawn: Definitely, there is staff and principal and CTO level people who have bought the book and told me that they enjoyed it, regardless. It's pretty, I guess rewarding to hear from them. I also don't care about external validation.
Chantastic: [laughs]
Shawn: If this is true, then it's true. It does not matter who says it? [laughs]
Chantastic: We wanted to have this comfort of, there's some credibility behind what the person saying. Ultimately, it doesn't matter. It just matters if it's right or not and if it's useful to you. It's good to have some, but I'm sure, I also have people who don't think I'm qualified to write a book.
That's fine. They're entitled to their opinion. I'm entitled to also publish and try my best to articulate what I think is true. Everyone should. If you don't agree with a single word, you should still write your own set of principles. That is just regardless of what seniority level you are.
That's true. I also want to push back on that idea of how not learning in public is maybe old, there are different levels of learning in public. I definitely don't. I always make the point to say that learning in public is not for everyone.
Chantastic: [laughs]
Shawn: There are different degrees of learning in public. Even when I am a principal advocate of this thing. I don't think you should live the majority of your life in public like. I'm just saying, go from zero percent public to, 1 to 5 to 10 percent.
Even that is a big lift for people. I'm trying to wake people up to the idea that your default has been zero, and it doesn't serve you well.
Chantastic: That's it. That's interesting. I can definitely latch on to that. I mean, just recently, we've been trying to do something a little bit different, where we put live streams on these conversations to YouTube, we're doing that right now.
That has been my turning the dial-up from totally private, I have control over, exactly how I am perceived if I stutter over a question or whatever, it's under my control, I can cut it out and try again, no big deal. Nobody knows any better.
That is in a way just turning the dial-up from zero to one. It's OK, well, it was all private before, we're just going to expose a little bit of this and see how it goes.
Shawn: Honestly, if you speak at all, I think you're already like way more public than most.
[laughter]
Shawn: I also think that at some level of audience reach with the great audience comes great responsibility. You do owe it to your audience to moderate how much you put out there that's totally raw and unverified and unchecked.
You do need some polish it on some scale, but it's probably a lot bigger than people think. People think that 20 thousand Twitter followers is big. It's not. It's nothing.
Chantastic: Especially since they're only seeing a subset of your tweets anyway, like on a given credit. [laughs]
Shawn: You should always be on the edge of what you're comfortable with, and just pushing that. Definitely, I'm not saying you publish everything sort of half done, super low quality. I definitely don't want to be the cheerleader, that either. I do encourage polish.
I'm trying to correct for the default and the default private. That's all. Do you know what I mean? Of course, try to polish things if you can. [laughs]
Chantastic: That's a really good distinction. It's not that you are trying to put misinformation out or bad quality work. It's just that like when you learn something, don't be afraid to share it. You don't have to be an expert before you start sharing things.
Now, I'm curious. You mentioned that people have responded, what right do you have to write a book? That seems odd to me, because effectively you're writing a manuscript, and distributing it for people who want to buy it.
What is it that you think that people I guess, have in their mind, that makes this some type of sacred ground that is only available to elites?
Shawn: It's a fixed mindset. Essentially, in their minds, there can only be, I don't know, five books in the world about computer coding careers, and they should be written by Linus Torvalds, Jeff Dean, people who've had six decades of making it in life. The funny thing is, these guys are not interested in writing career advice books, you know what I mean?
[laughter]
Shawn: One thing is the fixed versus growth mindset. When I launched, I launched on Hacker News, and I got to page one. It did well for what it was, which is sure a pretty expensive book.
What I hear when people comment on these things, is that they're just not my target audience. I don't pay them any mind. That people who are creators, like you are a creator, so everyone every podcaster, to explain this to don't, doesn't really get it, because you're sympathetic to the idea of what it's like to create.
There are people who don't create, look in the comments, and then they tell you that they're not your target audience. I just don't pay them any mind their opinions. Good for them, but they don't have to affect me.
Chantastic: I asked because I know that this is probably one of the biggest reasons that people hate learning in public is because especially for the type of work is represented by coding. When you learn in public, you open yourself up to criticism from this whole class of classic programmers maybe, [laughs] who are really just constantly judging your credibility or ability to be sharing something.
It feels like you're living this thing that you're recommending to people. What are some tactics that you employ for not taking it too personally and continuing to create and publish anyway?
Shawn: It bothers me. I read it, it does get me down, it does get my feelings. I have a chapter on, I have a section on my book called "Dealing with Haters," and this one comes from Paul Graham who founded Hacker News, so he knows a thing or two about dealing with disagreeable comments.
You just remember that there's this hierarchy of how people engage with arguments. At the basis level, there's name-calling, an ad hominem. I'll attack your character instead of attacking your point. Then, there's responding to tone. I don't like the tone of your thing instead of the fundamental point that you're making is wrong.
It goes all the way up to refuting the central point. What level of disagreement are people engaging you with? If they're just attacking your character, your backgrounds and not really disagreeing with your point, then that's the level that they're choosing to engage with. You don't have to respond to anything on that level. You can just choose to be better.
Chantastic: It's an interesting tactic. You can look at that chart, and we'll find a link to that chart.
[crosstalk]
Shawn: It's just triangle.
Chantastic: ...triangle and basically decide at which point you want to engage with people and just disregard. [laughs]
Shawn: Just have a filter, right?
Chantastic: Yeah.
Shawn: Not everyone's opinion is equal.
Chantastic: Now, I want to go back to something that you'd mentioned. This ties into the necessity for a book like this that talks about that junior to senior transition, is that most of what differentiates a junior from a senior is not raw coding talent.
I want to press into that, because I think that might be one of the most important things that we covered today. What are those things? [laughs] If it's not coding talent, obviously, there's a certain level of cost of entry.
You have to be good enough at coding to be able to progress, but it sounds like you're saying there is a point where you're good enough, and then it's these extra qualities that take you up to the ladder.
Shawn: The point at which you're good enough is essentially can you be assigned a task and independently execute without supervision. That's the bar that a lot of people stop at, for what is a senior engineer. It's a pretty good bar.
It means that the buck stops with you. I can hand you a [inaudible 20:45] ticket, a project, whatever, and trust that you'll take it from beginning to end. If there's something that's a deal breaker and a blocker, you will throw the exception instead of suppressing the exception.
I think that's a pretty good contract to have with your senior engineers, but then there's also a lot of I guess non-technical bars. That's what I discuss in the junior and senior section.
For example, one of the other discussions with senior engineers is that they're multipliers for the rest of their team. They help to train other engineers. They help to work on infrastructure that, I guess, enforces code standards or builds the architecture that sort of prevents a lot of technical debt in future.
They know how to migrate between legacy and systems and new solutions that they're trying to adopt. Those are all very desirable qualities of a senior engineer as well. In the book, I actually kind of break it down to four broad topics. It's kind of like code, there's code level stuff.
There's learning how seniors learn versus how juniors learn. How juniors behave so behavior and then the last part is how they impact their team. Code learning behavior and team and I have any number of comments on each of those sections, but I just wanted to keep it high level.
Chantastic: [laughs] Yeah, absolutely. Something that I find interesting that you mentioned, and I think I have been just processing this a lot over the last couple of years is something you specifically mentioned about the ability to migrate from legacy tech to new tech and I think that we see this a lot.
There are a lot of tools out there now that kind of automate code standards, with the goal, I guess, of communication and participation and making things better, but a lot of times they create arguments or artificially restrict what you're able to do.
It sounds to me like something that you learn along the way in this transition is kind of the nuances of those things like when it could be a good time to implement something like this. The nuance of like, "You know what? Hey, we're excited about Technology X," but how do we get there?
Not just like, "Hey, why don't we rewrite everything?" There's a respect for how hard it is to have done the thing in the first place. Could you talk to me a little bit more about that migration mindset and sustainability, and how that plays into the senior role?
Shawn: I'm not sure who wrote this. I'm going to kick myself once I remember. [laughs] Someone made the analogy of engineers to architects. We like to bulldoze everything from scratch, and then just build from scratch.
It's pretty apps. Whenever we see technical debt, we hate it. It's like, "Oh, this is using React and Mixins." Those aren't cool anymore. Render props, those aren't cool anymore. Let's take a cycle, and refactor this whole thing. It takes some level of maturity.
Chantastic: I'm in apps that are using [inaudible 24:04] .
[laughter]
Shawn: It takes some level of maturity to say, "No, yes, this is a pain and we have to deal with it, but that's not so important right now. This is." It takes some judgment to make that call, but then also sometimes to make the opposite call and go like, "Yes. OK, it's gotten to a point where this is actively slowing us down, and if we slow down, we can speed up later."
That is a conversation that needs to happen. As senior engineer, you're not the only stakeholder in this. You have to be able to sell this to products people, to your CEO, to marketing people who don't care about your tech stack, [laughs] who don't care [inaudible 24:48] . It's a lot about persuasion as well.
Once you've even got the internal buy-in among your engineering team, and that's hard enough, because a lot of engineers love to bake shit. That's a very high-level view of like, "Sure, what that looks like." I also talk about some migration strategies.
I like something that they do at Uber and Facebook, which is extensive use of feature flags instead of long-lived branches. I like that idea as well. It seems the industry is slowly moving in that direction. In other words, feature flags as a way to test in production, to migrate everything in a single codebase.
Then eventually delete without much disruptive change. It works until the point where feature flags become technical debt themselves, instead of a means that they're a technical debt. Uber wrote a tool to automatically scan through. They had 7,000 feature flags, and then they scan the code base, and then they were like, "OK, 2,000 of these are not in use anymore, we should delete them."
[laughter]
Shawn: Solutions can work at a certain scale. Then once you get past in order to of magnitude, then they will stop working, because they weren't designed for that solution. Then you need to know that you need to change solutions at that point in time.
Chantastic: I like how you touch on the importance of persuasion, which is basically internal sales and marketing, and how critical that is to demonstrating ownership over something like taking ownership of the thing, and demonstrating that you can take it from this point to the next point, whether that be a full roundup rewrite, or some long-lived migration strategy.
How do you see people demonstrating persuasion in these four groups that you've talked about like code, learning behavior, and team?
Shawn: That's a tricky one. I was thinking more about migrations and technical debt in general. These are where I notice the biggest differences between junior and senior are and in my attempts to condense and summarize multi-dimensional thing into four.
Those are what I landed on. I don't have a strong view on how persuasion applies to each of these things. That's [laughs] something I have to think about for sure.
[crosstalk]
Shawn: I'm just going to take a pass on that. [laughs]
Chantastic: Totally. It's a weird question. It's something that I'm maybe independently interested in, but I do want to tie in some of these ideas, behavior. That's a big thing and I think we did touched on that in the way you think, the way that you decide to rule out a decision, how easy you think it is to maybe theoretically rule out [laughs] some type of thing.
How do you think about hit behavior as representing you and being able to take...be a vehicle for taking your career up the ladder?
Shawn: People remember what you do and talk as cheap at is definitely more about what you do than anything else. I dual view it as doing anything in order to be perceived as doing the thing is very performative.
You should just do it because it's the right thing for you at that point in time. That's how I approached this thing. Honestly, instead of trying to look good just do the right things and hopefully you'll end up looking good more often than it doesn't look good.
I think that's much better than trying to skip to the end result of looking good [laughs] in the end results. That's why I try to talk about things. The other thing I also like to push back on is a lot of people, when they're asked what's the difference between junior and senior, junior, they always cast the juniors as the bad engineer and the seniors as the good engineer.
I try to push back on that because probably the only reason of definitive difference between junior and seniors is the pay skill. On everything else you can have multiple dimensions and you can be more junior on things and more senior on other things.
I definitely want to push back on this artificial divide that I've hooked onto for marketing purposes to not actually internalized it too much because that creates these artificial mentality of either A, I'm a junior therefore, I suck at everything or B, I'm a senior now, I have nothing to learn from juniors. That could not be further from the truth.
One of the things that I really like to talk about as well is, I'll pick one on the behaviors. When evaluating technologies, juniors will typically look at the developer experience based on they're getting started. Look at this awesome talk, look at this getting started, look at this hello world. Look at the other people who use it. That's great.
Whereas, the senior engineers might look for...They've seen a lot of this and they've seen a lot of it not worked out. They look for hidden cause in terms of user experience and extraction leaks. All of the extraction leaky like, "Where does this hurt me?" A lot of times their first question will be like, "This all sounds great, but what's the catch?"
If you don't get a very convincing answer as a catch, they know that you're trying to bullshit them. It's very, very rare that you have a complete free launched in tech. It happens, but it's super rare. You also start to care about user experience more than just the developer experience.
As a beginner, I know that the first thing for me was to get up and running the fastest with the React App whereas, the senior engineer will be, "OK, wait, hold on. My bundles are just two megabytes right now. What are we doing here?"
We get that, especially the other day we just had one of these discussions in the React Reddit and it's healthy for both these things to exists because when you're trying to get going, you try to get going. You should not have that many concerns handed to you at that point of time.
That's one example of how I think behavior has changed as you grow in capacity, as you start to have a little bit more of personal experience.
Chantastic: Interesting. Sorry, I totally didn't understand that framing of it until you describe it to me. I probably should start asking question...
Shawn: No, it's cool.
Chantastic: ...until I know [laughs] a little bit of that framing a little better. I do think that that's really interesting. I'm curious you had mentioned that in a lot cases the differences between junior and senior are multidimensional and it's really hard to say.
Apart from trying to help people develop their skills in this dimensions to say like, "Oh, these are the strict characteristics of someone who's starting, and the strict characteristics of someone who's further along."
I'm curious in an ideal world, how would you see it like describe or how would we live in a way where we're able to pull, draw from the benefits of someone who is new to the career but then also draw from the benefits of someone who has had that experience. What are those communications look like, I guess, in ideal world?
Shawn: First of all, I think as an industry we need to have a lot more apprenticeships. It's ridiculous that we have this gap between, "OK, you just graduated from boot camp or college and we'll immediately hire you as a full-time engineer."
A lot of people can do that and a lot of people cannot. They spend a lot of time trying to find their way, but then also getting to jobs that may not be that good for them. Having an immediate path of normalizing apprenticeships in tech would be a good idea to build that bridge.
The other thing that I also think about when you asked about this stuff is sort of these stupid questions saved Harper, which I know in the prep they like to talked about. I borrowed this concept from acting where if you know that you have known flaw you just called it out and say that, "I know I'm about to say stupid, but..."
Then you just say your stupid thing. Most likely, you're not the only one thinking that, or you're not the only one with that same question. You also communicate that like, "Yes, I understand in some level this is a confession of weakness."
Being able to embrace that weakness owns that. It also puts the ball in other persons court. If you're [inaudible 33:57] of saying this to my senior person, now the senior person is challenge to explain this to you and if they can't do it, it's their fault not yours.
Because senior developers should be able to explain complex things in simple fashion, otherwise, they don't understand what you're talking about. A lot of people cannot. I think that stupid question save harper is the idea that you can invoke it, just lampshade it. That's one of the tactics that I talked about in the book as well.
Chantastic: I can say one of my favorite piece of advice that you gave on this show, I think the first time you're on, we talked about that a little bit before we hit record was you're going to say it better than me. Being able to sacrifice your ego for learning. What's your quote on that?
Shawn: You can learn so much in the Internet for the low, low price of your ego.
Chantastic: It goes both ways, right? If you're that junior talking to a senior and you're feeling insecure, leading with that insecurity and being like, "Let's back up a second I don't actually know what we're talking about and would it be weird to talk about like this and starting the dialogue from that angle?"
Then also, from that senior side saying like, "Hey, I actually am not totally sure that I know all of the places that we're using this thing and how it's being used? The places we need to extend it and whatnot. Instead of just telling you how to do something, I'd love to learn from you on how this thing is being used. [laughs]
Shawn: That's totally valuable as well. Enable all forms of communication, not just junior to senior but just like it -- programmers do a lot of things to avoid talking to other humans.
[laughter]
Chantastic: If we talk some more, we will be able to facilitate knowledge transfer but then also be on the same page before we start committing code because that will save a lot of more code in the future, undoing the misunderstandings that we have. It's hard, especially as we go remote there's a lot less opportunities for communication and agreements.
Especially, the body language but then also in just opportunities to hash out stuff, so we should. I try to encourage this as well like, "Dude, do more writing just in general when in doubt, just write stuff down." Send it to people, skills yourself and also notes down your questions for future you but also future other readers as well.
Something I appreciate at Amazon is that there is a very strong emphasis on writing, to the point that we ban PowerPoint in internal meetings. Write the memo, try to explain and give narrative context to everything, and I think that's important.
Chantastic: One thing that I really love about your writing in general, but then also in this book, is that it's a tremendous resource to other resources. [laughs] There's a lot of quotes, there's a lot of references, there's a huge bibliography of resources that you have gained wisdom from kind of consolidated into this book.
I want to talk about like that process, being someone who has learned publicly, how important is it to piggyback off of the work that other people are doing, or more importantly spotlighted as you're learning from them?
Shawn: Part of it is attribution like this wasn't my idea.
Chantastic: [laughs]
Shawn: I should quote the original source because thank you for coming up with it. Also part of it is a strategy for dealing with my own imposter syndrome because you don't have to believe me, you can believe this other super experienced person. Then I can sort of step back and be like, I'm the curator.
I kind of put everything in context so I give you some nice intro to link ideas together. Even there it's like a value add that I think that people really appreciate. It's probably consistently shouted out as one of the biggest surprises about the book because I don't talk about in the learning page, so I should probably do that.
[laughter]
Shawn: I'm terrible at this. This is my first time selling something like this. Anyway, I think the other thing is also understanding that there is a rich history to a lot of these ideas. It's not just one person talking. It's definitely a crowd of very experienced people who all have converged on similar ideas.
To me, that means that they're not likely to change and I really love investing in things that don't change. It is much better than...People always want to know what could be different in 5 to 10 years.
The Jeff Bezos' line is like I would much rather invest in things that don't change because then I can just throw like there's no possibility of over-investing. You would just be early instead of wrong.
I think that's an interesting insight as well in terms of, in the battlefield of ideas, these are the things that have seemed to have stood the test of time, which I have picked up the term Lindy effect, which is the expectation that things that have lasted for a while will tend to last a bit longer just as statistical estimator of their longevity.
Those are things that I really like to think about and I really like how you linked it to pick up what they put down because I didn't really think about it in that way in terms of borrowing credibility, but it is.
When you're getting started as a blogger, one of the most high leverage things you can do is that you can summarize the key books in your chosen field. Every book, every industry has their Bible, their equivalent of like the books that everyone should read, but doesn't.
In general, people don't read it through. What you can do as a beginning blogger is to read the whole thing through. You not only have a much better retention of that source content material is, you also get to build your audience.
Nobody has to care about who you are. They just have to...They know that the book is already important and good. You're just helping them get there. As of voice, if you do the job of it, then you get to start to build your own name as someone with taste and someone with the ability to make things relevant for people.
Yeah, but then the pick up where you put down idea, which is one of the principles and as probably one of the most highly referenced principles after [inaudible 40:32] public, is this idea that you should actively engage with the mentors.
A lot of people, I think they say that, "I'm looking for mentors," or like they set out these platforms where you can apply for mentor and mentee matching. It's a job that is very ill defined. Of course, it's unpaid, but it's just ill defined. That's the real problem with it.
There's no contracts where...Is the mentor supposed to come up with some sage life advice that you could go apply and that'll just fix your whole career? No, we all know a little bit of things and we all have some measure of self-interest.
Yes, I want my mentees to succeed, but I'm also not responsible for all that they do and all that they're interested in. I think it's better to just engage with individual mentors on a one-by-one, project-by-project basis.
If it ends up that you keep working with them, then you work your way into being a mentor, a mentee relationship, rather than, "Hey, will you sign this?" unenforceable contract on day one and then we'll go to work together. I don't think that's the way two sovereign individuals should work together.
I want to close it by talking about this idea, what is the number one reason that people stop blogging, they stop learning in public? Is because they don't receive feedback. You should not care about feedback in theory, but we're all humans I care about feedback.
When are you guaranteed feedback? Is when you respond to something that someone else already did. As a whole, people don't respond in general. This is called the 99 percent rule. Most people lurk and consume passively. If you engage with anyone at all, you're likely to get a response, because that's the contract for what people put out.
People recognize when you come back repeatedly, as someone with quality. Someone puts out a blog post, you go through it and give comments. If someone puts out a new library, you actually try it out, and you report bugs, so on and so forth.
The more you engage, the more you become a collaborator, you become a friend, you become a peer eventually. This is a very, very consistent, and fast method of leveling up.
Chantastic: Yeah, I want to dive into the practicals of that, because I think that can't be overstated for people who want to level up and learn from people but can't actually get time with them. If you hit some of them be like, "Hey, I just want an hour of your time for you to mentor me." It's never going to happen.
Shawn: It's too generic.
Chantastic: [laughs] Yeah, but...
Shawn: Tim Ferriss has this saying, which I really like, which is, "The world punishes the general wish and rewards the specific ask." If you're like, make my life better, make me a better developer. No one has any idea.
If you have a specific thing that you want to work on and get better, I will have a lot of suggestions for you. Do you know what I mean? Don't ask me to do that work for you of defining what you want to get better at. Figure it out for yourself and then engage with the experts.
Chantastic: It's interesting. In a practical way, what'll this look like? Will this look like commenting on other people's content that they've put out there, giving feedback on stuff that's like on "Hacker News" or "Product Hunts"? Like you mentioned, giving feedback on PRs investing in open source, taking on a feature.
Shawn: Yeah, keep going. Lee [inaudible 44:06] , who's one of the committee members. He literally became a svelte maintainer by going through the codebases vault and seeing that there are a lot of to-dos. He followed up in the to-do's and sending PRs, and they made him in maintainer.
Yeah, read through source code, actually, try out stuff that people launch. There's bound to be bugs, there's bound to be stuff that you don't really get. You have the benefit of saying, "I'm a beginner, so I give you the beginner's perspective on this."
Of course, they want to improve it and make it more accessible to people who are not experts, because these people are experts and that's the one thing that they don't have, which is the beginner's mind.
Probably the easiest one that most people can do is summarize, like restate, reframe. Talks, podcast, books, blog posts, these are the main media formats. In which if you see anything good, don't stick it in your memory and try to hang on to it.
You're going to forget most of it and you're going to miss out on the chance to tell people about it. You're also going to miss out on the chance to engage with the person who connected to it.
It's pretty funny. If you actually randomly email the authors of your favorite books, they're likely to respond because most people don't do it. It's just a hack. People don't do this enough, so I can just continually recommend it and less than a percent of people who actually even hear this advice will even follow up on it.
I'm even comfortable giving out my email address. I put it on my Twitter. I get may be three emails a week on these things and yeah, people don't follow up.
If you are sold on this advice and you think that it works or if you want to try and see whether it works, there are a bunch of people trying this out now and seeing for themselves. I don't have to prove it anymore.
[laughter]
Shawn: It's a good idea. Partially, part of that summarizing thing again falls back to that borrowing credibility thing. One way to level up is to have a nose for really good stuff and summarize it, and internalize it.
I'm really keen on this idea of Big L. You know how in algorithms, we have Big O? How it something scales together with the amount of units or time or space, or whatever. Big L is this idea that people can scale linearly, sub-linearly, or super-linearly with their number of years of experience.
How do you change the curve of what you learn? It's doing stuff like this. Engaging in a higher level, engaging in a network and be more reflective on what you learn. Obviously, there's a blog post up about Big L and he's a rapper that, apparently, a lot of people like. I don't know anything about that.
[laughter]
Shawn: Big L notation for your career, for your learning, it's a very good structural thing to think about as you learn because a lot of people don't really think about how they learn as they learn.
Chantastic: I love that. When I look back, I feel like even this podcast is a way of doing exactly what you said. Borrowing credibility and picking up what others put down, and understanding a little bit more than what's on the marketing sheet of a thing. I think that there's so many avenues for people to do that.
You don't have to come up with some original thought to start blogging and writing. You can talk about stuff that other people have talked about. Add a paragraph that makes it make sense to you or a drawing or whatever, and then link to the doc that you read to actually learn that thing.
That can be so powerful and the audiences for those kinds of things can be -- depending on how you do it -- really big. Like comics, right? We see this a lot. Comics explode from Web developers. People love seeing comics of code and mental models and whatnot.
Shawn: Julia Evans, Lin Clark, Samantha Ming, anyone with a modicum of artistic ability, which rules me out. We're so used to dry and boring technical stuff so if you can actually make it more accessible by drawing or illustration of some sort, then you really stand out. I think that's a superpower. I'm actually keen on learning that just to try.
Sarah Vieira has been learning Blender. He talks about it in your podcast, but I'm not sure.
Chantastic: Yeah, we did.
Shawn: I can't draw, but I can probably mess around with some 3D shapes and stuff like that. Maybe that's a more interesting venue, but these are all ways to engage with your mentors. I think that, in a way, gives value back to them.
Eventually, you're going to have to strike out on your own. What you get from engaging with these mentors is understanding what do you think is important. By definition, because they're all busy, they're all experts, they have things that they don't have time to do so you can be their right hand in doing those things.
You can eventually become their peer by working on these things and up to a point where you start disagreeing with them for the right reasons. That's when you start to level up past your mentors.
Chantastic: I love this idea that you're calling these people mentors, but you don't necessarily have to have a mentor-mentee relationship with them. Mentors are a book. Listening to a podcast, reading someone's blog, these are your mentors.
Being that first person rising up as someone who appreciates that work and expands the vision of it and the communication and talking points of it, the audience of it. No one's going to hate you, no creator's going to hate you for that. [laughs]
Shawn: A lot of them probably rose up the same way. It's almost like this is the hidden rules of the game that nobody writes down, and I went and wrote it down. Even then, people don't...Part of this is my fault, but people insist on proceeding the way that they're taught.
I think a lot of it has to do with formal schooling. During formal schooling, we're given a path to succeed and it's a very straight and narrow path. In the real world, it's very different especially in the rather more egalitarian, open-source public sphere. It's a very different world from when we're in schools and "on rails."
Chantastic: [laughs] "On rails," I like that. We're blowing through time today.
Shawn: I'm sorry. [laughs]
Chantastic: No. I love talking with you. If we weren't trying to respect people's time...I was going to say "commute," but nobody has a commute anymore.
Shawn: I know. Apparently, podcasts have taken a dive in interest of general listeners.
Chantastic: Huge dive. I can very much validate that, yes, just nosedive. The commutes are very critical to maintaining a podcast audience. [laughs] As we get to the end of this thing, I want to talk about an analogy that you've made, the operating system of you, taking something that we understand -- coding, operating systems, firmware, kernels -- and mapping that over to the human.
It feels like maybe we should already be thinking about the human first, but I think as engineers, we like to think that we're all brain and whatnot. I love the way that you've mapped this back to the technical back to the human. Tell me about that concept, where it came from, and what the core philosophies of it are.
Shawn: This is the chapter. This is the end where I realize that if I don't write this, everything else preceding it doesn't make sense. That's what makes it a natural ending chapter.
It's this idea that what if I just handed to you, on a silver platter, the best talks in the world, the best books in the world, the best courses, the best advice in the world, objectively, from God [laughs] and gave it to you and put it in front of you and said, "These are all the proof." Would you be able to put that and make use of that in your own life?
A lot of people would not. That's a result of not having a system to process and incorporate these decisions and changes in their own lives. I think about it in that sense. We as people operate as an interface between the hardware, which is our bodies, and then our software, which is...
It's not even our software, it's the applications of our software, of our bodies, towards a job, towards a career, towards being a human which is how I pair tactics for a job, strategies for career, principles for being human.
The tricky part is to define the operating system on which all these applications run. When I dig down to the deepest, deepest habits that people like Scott Hanselman who's going to developer for 40 years, when they talk about having a long-lived career, they don't talk about picking what to put down or learning public that can push it. They are like, "Take care of your back and your hands."
[laughter]
Shawn: Really core stuff. I link to his blog posts. Bill Gates talks about how to advise that stands the test the time. He's like, "Sleep more." Like, "Shit like that."
[laughter]
Shawn: You know what I mean? Take care of your body because we like to pretend that we we're all the virtualized people, but we're not. We have bodies attached to us. I also like this analogy, because I think that there's a lot of domains in which in computing, we've learned to do things better than in terms of in dealing with humans.
What is an operating system? It's a way for us to manage limited physical resources, and then run applications and share resources on top of it. That's a lot of what we're trying to do as humans as well.
We have limited time. We have limited physical bodies and stuff like that. Then we try to run as much as possible that get as much performance out of our hardware as possible. We invest so much time at the application layer, we should maybe invest a little bit more time on the operating system layer as well. I wanted to make a case for that.
If I ever write a sequel to this book, it probably be that this chapter extended into book form. I've already given a couple talks about it. It's an idea that's spreading because the analogy is something that we all understand. We have different levels of storage.
Unfortunately, in our heads, the only forms of storage available to us is RAM. Basically, it's very lousy. It could you can even call it maybe like l one l two l three cache, basically, there's different levels of storage and we only have one available to us naturally. We should extend it by working with external storage devices like writing stuff down.
If you can derive so much of the principles from these fundamental like, "What are the limitations of our hardware? How do we exceed those limitations?" I can go further like, "What about our environment that's around us?" Temperature control is something that matters as much for CPU as for humans and oxygen control.
I even go into things like being able to virtualize other people. When we code, we can actually code a lot better sometimes if we're able to virtualize what other people are...test our code against our model of how other people behave. The pre-emptive code review is another interesting idea that falls out of this model. There's all these ideas.
Scheduling is another one that I'm pretty passionate about, because I'm not very good at it. [laughs] I put it as the final chapters. I was like, "I'm least qualified to talk about it." Like, "Do you drop tasks? Do you have a problem prioritizing low urgency, high important things in your life?"
That's a lot of where we get screwed up because a lot of times we prioritize notification bells, and thing and DMs and stuff like that, which really don't matter.
Chantastic: I'll do the important work after I get to inbox zero. It's like, "Just unsubscribe from all that shit and move on with your life." [laughs]
Shawn: There's just a system to triage and manage and batch. I talked about all of that in these ideas. Something I got from Sarah Drasner is this batching idea. Then the last one that I leave all the way to the end. You can strip up. These are all extraneous stuff. It's nice to have operating systems.
At the core of what operating system is, is the kernel, the process that drives all the other processes. If you lose that, which for humans, it's motivation. We call this drive, I used to [inaudible 57:38] . If you lose your drive to code, you will stop coding.
We see that so often in tech. I put up a couple of examples on Hacker News, where they're like, "Whatever, in Google, I'm being paid hundreds of thousands of dollars, and I'm totally unmotivated and I feel like quitting and burning.
I think maintaining that drive and motivation to keep going and to have joy in your work, to understand that the code that they work on, may have a broader impact in something that you care about. I think those are really core important things to keep track on.
The last chapter is like a mixed bag of all these ideas. It's an invitation to explore more, because I definitely don't think I have the answers. We talk all the career stuff, it's cool, it's interesting, might get you more money, but ultimately you want to stay in the game and not burnout. That's something that we should all spend a little bit of time talking about.
Chantastic: Speaking of that last chapter, one of the quotes that you have in there that I'd not heard before, but is just concise is from James Clear's "Your outcomes are the lagging measure of your habits. You get what you repeat." It ties into everything that you're saying.
Even what you said at the beginning -- I don't even know if this was before or after we started -- but talking about focusing on systems over objectives, maybe?
[crosstalk]
Shawn: Goals. Systems over goals.
Chantastic: This is true. It's the building of a process, the building of you, the maintenance of your operating system is what actually takes you to distance. Not any, external thing that you..."Oh, I reached LX. I guess I'm done now."
There's always some place where you're done. If you don't have a system that actually carries you through and continues to motivate you, you're cooked. You're done. [laughs]
Shawn: You said it. James is the author of Atomic Habits, which is a lot of peoples' favorite book these days. That's a much healthier way to approach coding careers than the go-hard, go-fast non-React in 60 seconds kind of thing.
Chantastic: [laughs]
Shawn: We're in this for the long run and I think there's something I'm also increasingly interested in, which is sustainable ways to have a coding career. Rather than "Look how fast I'm rising. Look how senior I am." None of that matters. "Are you happy?" Ultimately...
Chantastic: How's your back feel?
Shawn: I actually think this is a uniquely American thing, but people are obsessed with learning how to learn. I talk a lot about that. Learning in public is better than learning private. That's great, but there will never be any end to things.
There's this unlimited number of things to learn. You'll never be done and maybe what's more important is learning how to be happy with what you already have. Nobody tells you that.
Chantastic: [laughs]
Shawn: Anything that anyone markets to you is telling you that you're not good enough. It's just giving you FOMO in some sort of way. It's hard for me to say that because I'm also trying to tell you...
[laughter]
[crosstalk]
Shawn: ...until you learn how to be good enough. It's true. I freely give this away to anyone who listened. Sometimes, you need to pay to take something more seriously.
[laughter]
Chantastic: Absolutely. This episode is jam-packed with just great advice. Tell people where they can go to get your book and...I mean, this thing is huge. It's 400-ish pages?
Shawn: 450, yeah.
Chantastic: Oh my gosh. We'd just barely scratched the surface of the topics and resources that you covered in your book. Where can people go to find more information about this book and how to learn public and do all the things that we've been talking about?
Shawn: It's at learninpublic.org, which is the domain name. It was originally called "Cracking the Coding Career" and then Gayle McDowell, who wrote "Cracking the Coding Interview", threatened legal action. I had to rename it.
[laughter]
Shawn: This "Coding Career Handbook", it's more generic. I don't love it. Anyway, I named if after the original .org. The vision is to eventually develop this into a non-profit. I've given away a quarter of the money that I've made to freeCodeCamp. So far, I've given them about $10,000. I will be giving them more.
For listeners, who made it all the way through the end, I always like to give a little something for people who follow through. People often don't follow through. I created a coupon. It's learninpublic.org/queryc=reactpod40 and I will give you 40 percent off everything.
[crosstalk]
Chantastic: We'll link that in show notes too. Should we not? Should we just leave that for the people who followed through to the end?
Shawn: It could be hard to type. It's a query param. Sometimes people get it wrong. I just leave it in the show notes. It's fine. I've done this for every podcast. People just don't get to the end sometimes. If you want to, they can take me up on that.
Chantastic: We'll link it regardless. I'm super excited to point people to your book. It's jam-packed full of really great information and very concisely-consolidated and curated information. I want to say thanks for putting it together and risking being out there, because not everybody does. I thank you for your service to the community for making this available.
Shawn: You're very kind. I very much acknowledge, this is the first book I ever wrote for money. I hope that this will be the worst version of the book.
Chantastic: [laughs]
Shawn: What I can say is, I will try to publish a new version every year and make it better, so I need your feedback. Let me know what you think. You can reach me on Twitter @swyx. The book has its own Twitter as well. It's @Coding_Career.
Chantastic: Awesome. Go out. Check it out. Thanks, everybody, for listening. Thanks, Swyx for being here.
Shawn: Thanks for having me.