newline

Coding Career Handbook with Shawn Wang

Episode Summary

Today we're talking with Shawn Wang, a senior developer advocate at Amazon Web Services. Shawn is a prolific writer- you should totally check out his blog, if you haven't already. and most recently has written a book about the non-coding parts of your coding career. Shawn used to work at a hedge fund until transitioning to tech, and this gives him a unique perspective on how to be effective in your job - and why you should take ownership of your whole career. In this wide-ranging conversation we talk about the differences between a Jr and Sr engineers, how to find strength in your weaknesses, and how to capture your daily ideas and use them to supercharge your career. I think developers at any level will get a tons of value from this conversation.

Episode Notes

Resources:

Today we're talking with Shawn Wang, a senior developer advocate at Amazon Web Services. 

Shawn is a prolific writer- you should totally check out his blog, if you haven't already. and most recently has written a book about the non-coding parts of your coding career.

Shawn used to work at a hedge fund until transitioning to tech, and this gives him a unique perspective on how to be effective in your job - and why you should take ownership of your whole career.

In this wide-ranging conversation we talk about the differences between a Jr and Sr engineers, how to find strength in your weaknesses, and how to capture your daily ideas and use them to supercharge your career.

I think developers at any level will get a tons of value from this conversation, let's dive in.

Episode Transcription

EPISODE 08

[INTRODUCTION]

[0:00:06] AW: Welcome to the Newline Podcast. 

[0:00:08] NM: Our show is a conversation with experienced software engineers where we discuss new technology, career advice, and help you be amazing at work. I’m Nate Murray. 

[0:00:17] AW: And I’m Amelia Wattenberger. Today, we’re talking with Shawn Wang, a Senior Developer Advocate at Amazon Web Services. Shawn is a prolific writer. You should totally check out this blog if you haven't already and most recently has written a book about the non-coding parts of your coding career. Shawn used to work at a hedge fund until transitioning to tech, and this gives him a really unique perspective on how to be effective in your job and why you should take ownership of your whole career.

In this wide-ranging conversation, we talk about the differences between a junior and a senior engineer, how to find strength in your weaknesses, and how to capture your daily ideas and use them to supercharge your career. I think developers at any level will get a ton of value from this conversation, so let’s dive in. 

[INTERVIEW]

[0:01:06] SW: I’m a Senior Developer Advocate at AWS and previously I was pretty much the same thing at Netlify and I changed careers when I was 30. I used to be in finance. I did six years in investment banking and hedge funds. I basically burned out and decided that I want to try coding instead and spend a year going through freeCodeCamp and then a boot camp. Then I started out in a small insurance tech startup and then I went to Netlify. That’s the brief history.

I am mostly finance and a little bit of service, especially with Netlify now. Originally, like I basically spent all of 2018 in React and did a lot of community work, so speaking and then moderating of the [inaudible 0:01:44]. I’ve stepped down from that. I did that for about two years and basically to focus on other things. It can be a repetitive job doing moderation for a community when I wanted to do other things, so I just handed it off. I'm still around on there if you want to engage on React. 

Recently, I’ve been delving a lot more Svelte, like my own site is renamed Svelte. I think it’s a really interesting tension between Svelte and React because Svelte focuses on a very light frame or footprint, and then React says, “What can we do with a heavy but still reasonable framework for print?” The way that I started pitching things is that Svelte is for sites and React is for apps. Svelte is for interactive sites where you want to do a little bit of New York Times-y interaction, and React is for if you want to write cross-platform functionality. React is perfect for that. 

Basically, I’m just dabbling in interesting ideas. I don't really know what my brand is which is funny because I tell other people to have a personal brand. If anything, I'm not that great of a coder, but people like the advice that I give, especially on a non-technical level. When I having downtime between jobs, my choice for writing my first book was career advice. I think there are not that many people who basically stop what they're doing halfway in their careers and then just like made out a bunch of advice, so that’s what I did. 

[0:02:57] NM: Yeah, and I've been reading through your book the last couple of days and I think that it's fantastic. So the title of the book is Cracking the Coding Career, which I assume is like a head nod to Gayle McDowell with Cracking the Coding Interview. Is that true?

[0:03:10] SW: Yeah. It helps to sell the book immediately because it helps position people. I think one of the superpowers that China developed is how to package ideas. To package ideas into a very, very small quantum of words and then phrase it in such a way that it explains itself, like you don’t even have to be there. Once you have a title of the Cracking the Coding Career, _people very naturally contrast it with _Cracking the Coding Interview and then you realize the interview is only one part of your entire career. 

[0:03:35] NM: Tell me about the book. Tell us what you're trying to accomplish with this book. 

[0:03:39] SW: I’m trying to fill a niche. I think there's a lot of books out there about how to learn to code and some about getting your first job. Then there's a lot more books about how to become an engineering manager or how to write super high levels sort of architectural patterns like Clean Code and other timeless books. I think there is a missing – Yeah, for people who are in the early parts of their career, so trying to give some good ideas for juniors to seniors. 

The way I touch it is from code newbie to senior dev, so it’s like code newbie and then junior dev and senior dev and then the two transition states in between. Then I also talk a little bit about when people go on past their coding careers into management or entrepreneurial roles and stuff like that. Basically like giving a roadmap of how this thing works. 

I have a little sister. She is still in college, and if she were graduating right now and coming into the tech industry, this would be me, the older brother, telling you the way things are and not from a position of authority. Nobody appointed me as a guru. I’m not a career coach or something. I'm just one person. I've seen a lot. I’ve read a lot. I’ve talked to a lot of people. These things seem to be true. These seem to be good ideas. Your mileage may vary a lot. But, hey, I wrote it out for you. Take what you can. 

The way I pushed in the preface was this is a buffet. There's a lot. There’s 40 chapters. There's a lot of ideas in there. You’re not meant to drink all of them in. Pick a few that work for you. If you can do that, then it would be a better book book already. 

[0:05:05] AW: You’re not focusing on the craft of coding, which I think I know when I was an early career coder and I just felt like I need to heads down focus on the code and get better at code when I'm sharing just a lot of opportunities that had to do with there are so many other parts of the job. How much does your advice in this book extend to other careers?

[0:05:29] SW: Interesting. There's a section at the end of the career guide section which is called Beyond Your Coding Career. The book is split into four parts, right? There is a career guide section that’s anywhere from newbie to senior. Then there’s principles, there is strategies, and there’s tactics. These are all in there. They’re just like independent essays that may or may not give you some good ideas. I think the idea is that we focus on those principal strategies and tactics wherever you are in your coding journey, and it will be evergreen and relevant throughout. 

To some extent, yeah, if you’re coding adjacent, you can still apply those. But I think definitely the focus was more on things that developers can use. For example, the Marketing Yourself chapter, you could do a lot more marketing if your business depended on. If you’re a founder, if you’re a consultant, you might want to do a lot more marketing. But I think most developers don't have time for that. The pitch was marketing yourself without being a celebrity, right. They kind of feel like it’s not for them. All these marketing tactics is kind of like, “I don’t know.” That becomes a lot of your identity. I wanted to present an alternative way I guess. 

People know these things are important, but they don't want to be full-time on them, and so I want to present like clearly the basics that you can take care of without committing your whole self to it. I think that’s incredible for people because ultimately people still want to code. They still want to be developers, but you also just want to do what makes sense in terms of making sure that people know about your work, both internally at your company and but then also externally. You're the only person who's as invested in your career as you are, right? Everyone else has their own things going on. 

The days where like companies had a whole career development plan for you and stuck with them for 20, 30 years that just seems so ancient. It’d be nice if that actually happened but it doesn’t, so we have to take care of our own career image and think about the long-term gain. 

[0:07:12] AW: I think it’s funny how you say everybody knows it’s important to do things like market yourself and I feel like a lot of developers don’t necessarily think that’s important, and it can feel kind of like, “Oh, this is supposed to be meritocracy. Our work should be able to stand for ourselves. If we do good work, then everyone will know about it.” But that’s just not at all how things work. 

[0:07:36] SW: Basing off of – Let’s say I have a buddy who just like created like a marketing for developers workshop, and he did a survey. When he said on the survey, 91% of respondents said that they knew marketing was important for them. That’s kind of basing off of that one off anecdotal survey that was completely non-scientific. There can be this build-it-and-they-will-come mentality in dev. I think it’s pretty common advice that like, “Hey, if you build it, they might not come if you don't tell them about it.” 

In the same way, if you’re a great dev and nobody knows, then nobody can really see your work. Nobody can really benefit from your work, and you can benefit from your skills because no one knows about it. So that’s kind of how I think about that. 

[0:08:09] NM: I think that a lot of devs, when you say like, “Oh, you need to market yourself,” they immediately associate that with like marketing. Oh, I need to tweet more hashtags or something. They have this very maybe rudimentary view of how you go about this idea of self-promotion, and I think a really good path for a lot of developers can just be just teach. You are learning things constantly as a developer. You have t. So just share those things that you're learning with others is just like a very natural way that you can help other people, but you're not overly self-promotional. 

I think that’s something that you do really well and you give really good advice for in your book as well. Maybe you could tell us a little bit about those ideas. Can you tell us maybe about your writing habits? One of the things I noticed about your work is that you just draw on tons of prior art. You link to tweets. You’re sighting siding stories from Silicon Valley Titans. You're quoting principles from Ray Dalio. What’s your workflow look like to just organize all this?

[0:09:05] SW: I call it [inaudible 0:09:05] writing, and it’s one of the chapters in the tactics section of the book. Basically, it’s this whole idea of you store ideas and bullet points in sort of an external second brain. I use one note. Other people can use notion. I don't use notion right no, which is because they don't have off-line access and I don’t want to be stuck with this idea in my head that I can’t offload it, because my memory is terrible. Things that humans are really good at are creativity, and they’re seeing abstract shapes of things. Things that humans are really bad at are like storage and search, and we should just offload that to devices and make use of those. 

I listen to a ton of podcasts. I read a lot of information, but that doesn't count for anything if I don't write it down somewhere. It’s kind of that whole thing about if a tree falls in the woods and the no one’s around to hear it. It doesn’t make a sound or whatever. It's kind of like if you learn a bunch of things and never put it out or you never write about it or you never even write it down. Did you ever even learn it? Why’d you bother? It's a little bit harsh. Obviously, like you pick up some stuff but your levels of attention is much better once you write it down and take notes. 

I try to go through life, looking for interesting ideas, interesting quotes, interesting turns of phrase even. I'll write it down and organize it by the matching theme and trend. Then I might just sit there for months. I might just like slowly add something. But when the time comes, I start from a base of here are all my notes already, and now my only task is to organize them. I think that's much better than starting from an empty page and then going out and pulling in data and references on demand because like it’s just a lot harder. It’s better to start from everything in place. 

The whole [inaudible 0:10:36] writing ideas is far from French practice of cooking where you do all the prep work up front. Then when you start cooking, you just cook. You don't do the slicing. You don’t do the washing. You don't do any of the other stuff. I don’t cook very much. 

[0:10:52] AW: Of your stuff. 

[0:10:55] SW: In the post, I listed a bunch of things but I had to reset that. But you start with all your ingredients measured, washed, and prepped. Then all you're doing is just combining things when you're actually in the process of cooking. Then you have the room for creativity and you have the ability to enjoy it a lot more, and it's a lot shorter too, right? The whole idea is to split your writing into pre-writing and then the actual writings of [inaudible 0:11:15]. 

Pre-writing is very serendipitous. It's always on and it’s a background process. You’d never know when you think of something or like a conversation or like a podcast or like something that you add links to it. When that happens, just put it down but then you carry on with the rest of your day. You don’t have to drop everything. Then when you actually sit down to write, which I think for me I think at least the first three months of the year, I was blogging something every day, which is a lot. I had to stop that, especially for the book writing. When you sit down to write, you have all this stuff laid out for you and all you do is sort of organize and then put the words around the idea.

I also do a lot of testing of ideas, so I'll have a conversation with friends or I’ll be on a podcast and I’ll verbally say something I haven't written yet, but it’s something sitting in the back of my mind. I’ll receive a response. If the framing isn’t right, people may not get it straight away, so I want to test the framing of the ideas. Kind of like how when you launch a musical on Broadway, you don't go straight to Broadway. You actually workshop it for a few weeks off Broadway and then like gauge the audience response. You swap out some songs. You like swap out the cast members, whatever. Then you bring it to Broadway. 

That's a little bit more of the highly produced thing. I don't do that for everything. In fact, this is probably like the minority of what I do, but these are old skills where you separate prewriting from writing, because the actual act of writing is already hard enough, so you should do everything to make it as easy as possible. The main insight from all of this was that in cooking you only have one kitchen. You can lay out all your stuff on the table. That's one meal, and you just got to limit it by that. Whereas in writing, you have infinite kitchens and you can just lay everything there. Nothing rots. It's great. You have infinite storage. It doesn’t matter. 

People s should use that. If you’d look at your note-taking system as an infinite kitchen of things that are going to be [inaudible 0:12:52] one day, so the way that Tiago Forte, who runs the Building a Second Brain course, he says basically optimize for action. All your notes optimized to take action, because I think too many people authorized for consumption. They’ll go like, “Yeah, I read 150 books a year or something.” I’m like, “What do you really get out of that?” I mean, there’s all the enjoyment, right, like this entertainment trip.

I think if you want to step up your sort of writing productivity, you can just like divert a little bit of your energy to optimizing for action. When I listen to a podcast, if I find something good, I will trade off [inaudible 0:13:22]. I'll just pause and like transcribe even the timestamp, the dates. If someone mentioned something during a conversation, I’ll go follow up on that, because it's much better to trace an interesting idea than to go wide. 

[0:13:33] NM: One of the helpful things I learned from Tiago too is this idea of organizing your notes by projects rather than category, and that was like a huge insight for me. The difference is like I’ve used, for example, a bookmarking service. I used Delicious back in the day and now Pinboard. I’m just this constant squirrel tucking away nuts for winter but I'm just tagging stuff, and it's actually pretty hard. There's no goal attached to it. You're just like, “Oh, this is something about React. It’s something about Angular. 

Whereas one of the things they talk about in Building a Second Brain is really you want to have projects in mind, like don’t just tag something React to be like, “Oh, I’m going to write a blog post about how to think about useState and React Hooks.” That’s a project. But when I come across an idea that's related to that, I will like categorize it for that project. I think that’s really, really helpful in collecting notes. 

[0:14:18] AW: Yeah. I wanted to ask. So say you’re reading a book, what does it look like for you to process that and turn that into notes? Do you have one page for notes about this specific book, and then how do you remember that you have notes on that specific thing?

[0:14:34] SW: I don't read that many books. 

[0:14:37] NM: Well, I think the bigger question is, yeah, just workflow. 

[0:14:38] SW: Books are very topical for me. Books are very topical for me. Recently, I read the _DynamoDB Book _by Alex DeBrie, right? Everything in there is going to be about DynamoDB. It’s very collocated in that sense. I do write down the things that I find interesting and then I blog about it. He appreciates that because it helps him do content marketing, which by the way, if you want to get really good at marketing, help other people market their stuff. It’s such an unappreciated tactic but anyway. 

I’m very into reading technical books cover to cover. In my own book, I call it the best way for developers to level up, right? Because if you think about it, beginners need the quickest way to hello world and expert people only need the diffs of what’s changed. It’s only the intermediate people that need to fill in all the gaps, because you’ve done the hello world. You can get something working. You need to know how things actually fully work. 

One thing is I guess I don’t have that much of an issue. I do a lot of reading and podcast listening. If different parts of the podcast correlates to different parts things I’m interested in, I’ll just split up the learnings. There’s no point concentrating by the medium type. You’re sort of splitting that and slotting them into the ideas they belong in. 

[0:15:41] NM: Just to dive in this a little bit more, then we can move on, is I'm curious about the actual tooling. I feel like I'll be reading the Hacker News and click through a couple of articles and then there's like moving on. For you, when you come across an interesting blog post on your computer, how does that actually end up in your notes? You have one note open as like a separate app and you’re just like, “Oh, this is amusing. Copy [inaudible 0:16:00].” 

[0:16:00] SW: Yeah, all the time. Yup, your note-taking system has to be cross platform. For me, it has to be offline ready because I can be on a plane or I could have bad connection. I'm not letting that stop me from writing things down. It’s that important because maybe my memory is bad. It would be like it also is a blocking behavior on the other things I could do. The quicker I can offload that, the more it frees you. You have to do other stuff, so it has to be reliable. 

[0:16:22] AW: Are your notes just verbatim? Are you copy and pasting passages? Or are you totally writing something in your own words or you have like bullet points?

[0:16:30] SW: I do a mix, yeah. I would say like if you are in a podcast, you’re basically just writing down things that resonate with you. If you can, you copy and paste. It’s easier to search. It’s just levels, right? If you copy and paste, you’re engaging with it less. If you’re typing it out, you have more resistance, right? You’re summarizing more and you’re putting in things in your own words. Then that resistance actually helps you learn and retain better. So it’s all levels. You do what you can. Sometimes, there's no better way to phrase it, so I just copy and paste verbatim. 

One of the chapters that you see as really an action is the megatrends chapter. That chapter probably took three years to write, because it's just been me jotting down things that I thought fit what a megatrend was for developers. People broadly understand the principles chapter like these are good things that I always have on, and people understand the taxes chapter like what to do when x. 

The strategy chapter is me being really weird. I have a business background. I have a business/finance background and I’m really interested in big decisions, big irreversible decisions where it’s not like you can just bet on a thing and then just cut out and go the other way. You made that strategic movement. So I wanted to have that discussion basically because I am one of the few people who has that kind of background to talk about this stuff. This is everything I do with how you bet on technologies. 

As a developer, you have this raw programming ability, right? You have this vague sense that some technologies are more valuable than others and you try to get lucky in it. You can be successful in it like many different technologies. It’s a little bit of a difficult sort of multivariate equation to solve. What I was trying to emphasize in megatrend, people understand, when you invest early, you’ll meet the worst later, and the risk of investing early is that you might invest in something that this just doesn't work out and you’ve just like wasted a bunch of time, which I explained in the book. It is still fine. It’s not great. It’s still fine. 

When it comes to identifying a megatrend, it’s not about being early so much as seeing something that's inevitable because it's just like sweeping a vast sauce of the population and then just getting on with the program. There a lot of developers who just fight it or they just – I don’t get it. I’m out. That’s fine like if you really, really disagree with it. But I think a lot of people can get ahead in their careers. The main example is the one that has [inaudible 0:18:28] my life. Then also it’s just a really good example. 

I think as I gave an example transcript production in JavaScript from 2016 to 2019, something like that, and it was like 20%, 30%, 40%, and 50%, 60% of all of JavaScript, right? The question was, well, do you want to vet that in 2020 it’s higher or lower, right? It’s probably higher. It’s the kind of thing of like, “Okay, you can see where things are going.” If you want to, you as an individual developer can pivot yourself much faster than the broad population, which takes time to decide and figure out on your own. So if you want to, you can lean into that trend and go skate to where the puck is going. But in this case, the puck is not moving fast at all. It’s just moving really slowly. It’s good for you because you just can spot it.

But then also like you can also establish a really good brand just from things that are obvious, just living slightly ahead in the future. 

[0:19:17] AW: I feel like a lot of people are trying to be like if something is gaining popularity too quickly, they can act like hipsters like, “Oh, TyepScripts. I don’t know. Everyone’s into TyepScripts and I don’t like it.” But actually embracing things that you can see are really gaining speed I think is super valuable. 

[0:19:34] NM: We also interact with a lot of people on the other side that you were talking about where we’ll send an email saying, “Yeah, we’re going to talk about React and TypeScript,” and they like do not want to learn TypeScript. They feel like the world is moving too fast, JavaScript is moving too fast, and they want to just opt out. If you want to opt out, you can get a different career. But if you want to continue on, you sort of have to see where these trends are going. Like you said, get on board and be a part of that wave is going to be easier than trying to like battle against it. 

[0:20:01] SW: I’m always very careful to say like there are multiple ways of success. For sure, if you just fundamentally disagree with TypeScript, [inaudible 0:20:07]. But I’m just saying, if you’re looking for an edge, this is one fairly clear edge that I don't see people being aggressive enough about. There is this thing of consensus winners in finance. In tech, it could be like FANG, like Facebook, Amazon, Netflix, and Google. Everyone on Wall Street has a buyer rating on them, right? The traditional thinking in finance is that you have to be contrarian to make money, right? If you're just thinking the same as someone else, you’re just going to have the same results as everyone else.

So the contrarian way is like if everything is to buy, then you want to short that. Traditionally, that doesn’t work out because they are broad megatrends and things don't just go up in a country that there's some persistence in terms of how companies perform, especially if you can spot the megatrend. The way to be non-consensus here is that everyone is positive on the company or technology. You want to be way more positive than that. You want to go really aggressive and hard on that because that just puts you two, three years ahead of everyone else, and that gives you an edge as well. 

That's an interesting way to think about this and which probably loses a bunch of folks. But if you invest in stocks at all and you look at analyst’s reports, you can see like – Let’s say I have if I have a [inaudible 0:21:08] on Amazon, a thousand dollars. Everyone is like 900, 800,000, and then some random fella comes along and says, “I have 5,000 on this. I think the stock is going to 5,000.” That's a way to be non-consensus but still in the same direction as everyone else. But you’re seeing something that everyone else doesn't in terms of like the broader trend and sort of mapping that out long term. 

[0:21:27] NM: You also talk about this idea of specializing in the new. I feel like that’s somewhat related. Can you talk about that idea of your advice to specialize in the new and why you think that?

[0:21:36] SW: Yeah. Again, this doesn't have to apply to everybody. This is just an idea that you can think about when you're thinking about what to do with your tech choice and personal branding. There's a lot of croft that builds up and stuff that's old. To be an expert in something, you probably have to have read basically everything there is to be read about that particular topic. I graduated from a boot camp three years ago. If you’re just joining, I don't care how good you are at rails, right? You’ll never going to be as good as someone who's done it for 15 years.

If something newer came along and it was a bit younger like three to five years, you could probably catch up with that just by catching up on history and working harder than others, but it is likely feasible to be like an expert in that field if it's new. I’m not saying that you can be an expert in something that’s old. It’s just you’re contending with a lot of other people who naturally just been there longer and they just have way more credibility as a result. 

I think new ones I actually haven't written into the book yet but I have thought about it recently was basically you don’t have to specialize in everything new. If it’s something that's relatively dated like rails, for example, you can specialize in the new inside of the old, right? Whatever is coming out in Rails 6.0, just do that, because the whole idea is that everyone else is so caught up in their own things anyway. 

Actually, a lot of developers don't have the time like you want to speed on the latest and greatest stuff. If you specialize in that, then you become the authority on that particular thing. Then you can spread out your authority beyond that later on. But anyway, in the book, I try to identify people who bet on things early and their careers did really well as a result and they were not project originators. They saw something that was new that was a megatrend that also clearly identify with their values and the problems that they had. Then they just lean super hard into it. 

It’s really funny because we all have the same 24 hours in a day. We have broadly the same units of work in terms of what we can output. But if you tie your horse to something that’s just like a rocket ship, then your work just magnifies itself in a really interesting way. I think just like specializing in the new ones is like a really good principle for like setting yourself apart and having a better-than-average shot of becoming the world's best at something. Because that's a very, very good position to be in. 

[0:23:35] AW: What are some more specific metrics that I would want to look out for if I were looking for what technology do I want to tie my horse to that might be a rocket ship? Is there a particular fingerprint or certain metrics that would be really appealing for this? 

[0:23:53] SW: Basically, things that are easy to get are less valuable. So the things like GitHub stars and downloads and stuff like that, those are good virtual accounts, but they just kind of mean less. Obviously, the closer you get to actual usage rather than just raw popularity is useful as well. I tried to push people towards longer-term metrics like anything that you can measure on like a week-to-week basis is too granular. There’s too much noise. You’re treating these like financial stocks or whatever. 

The main metric that I really want people to get to is what's population adoption. What is like the number of hours in a day that people spend in this tool or technology? Those are really substantial. You don't make those things lightly. I can fake a GitHub star, fine. But like if you want me to use a tool for five hours day, that is some serious commitment right there. Those are the things like VS Code and whatever. When you start understanding that there are some metrics that are more valuable than others and really looking for things that trend long-term, you can start planning your tech adoption that way a lot better. 

For example, I try to identify megatrends as double-digit increase in adoption from year-to-year in terms of population percentage, so that's a very high bar. That’s a little bit like viral adoption. There is also generational adoption like broad increase in population adoption for over 10 years. You see that in things like e-commerce, which is a very, very broad category. 

I think in terms of like the lower level like betting on technologies, probably usage management. But then also I tend to look at individual big companies announcing that they invest in something. In the book, I talk about React Native. When Shopify announces that they now have adopted React Native, that’s not something that's casually made. That’s an investment of millions of dollars of developer hours, and that's something that's vetted legal compliance. I don't know. Whatever. When you say those kinds of things, they’re not only saying that they're using it. You’re also saying, “Hey, we’re open for business. We want to hire React Native developers.” That’s really what they're getting at.

When companies announced that they're using technology, that counts for a lot of off-book evaluation of the technology and forward investment in its future. I think that’s very interesting to watch as well. 

[0:25:47] NM: I mean, I love this idea that you are able to like read between the lines, right? Some people might just see, “Well, Shopify is using React Native. So what?” But you’re saying no. When someone does that, they’re drawing a line on the sand. They’re saying like, “We’re trying to hire React Native developers. We’re investing in React Native.” I appreciate that about your insights as they – Because of your background, you're able to look at how businesses operate and then be able to give this sort of like soft advice as to how developers should function within there. 

One I’m thinking of in particular is this idea between profit centers and cost centers. You talk about this in your book and you have the disclaimer that you’re not even 100% sure on this, because it's a bit touchy in the sense that you're saying like, “You might be part of a cost center rather than a profit center. You should pay attention to that.” But I also think it's really applicable to what you're talking about with being a big brother. What I might tell my younger sibling is like this doesn't apply to like the whole world necessarily, but I have your best interest and you should pay attention to it. So could you talk a little bit about that, profit centers versus cost centers?

[0:26:46] SW: Yeah, I’ll go further than that. I’ll just say it might not be politically correct but it’s just the way things mostly shake out. You want to warn your sibling about that when they join the industry. That one probably had the most disclaimer [inaudible 0:26:57] chapter of all.   

[0:26:58] NM: Could you talk about that idea right now?

[0:27:00] SW: Yeah, sure. 

[0:27:01] NM: Like you were talking to a sibling with all the disclaimers intact. 

[0:27:03] SW: Yeah. It’s this idea that companies mostly try to make money. [inaudible 0:27:07], but mostly they try to make money and some parts of the company are more closely associated with moneymaking and some parts of the company are more closely associated with spending money. The way that each of these parts of the companies are treated and perform and behave and are compensated differ dramatically. I saw this very, very closely in finance, and it’s been a part of the chapter talking about that. 

If you make money for the company, you’re treated with more resources, better headcount on hiring. If you show a positive result, they’ll throw more money, and you would get more positive results. That's how profit centers behave and that’s how companies behave around their profit centers. When you’re a cost center, it kind of works the other way. The way you sort of contribute is you sort of save money and then that kind of gets zeroed out for the next year and you’re like just expected to do better and do better. You’re always asked to do more with less. The upside is not that much, right? Your maximum upside is 100%. You can just eliminate your job completely or whatever. 

As far as profit centers go, if you can show us clear correlation between like you spend $1 million on us and we give you back three million, the next day they’ll come back and throw 100 million at you. They’ll weigh the things scale in terms of like resources. It’s just completely different. I mean, it’s particularly relevant in a recession like the one that we may or may not be going through right now. That’s an interesting question. It also matters what people trim and what people really, really want to hold onto. Obviously, you want to hold on to profit centers. But if the profit obviously at least have disappeared, then then you got to let those go. 

Profit centers take more risk and cost center people get compensated accordingly with that. Cost center people take less risk because they kind of deal with the internals of the company. But it is more within the control if you can reliably reduce the expenses of something. Let’s say money in the bag rather than like money that you may or may not get. Those are just interesting ways that business people think. But basically, the whole premise that you want to align yourself with profit centers in your company and as a developer, you can actually be both. 

The example I’d explain is using the building engineer. At my previous [inaudible 0:28:57], we had a building engineer. If you look at that as like a cost center job, then you’re just really making sure that all the payments go out on time and inflection notices and whatever. But if you're looking at it as a profit center job, then you can think about how to pitch that as improving retention for your company and reducing churn, and that actually translates to actual dollars. 

The whole thesis was just companies treat profit centers better. You probably want to be closer to those, but it also doesn't preclude the idea that you can work in a cost center and do extremely well as well. It’s just that your upside is [inaudible 0:29:24]. 

[0:29:25] AW: I love how you take your finance background and to play to a developer career. I think that a lot of people who switch careers – I used to do research and then I switched to become a developer, and I’ve had this impostor syndrome where I’m like, “I don’t have a computer science degree. I’m not as experienced as the other people.” But to take that background and hit the ground running when you switch to a coding career I think is super valuable as you’ve shown. 

[0:29:56] SW: Obviously, not everyone can do that. I think especially in web development, we’re actually like a weird industry of majority non-degreed people. Most of the people I interact with are all career changers, so it’s common. It’s not even unique, and I think you want to press the things that you have as your advantage, right? The things that you have is your advantage, right? Some people might say it's a weakness that you don't have a degree, but there's always a strength to every weakness. For us, the strength is that we have prior backgrounds that are way unique compared to everyone else. If you can spring a little bit of that into the conversation, then we start to contribute value that is over and above someone who just hasn't dipped outside of computer science before. 

I didn't start out this way. When I was writing this book, I was just like, “Okay, I will just write down a bunch of good ideas.” I eventually realized that, okay, the strategy section in particular is where I’m really bringing my business back up. I don’t want to make it sound like I'm pressing the entire finance thing throughout the entire book. Strategy section is where I really press this because I'm the person to write it. How many people switch from finance to tech? I'm sure there are many but like I'm the person writing this book. That’s something that I'm abnormally advantaged to write, so I should probably lean into that. I think everyone can do that. 

I had a friend who used to be a chef before he went through a boot camp, and then he applied to one of the delivery box startups, Blue Apron. He was like, “I’m a developer who was a chef.” He puts you ahead of other developers. That’s great. Everyone should do that. I think in particular, anyone who’s done education and art does really well in a career change to teach. 

[0:31:16] NM: You said you can find strength in every weakness and you actually have a chapter that's somewhat related to that in your book, which is a chapter on – Which is called lampshading. Can you tell us a bit what lampshading is and how we can use it?

[0:31:27] SW: By the way, that’s a super nice segue. Lampshading is this idea of there are two parts of your career. Two parts of like a general – Sort of anywhere in the company, there are two sections where it was very common to have people say I don't know. It's when you're very junior. When you're just starting out, you’re allowed to say I don't know a lot. Obviously, you’re always allowed to say I don’t know but I’m just saying like in the abstract. When you’re very junior, you’re allowed to say I don't know and people have to teach you because they are mentoring you. 

Then when you’re very senior and you saw this managing director, he is always like, “Then explain it to me like I’m five.” Obviously, it’s this whole idea of lack of knowledge can be power as well. The common assumption is that more knowledge is power. But I think I want to sort of reverse that a little bit by saying, “If you lack knowledge, there are ways to deal with that. If you have flaws, ways to deal with that.” This is something that stage playwrights do very well. 

I don't know why I talk so much about Broadway. I live New York but I just am interested in putting these ideas from others and just applying it to what we do. The playwright would say like, “Okay, this is a known flaw of my movie, my play, my whatever, my musical. I’m just going to call it out and make a joke of it and acknowledge that it’s a flaw.” Then no one else can attack you for it. Part of the attack is pointing it out. If you took away from them, then you just saw an original. That’s an interesting way of thinking about things from a public presence. If you don't know something, just say you don't. 

Especially in tech, there is so much to learn. No one can ever blame you for not knowing things. If you lampshade your ignorance, then it turns people from possible attackers or critics into people that will help or teach you. That's a very, very broad tactic, but I think it really applies for beginners, because I kind of relate this to my own first dev job when I first landed on the first day. My tech lead was like, “We’re going to write our app in TypeScript. Do you know TypeScript?” I think some people might want to naturally try to cover for their impostor syndrome and just say yes and then go run straight back home and buy a textbook and read it through. But you realize that you’re already in the job. The hired you knowing what you do. You can say no, and they are then obliged to teach you. 

I think that’s a privilege for sure for some people who don't feel secure enough for whatever reason. But for most people, it's okay. The seniors are meant to teach you. I really sort of try to focus this advice on people who are entering in as new developers and trying to keep up, because a lot of people feel overwhelmed. I want to like give this message like, “It’s okay and here's a powerful tool to deal with it. Just acknowledge it.”

[0:33:43] NM: You’re shining a light on it, yeah. 

[0:33:44] SW:Shine a light on it. It’s fine.

[0:33:46] NM: Yeah. It reminds me of this related idea from – Did you see the former FBI hostage negotiator named Chris Voss? He has some books on negotiation [inaudible 0:33:54]. 

[0:33:55] SW: Nonviolence. Does he talk about nonviolent conflict resolution?

[0:33:57] NM: That is part of what he's talking about. It’s about like how he does like hostage negotiation, and one of the I guess tactics he uses is he calls it tactical empathy, and the idea is it's like lampshading where you say the worst thing that the other person might come up with about you to like smooth the path. He has maybe some gimmicky advice but ones like you're going into a hotel and you want to get a free upgrade. He might open by saying, “All right. You're going to think I'm a self-absorbed cheapskate when I ask this but,” and then like ask for an upgrade to the room or something. You say that and the other person is like, “No, no, no. I don't think that. Of course, I would not think that you’re a self-absorbed cheapskate.”

You can also use that just in your work. If you’re like a junior dev, you’re coming in. You can be like, “You’re going to think I'm totally uninformed, but I have no idea how this deployed Heroku works.” Your coworkers are going to be like, “It’s no problem. We’ll just explain it to you.” I think people care more about if you’re trying to protect your ego by pretending that you know something you don’t. Then they would much rather prefer that you just say like, “I don’t know this. Can you explain it,” and people are happy to help. 

[0:34:53] AW: I’ve also noticed there’s like a total compounding effect for – I was thinking back to high school when there is always that kid in your class who is always asking the “stupid questions,” and you’re kind of like, “Oh, my gosh. They’re going off again.” But then I reconnected with some of those people recently, and they’re just really killing it at life. I feel like people who consistently are okay with looking stupid but then are learning from that, if you think about those compounding effects over like 10 years, I think it can be a really powerful tool. 

[0:35:29] SW: Yeah. I couldn’t find a good way to phrase this, so this didn't make it in the book, but I find that there’s this common thread between resilience and trying to be perfect all the time. In the junior dev chapter, I list a bunch of ways that people have screwed up majorly in their careers, and it’s super entertaining. For example, when Instagram launched, Kevin Systrom, the Founder of Instagram, had an automatic notification set up for any ping of 404, and he’s got an email for what was missing, right? That seems a reasonably correct way to handle these things, except that when he launched Instagram, he forgot a favicon, and every single favicon generated a 404, and the service just knocks itself. So there is a bunch of these mistakes. 

There’s another person whose story I tell. When he joined the company for the first day and you’re following the onboarding instructions, accidentally they deleted the prod database of the whole company. The person was like, “Oh, shit. What do I do?” Everyone is like, “Do nothing. It’s not your fault.” It’s the job of the management to help you recover from any mistakes rather than prevent you from making any mistakes. That's a more resilient way of doing these things, and so I think that resilience versus the imperfect idea maps from management to your own personal journey as well where it’s not your job to know everything. It's your job to be really good at not knowing things and to learn them on demand when needed, and I think that's a much saner way to live life. 

[0:36:45] NM: On this topic of career advice, you have a few pages that are really information-dense that are about the difference between junior engineers and senior engineers. I wonder if we could just go through a couple of those and if you could just talk through them as we go. 

[0:36:59] SW: First of all, how do you feel about that?

[0:37:00] NM: I feel like we could probably spend the whole hour on page 41 of your books, so there’s so much there. Let us start with one which is juniors collect solutions and seniors collect patterns. Talk me through this. I haven't talked about them before, so this might be a little bit stream of consciousness. But it’s just the observation that I had, which was I think when you’re just getting started. Again, like in preparation for writing all this, I reviewed a whole bunch of what's the difference between junior and senior dev, and there’s a lot of advice out there. 

A lot of it just assumes that juniors are bad, which I really don’t like. You can’t swap a bad engineer for a junior engineer and a senior engineer for a good engineer. It would mostly stand, and I don’t think that’s good. That’s what helped me to say like juniors are automatically bad. I wanted to frame things in a way like here are the things that you do as your junior that makes sense because you’re junior and then here are a different set of things that you do that makes sense because you’re a senior, and here is the distinction and this is direction in which you can possibly grow. I try to be very careful about not saying the juniors are the worst, which I think a lot of people are not very careful about. 

Anyways, you’re a junior, you’re trying to problem solve, right? You’re trying to get the job done, and I think you should collect solutions. You think you should collect libraries, tools, frameworks, whatever help you get there. If you're proficient in that, you’re a great junior. I can hand you something, and you can get it done. So I think that's the whole idea. I think where that maybe falls apart is getting too married to the tool to the point where I’ll deal with this a lot in the React [inaudible 0:38:20]. People will be like, “I have this blog post for doing x, how to do like, I don’t know, modals.” Then it’s completely useless to me because I only read the blog post that says how to do x with React, right? I now identify myself as a React developer, so I don’t even read things that are made for me in React, and everything that doesn’t have the word react in it, too bad. 

That’s something not healthy, and you see that a lot. People get really married to their tools because, well, first of all, I guess it gives them their jobs. It’s very good reasons to be married to something. But then when it stops serving them well or witness some new, something that the solution doesn't directly cover, then they have to contort themselves really hard to find a way around that. Anyways, I think in the – What I was trying to say was that juniors should collect solutions and be really good at applying those solutions to the problems. 

I think seniors just start to set back a little bit from that and understand the underlying patterns behind any particular tool that I’ve reframeworked. I don’t care, whatever, and be able to either evaluate whether that works for that situation. If it doesn't work, write your own or choose a completely different thing and being able to evaluate technology based on very fundamental I know how this thing works underneath. Does it work for this use case? If it doesn't, I’m just not even going to choose this tool. I’m just going to go with something else. Being able to interact with technology is not on the branding, naming, identity level but just like the raw underlying how does this solve this problem and what trade-off does it have. 

Basically, all solutions and all patterns have trade-offs, and that’s why you memorize design patterns and all that. These solutions basically make sense at a certain scale and when you 10x or 100x that, those solutions started becoming unscalable, because they always make assumptions on I have unlimited memory. That becomes not true. I have unlimited bandwidth. That’s not true. I can do all my computations within 60 milliseconds. That becomes not true. Things just fall apart as you scale up. As you understand patterns to like solve each of these things, you start to collect them, right? I will read a whole bunch of framework stuff and a lot – There’s so much junk out there about like how to do x with React. It's just like, “Okay, that’s great. There’s a whole lot of solutions but what is the pattern that takes me to the next level?” 

Then you start reading beyond your field and going into operating systems programming where you understand things like scheduling and how threads work, and that's what the React team is doing, especially with [inaudible 0:40:29] React. But then you can also go and study game programming patterns. A lot of a people recommend like game programming design patterns book. [inaudible 0:40:36] that I haven’t’ read all of it but this whole idea of like go out there. Go collect patterns. Bring it to your – Those things actually last longer than any individual technology or situation that you have. 

So that's what I mean by those six words, juniors collect solutions and seniors collect patterns. Does that make sense?

[0:40:51] AW: It makes sense and I really love this and it totally reminds me to go back to food, because food is very important, of the way I learn how to cook. I was learning how to make sourdough recently, and it was very much go out, find recipes. What are different recipes I can follow? But then once I become more comfortable and I have made bread 10, 20 times, then I can start to extrapolate and think of what has worked, what hasn’t worked, and move more towards patterns and set up specific recipes. 

[0:41:22] SW: Yeah, absolutely. I mean, you’re a junior. Sure, follow the recipe, right? But then like maybe you start to experiment a little bit. Do I really need one tablespoon? What about three? Then how does that change things?

[0:41:31] NM: I’d like to look at two more and then we’ll wrap up. The next one is juniors keep things dry and seniors avoid hasty abstractions. So dry here is don't repeat yourself. Talk me through this. 

[0:41:43] SW: Yeah. This one might fall in sort of bad engineer, good engineer technically. Phrasing these things is so hard because I’m trying to keep it short so that's impactful but I also like to just lose a lot of context. Keeping things dry, don’t pee yourself, is something that is taught among people that’s like a good programming practice. There is something to say for this, because if you have some code that gets running all the time, if you have the same code that’s spread out in all the different places, then when you change something in one place, you might have to go through the rest of your code base and change it. That’s seems kind of hard to maintain. 

A reasonable have to do with that is to just try it up to extract things into higher-order function or some sort of mix in and some middleware and then [inaudible 0:42:19] framework inside of your own bath. That’s like fine. It’s not the worst. Sometimes, it works really well, and then you become a framework author based on that. 

Sometimes, you don't want that because you don't really understand the abstraction that you have created yet. You don’t understand the problem space that you’re dealing with and you don't know whether the abstraction that you’ve first settled on is right, and it’s very expensive to unwind abstractions to the point that people don't, and so they just stick to the abstraction that they have and they punch holes in it till there's 50 different options on your function, and it kind of does whatever. Basically, the more abstract the name becomes, like abstract class creator factory factory, it starts to become this behemoth of a thing that costs more in terms of the stack frame of your memory as you go through the code than it actually gives in terms of the readability of it. 

Seniors avoid hasty abstractions. What I mean by that, this term is actually directly lifted from Kent C. Dodds. I credit him on that. Basically, saying don't abstract too early. Live with a little bit more duplication. So I think one of the popular ways of phrasing this is write everything twice like wet, which is the opposite of dry. [inaudible 0:43:16], so write everything thrice. The idea is you avoid hasty abstractions. Copy and pasting is not that bad because you don't know what you need yet. If you abstract things too eagerly, it becomes very hard to unwind. What I phrased it in the book as was seniors understand that code is read, deleted, moved, and copied much more than it is written. You shouldn’t be optimizing for the lines of code. Sure, dry code has few lines of code, but it costs more in terms of the ability to change and modify it. 

I also tie it in with this idea from Dan Abramov, which is you should optimize for change rather than optimize for concision or being dry. That’s kind of the whole idea of why I think juniors keep things dry, seniors avoid hasty abstractions, because you learn the cost of abstractions is not zero. 

[0:43:58] NM: Okay, last one. Juniors deliver features but seniors deliver outcomes. 

[0:44:04] SW: I like this one because it’s not the good versus bad engineer thing. It really is a step change in terms of your global responsibility. The way I prepare for this entire section was I went and read something like 20 different engineering career ladders, which is also a chapter in the book. People publish their career ladders and they have the very clear expectation of this is what a junior is responsible for and this is what a senior is responsible for.

One of them is business impacts. The more senior you go, you’re not so much just about the code anymore. You’re also about the mentoring like communication and the business impact, the ability apply code to solve business problems. Do you understand your problem domain? A junior developer like you just hired on some job, you need to share features. People will assign a junior ticket to you, and you take that junior ticket and you go complete it. Then the cycle repeats, right? That's a very functioning capable junior. I think the senior would be responsible for business outcome of that. When are the junior tickets wrong?

Being able to push back on things that are assigned to you and saying like, “You prescribed to me this solution and asked me to do it. But how about I don’t do that? If we actually do this other thing, there’s actually a guess at what you really want.” People will go like, “Ah, that's totally right,” and then they promote you. That’s the whole idea of like delivering outcomes because ultimately what your product managers, your CEO, your whatever, what they care about is does it make customers happy. Does it make users happy? It really isn’t about features, right? It really isn’t about any specific ticket. It’s more about do you understand that the entire company is working towards this goal. If you get everything on your checklist done but the company fails, it doesn't matter. You should own outcomes. This basically lets you a little bit with your PMs. Your PMs should definitely own outcomes, right?

I’m not saying that you’re totally in the hook for it. You start looking out for the impact of your code. I’ve written code that I was absolutely sure it wasn’t going to go nowhere because it was stuff that was asked for but I could see that it was just like a boneheaded decision by someone. I didn't have the authority at the time to push back but like I should’ve because that would've saved my team a whole bunch of time, and it worked out that it was never used. That doesn’t make me happy. You want to ship impactful products in your career. Not just for self-satisfaction but it becomes a talking point for your next job, right? You want to ship outcomes because that’s what markets – That’s what sells you in your next thing. Even if you don’t switch jobs, it sells you within your won company as well. 

That’s just the whole idea. I want people to understand that one they are comfortable shipping features, they should look to the next thing of business impact and building outcomes. 

[0:46:18] NM:I feel like that’s a key theme in your book, which is basically around don't give too much mind to these boundaries that people put up for themselves in terms of just thinking of yourself as a developer or that I just write code. It's about I think this holistic responsibility for the outcomes of both your work and your career and take a personal responsibility there. 

[0:46:38] SW: A lot of it depends on how receptive your company is to that. A well-run company will encourage that from you, and a somewhat more bureaucratic company might just view you as a dev box like, “I give you tickets. You fulfill those tickets.” That’s fine. Those jobs exist but you might not be best utilized at those jobs. That's where marketing yourself comes in because ultimately you are in charge of your own career, right? You want to be able to put yourself in positions where you can flex the best of your judgment, because those are the things that will never be automated away. 

[0:47:05] NM: Okay, Shawn. Tell us where people can find more about your book.

[0:47:08] SW: Okay. You can find more information at crackingthecodingcareer.com and you can also see more details about the behind-the-scenes and making of the book in other interesting relevant career information on the Twitter just coding_career. 

[0:47:21] NM: Okay. Then what's your Twitter handle? 

[0:47:23] SW: My Twitter handle is swyx. I got on Twitter early, so it’s S-W-Y-X, it’s just my initials. I’ve gome by swyx for, I don’t know, 15 years. 

[0:47:31] NM: All right. Shawn, thank you so much. This has been a delightful conversation. 

[0:47:35] SW: Thanks, Nate. Thanks, Amelia. 

[0:47:35] NM: I’m so happy to have you. 

[0:47:36] SW: Thanks for having me. 

[END OF INTERVIEW]

[0:47:38] NM: You’ve been listening to the Newline Podcast. I hope you enjoyed this conversation. 

[0:47:42] AW: If you have a minute, a review on iTunes would really help other people find the podcast. 

[0:47:46] NM: We have a lot of great content coming up, and so to be notified of new episodes, hit that subscribe button. 

[END]