Learning in Public w/ Shawn Swyx Wang (part 2)


Summary

In this second part of the interview, Shawn ‘Swyx’ Wang continues his discussion with host Jonathan Cottrell about developer career progression, focusing on the distinction between principles, strategy, and tactics. Wang explains that principles are ‘always-on’ rules of thumb, strategy applies to large, irreversible decisions, and tactics are smaller, commoditized skills like writing or speaking that help in your current job.

Wang emphasizes that top engineers aren’t necessarily more productive in terms of raw output, but rather apply their productivity to things that matter. He discusses how engineers can move beyond just executing tickets to influencing technology strategy, suggesting that they don’t need to wait for permission but can take initiative, as demonstrated by his friend Matthew Gerstmann who started a JavaScript guild at Dropbox.

The conversation explores how values intersect with principles and technology choices, noting that disagreements about frameworks often stem from value conflicts rather than technical features. Wang shares his favorite principle ‘Pick Up What They Put Down’ - a method for engaging with mentors and experts by responding to their work, which guarantees feedback and helps build authority.

Finally, Wang introduces the concept of ‘the operating system of you’ - the need for developers to maintain their physical health, motivation, and systems for processing information to sustain long careers. He stresses the importance of taking care of fundamental needs like sleep and physical health, drawing insights from experienced developers who have maintained careers for decades.


Recommendations

Books

  • The Coding Career Handbook — Wang’s book that covers principles, strategy, and tactics for developer careers, available at learninpublic.org with a discount code devt30 for Developer Tea listeners.

People

  • Matthew Gerstmann — A friend of Wang’s who works at Dropbox and started a JavaScript guild internally, eventually setting JavaScript strategy for the company without being asked to do so.
  • Sanjay Yamawat and Jeff Dean — Top individual contributors at Google who exemplify applying productivity to important problems rather than just raw output.
  • TJ and Ryan Dow — Creators of Node.js and Express.js who left their projects due to value conflicts with the communities that formed around their work.
  • Guido van Rossum — Creator of Python who stepped down as BDFL due to disagreements with the values of the Python community.
  • Bill Gates — Mentioned as someone who regrets not sleeping enough during Microsoft’s early years, highlighting the importance of physical health for sustained career success.
  • Scott Hanselman — Developer who emphasizes taking care of physical health (hands, back, neck) for long-term career sustainability in software development.

Talks

  • The Operating System of You — A talk by Wang about maintaining physical health, motivation, and systems for processing information to sustain long developer careers.

Tools

  • New Relic — Observability platform sponsored in this episode, offering telemetry data platform, full stack observability, and applied intelligence with AI/ML for anomaly detection.

Topic Timeline

  • 00:00:00Productivity of top engineers vs. junior engineers — Wang discusses research showing that top engineers like Sanjay Yamawat and Jeff Dean at Google aren’t necessarily more productive in raw output than junior engineers. The key insight is that they apply their productivity to things that matter and focus on choosing important problems rather than just completing more tickets. This challenges the common management incentive structure that emphasizes ticket completion as the primary measure of productivity.
  • 00:01:49How engineers can participate in strategy discussions — Jonathan asks how junior or mid-level engineers can move into strategy discussions rather than just executing tickets. Wang suggests this requires a self-driven approach since most companies don’t sit engineers down for strategy planning sessions. He recommends advocating for strategy in one-on-one meetings and water cooler discussions, and shares the example of Matthew Gerstmann who started a JavaScript guild at Dropbox without being asked, which eventually led to him setting JavaScript strategy for the company.
  • 00:07:08Differences between principles, strategy, and tactics — Wang explains the hierarchy: principles are ‘always-on’ rules of thumb that serve as good defaults. Strategy applies to large, one-off, irreversible decisions but isn’t always on since engineers aren’t full-time strategists. Tactics are small, one-off skills like speaking or writing that help in your current job. He notes that tactics help in your current job, strategy helps in your career (a chain of jobs), and principles help in your life as a person.
  • 00:10:21Values vs. principles in technology choices — The discussion explores how values fit into the principles-strategy-tactics framework. Wang admits he conflates principles and values, but notes that disagreements about technology choices often stem from value conflicts rather than technical features. He gives examples of creators like TJ and Ryan Dow (Node.js/Express.js) and Guido van Rossum (Python) who stepped away from their projects due to value conflicts with their communities.
  • 00:17:02The ‘Pick Up What They Put Down’ principle — Wang shares his favorite principle from his book: ‘Pick Up What They Put Down.’ This involves responding to work put out by mentors or experts in your field - writing takeaways from their talks, reviewing their blog posts, or working through their demos. This guarantees feedback since creators are highly attuned to early responses, helps focus your learning, and builds authority by associating with established experts.
  • 00:23:37The operating system of you for sustainable careers — Wang introduces the concept of ‘the operating system of you’ - the need for systems to process and implement good advice. He breaks this down into firmware (physical health), memory (information storage), scheduler (task prioritization), and kernel (motivation/drive). He emphasizes that experienced developers like Bill Gates and Scott Hanselman stress fundamentals like sleep and physical health for sustaining long careers, rather than just focusing on promotion tactics.

Episode Info

  • Podcast: Developer Tea
  • Author: Jonathan Cutrell
  • Category: Technology Business Careers Society & Culture
  • Published: 2020-12-09T10:15:00Z
  • Duration: 00:33:32

References


Podcast Info


Transcript

[00:00:00] But when you study highly productive engineers or top engineers, it’s not so much the output

[00:00:06] that they, the raw like numerical output, you know, I actually have a quote from somebody

[00:00:14] at Google who talk about Sanjay Yamawat and Jeff Dean, you know, who are like the top

[00:00:19] individual contributors in Google.

[00:00:22] They actually are not that more productive than a SWE3, like a junior engineer at Google.

[00:00:28] The insight is that they really apply their productivity to things that matter, right?

[00:00:34] And it’s about choosing problems more than being like a code wizard that just blows through,

[00:00:40] you know, a hundred times more tickets than other people.

[00:00:44] It’s not, you know, your primary unit or output is not your tickets, and we’re trained to

[00:00:49] do that because that’s how we’re incentivized and managed.

[00:00:53] But really, it’s about picking important problems.

[00:00:59] You just heard the voice of our guest today, Swix.

[00:01:01] Swix was on in the last episode of Developer Tea.

[00:01:04] So if you missed out on that episode, I encourage you to go back.

[00:01:08] You’ll hear a little bit more about his background, especially so you can kind of see

[00:01:13] where Swix is coming from.

[00:01:15] If you’ve ever wondered about the nuances between strategy and principles and tactics,

[00:01:21] then this episode is for you.

[00:01:23] And this episode is for you if you haven’t wondered about those things, because you will

[00:01:27] learn a ton about how the next step in your career might be to abstract your thinking.

[00:01:34] My name is Jonathan Cottrell.

[00:01:35] You’re listening to Developer Tea.

[00:01:37] My goal on this show is to help driven developers like you find clarity, perspective,

[00:01:40] and purpose in their careers.

[00:01:42] Thank you so much for listening to this show.

[00:01:44] Now let’s get straight into the second part of my interview with Swix.

[00:01:49] The question that I think is hardest to answer for, let’s say, a junior or mid-level engineer

[00:01:56] is how do they get to the right place to think about those things?

[00:02:05] Are they supposed to invite themselves to a strategy meeting?

[00:02:08] Where does that happen?

[00:02:09] What is the crossroads where they say, okay, instead of just picking up a ticket,

[00:02:14] I’m going to, for example, I’m going to push back against it and say, oh,

[00:02:19] I don’t think this is the right time to work on this.

[00:02:22] What are those actual kind of concrete actions that I, as an engineer,

[00:02:28] can take to move me more into those strategy discussions?

[00:02:32] Okay.

[00:02:33] So what I was talking about earlier was more of like just being aware of what’s going on,

[00:02:38] like staying informed.

[00:02:39] But what you’re talking about here is how to more actively incorporate strategy into

[00:02:44] your own work.

[00:02:46] And I think that one is more of a self-driven approach, I think, because no one actually

[00:02:57] does this consciously.

[00:03:00] I mean, let me rephrase that.

[00:03:02] I don’t think many companies sit their engineers down for a strategy planning session.

[00:03:08] And I think that you can probably more actively advocate for that in your

[00:03:13] water cooler discussions, your one-on-one meetings with your managers,

[00:03:18] and actually have more of an active conversation.

[00:03:21] One of the very effective examples that I’ve seen is a friend of mine,

[00:03:26] Matthew Gerstmann, who works at Dropbox.

[00:03:29] He actually started a JavaScript guild.

[00:03:31] So he was a software engineer, just like a lot of others in Dropbox.

[00:03:38] But he started in extracurricular organization, internal within Dropbox,

[00:03:43] that focused on important topics within the JavaScript ecosystem.

[00:03:47] And then he ran that and was well-known in his career for that.

[00:03:52] And he ended up setting some of the JavaScript strategy for Dropbox.

[00:03:56] And nobody ever asked him to do that.

[00:03:58] He just came up with it on his own accord.

[00:04:02] But then once he did it, everyone recognized the value of it.

[00:04:05] And then the company supported him financially.

[00:04:07] They were able to hold internal conferences where they could hold these discussions.

[00:04:12] So it’s a little bit of you don’t ask for permission.

[00:04:16] You can just kind of do it.

[00:04:18] And then because it’s valuable, because you’re doing the right thing,

[00:04:22] people will recognize that and reward you.

[00:04:24] And yeah, don’t wait to be asked.

[00:04:29] Yeah, that makes sense.

[00:04:31] And I think it is a challenge because,

[00:04:35] like you said, there’s a difference in becoming aware of this

[00:04:38] and actually doing something about it.

[00:04:41] There can be a conflict, and I’ve experienced this personally myself,

[00:04:45] where I felt like there was an imbalance between my awareness of a need for strategy

[00:04:54] and my leverage to make that strategy a reality.

[00:04:59] And I’ve been there before.

[00:05:02] And I think that that is really where the hard work comes in, right?

[00:05:05] It’s stepping in and saying, okay, I’m going to take one step towards

[00:05:11] making the right decisions, the right strategic decisions.

[00:05:15] And eventually, theoretically, that should bear out in value for the product,

[00:05:20] value for the users, value for the company.

[00:05:22] And assuming that your strategy is right,

[00:05:28] is that your understanding of how that can play out?

[00:05:35] Yeah, I mean, I definitely agree with that.

[00:05:38] For sure, if you don’t have that much influence, then actually your best strategy

[00:05:43] is more of career strategy rather than technology strategy.

[00:05:47] But that’s also very valid and is something that we should discuss.

[00:05:52] But I mean, I do think that engineers have more control over strategy

[00:05:56] than they realize.

[00:05:57] You are consumers of strategy as well.

[00:06:00] The tech choices that you make are reflections

[00:06:03] of what you think of other people’s strategy.

[00:06:05] It’s strategy all the way down.

[00:06:08] And you can’t really just say, I don’t have a say in this.

[00:06:13] You always do.

[00:06:14] And you should recognize your own agency in your own outcomes.

[00:06:19] And I think that that’s an important recognition.

[00:06:23] But for sure, I think when you feel like you have less influence,

[00:06:27] then probably the right focus is career strategy,

[00:06:30] essentially climbing up the ladders.

[00:06:35] I’ve actually surveyed all the public company engineering career ladders out there.

[00:06:40] So you can check out my blog for that or I also have a chapter in the book.

[00:06:44] But yeah, it’s something that’s worth talking about

[00:06:47] where you don’t feel like you’re that empowered to pursue strategy.

[00:06:50] But definitely you can start training for it

[00:06:53] because when you’re in a position to exert some influence

[00:06:59] over the company strategy, you better have some practice.

[00:07:05] Well, it’s a convenient transition here

[00:07:08] because you have the Coding Career Handbook,

[00:07:12] which is at learninpublic.org for anybody who’s listening

[00:07:16] and interested in these topics.

[00:07:18] But I’d love to walk through some of the,

[00:07:22] like you’ve already mentioned, principal strategies, tactics.

[00:07:25] I’d love for you to kind of differentiate for me here.

[00:07:28] What are the differences between these things,

[00:07:30] principal strategies and tactics in your mind,

[00:07:32] or at least as you present them in the book?

[00:07:34] Yeah, the principles are good rules of thumb

[00:07:40] to always have on in the absence of anything else.

[00:07:45] Like if they’re just good defaults, the default behaviors

[00:07:50] that I find are more rewarding than other default behaviors.

[00:07:53] So I try to stress them as much as I can.

[00:07:55] Obviously you don’t always have to follow them,

[00:07:57] but they’re just good ideas to live by.

[00:08:03] You cannot even call them good algorithms to live by.

[00:08:06] After principles comes strategy.

[00:08:07] So if principles are always on, then strategy is not always on

[00:08:13] because I don’t expect engineers to be full-time strategists.

[00:08:16] That’s a separate job.

[00:08:17] But I think that when you’re making large,

[00:08:22] one-off, irreversible decisions,

[00:08:24] then strategy starts to matter quite a bit

[00:08:27] because then it becomes the domain of more finite games

[00:08:29] than infinite games.

[00:08:31] Then finally, tactics are one-off,

[00:08:34] but they’re small instead of large.

[00:08:36] So they’re just things that you do a lot of

[00:08:38] that you would like to do better.

[00:08:41] And might positively impact your career,

[00:08:44] but they’re sort of relatively commoditized skills

[00:08:47] like speaking or writing and marketing yourself.

[00:08:50] These are still important, right?

[00:08:52] But they’re not in the domain of strategies or principles.

[00:08:55] So that’s kind of how I break it down.

[00:08:57] And then at the end of the book,

[00:08:58] I actually draw a very helpful diagram,

[00:09:00] which I kind of bury the lead, but it’s kind of on purpose

[00:09:03] because I think that you have to go through the journey

[00:09:06] in order to appreciate it.

[00:09:07] So tactics help you in your current job.

[00:09:12] Strategy helps you in your career.

[00:09:14] So a chain of jobs.

[00:09:17] And then principles help you in your life as a person.

[00:09:21] There’s a one-to-one matching of each of those.

[00:09:26] It strikes me that I think the way I’ve seen similar breakdowns

[00:09:32] to this is that you kind of choose,

[00:09:35] you go the other direction in choosing principles

[00:09:39] that will birth your strategies.

[00:09:41] And then based on your restrictions,

[00:09:44] you can choose tactics to accomplish those strategies.

[00:09:48] And it’s kind of this like nested OKR style kind of structure.

[00:09:53] Yeah, exactly.

[00:09:56] So like, I think a lot of people focus on tactics

[00:09:59] because those are more objective and more easy to share.

[00:10:04] But that’s the lowest level.

[00:10:07] If you’re overly focusing on tactics

[00:10:08] and you have your principles and strategy wrong,

[00:10:10] then you’re not going to be as effective

[00:10:12] as if you focused on those more fundamental things.

[00:10:15] So yeah, I absolutely do believe

[00:10:17] there’s some level of nesting there.

[00:10:20] You did mention something earlier

[00:10:21] that I want to bring into this discussion

[00:10:23] and see how it fits in.

[00:10:25] You mentioned the idea of a policy, right?

[00:10:29] And this is when we were talking about strategy.

[00:10:31] But I think what I’m interested in, I guess,

[00:10:34] is these guiding policies that an individual might choose.

[00:10:41] I’m wondering how you see values fitting into this picture,

[00:10:46] because for some people,

[00:10:48] they might conflate the idea of principles and values

[00:10:52] as an example, right?

[00:10:56] For me, looking at this picture,

[00:10:57] I see values as kind of this filtering mechanism

[00:11:01] on all three of these,

[00:11:03] or perhaps on, yeah,

[00:11:06] I’m not sure exactly how it fits, honestly.

[00:11:08] And that’s what I’m wondering.

[00:11:09] How would you put values into this picture, if at all?

[00:11:16] I haven’t really thought about it that much.

[00:11:17] I kind of conflate principles and values,

[00:11:21] if I’m being honest.

[00:11:23] So they’re the same thing to me.

[00:11:25] I think a principle life is one that lives with values.

[00:11:30] But I don’t really focus that much on it.

[00:11:32] And it’s something I do care about, for sure.

[00:11:36] Having a clear value stack

[00:11:40] and understanding what you value over others.

[00:11:42] And maybe it’s a future version of the book.

[00:11:50] This is my first year doing this.

[00:11:52] And it’s a very uncomfortable thing to do

[00:11:56] because it’s so widespread.

[00:11:57] Like it literally is like,

[00:11:59] please span all the non-technical aspects of coding careers.

[00:12:04] But yeah, so far I have it down to three things.

[00:12:06] In fact, there was one entire section of the book

[00:12:08] that I did not write, which is concepts.

[00:12:11] And you may have just given me an idea for a fifth section,

[00:12:14] which is values.

[00:12:18] I did talk about, so one thing I do stress

[00:12:21] in terms of my thinking

[00:12:24] is that when you do take technology choices,

[00:12:27] when you pick frameworks, when you pick languages,

[00:12:30] a lot of people talk about picking languages

[00:12:34] or frameworks based on performance features

[00:12:36] or syntax, things that you can sort of see in code.

[00:12:42] But again, actually the more fundamental disagreements

[00:12:46] usually come from disagreements in values.

[00:12:49] And so if you don’t value the same things

[00:12:52] as the community or the maintainers of a thing value,

[00:12:55] then you will eventually grow to dislike that framework

[00:12:59] or that language.

[00:13:00] So I gave some examples of, for example,

[00:13:03] the original creators of Node.js and Express.js,

[00:13:07] TJ and Ryan Dow.

[00:13:10] They both left because their values conflicted

[00:13:13] with the community that eventually formed around

[00:13:16] the very things they started to create.

[00:13:19] Weedo Van Roosum from Python

[00:13:22] stepped down from being BDFL Python

[00:13:24] because he disagreed with the values

[00:13:26] of the community that he formed.

[00:13:28] It’s a very common thing for creators, I guess.

[00:13:33] But also, I guess, when you choose a language

[00:13:39] or a framework or library,

[00:13:41] you’re also choosing the values

[00:13:43] of the maintainers of those things.

[00:13:45] And eventually you’re going to suffer

[00:13:46] if you don’t agree with values.

[00:13:49] Yeah, or at least you’re going to have to find common ground

[00:13:52] and deal with the differences.

[00:13:55] And that seems to be a difficult thing to do

[00:13:57] if there is a large enough gap between your values

[00:14:01] and the values of that particular thing that you’ve chosen.

[00:14:06] And I, like you, I think I see principles

[00:14:09] and values at least overlapping for me.

[00:14:13] And some of that is because some of the principles

[00:14:18] that I choose are more about kind of heuristic,

[00:14:22] you know, like you mentioned,

[00:14:23] they’re kind of like good ways, good patterns of thinking.

[00:14:27] But those are only good patterns of thinking

[00:14:29] if you also ascribe to this other kind of arbitrary value, right?

[00:14:36] That value is somehow accomplished

[00:14:38] by holding to that principle.

[00:14:40] Whereas other principles are kind of derived principles, right?

[00:14:43] They’re observed in nature

[00:14:46] or there’s some kind of mental model

[00:14:48] that is outside of something that I choose.

[00:14:54] For example, a scientific approach

[00:14:56] or a scientific method might be,

[00:15:00] and I don’t know, maybe it fits somewhere else.

[00:15:03] Maybe it is part of strategies or tactics, I’m not sure.

[00:15:06] But it seems like having a scientific approach

[00:15:08] or iterative approach could be considered a principle

[00:15:12] that is somewhat devoid of values.

[00:15:16] It could be, yeah.

[00:15:19] Today’s episode is sponsored by New Relic.

[00:15:21] New Relic is observability made simple.

[00:15:25] Monitoring a complex digital architecture

[00:15:28] typically takes a dozen different tools

[00:15:31] and they’re all over the place.

[00:15:32] You have to keep track of all your logins,

[00:15:35] probably have multiple different ways

[00:15:37] of doing two-factor authentication

[00:15:41] and it just takes forever to try to track down an issue

[00:15:44] or bring together the stats

[00:15:47] that you need to bring together to create a report.

[00:15:50] Troubleshooting means jumping between

[00:15:52] all of those dashboards and data

[00:15:53] to get the information that you need

[00:15:56] and by the time that you do that,

[00:15:58] you probably aren’t really responding quickly

[00:16:00] and kind of defeats the purpose of observability.

[00:16:03] New Relic wants to change that

[00:16:05] and they’ve designed everything you need in three products.

[00:16:08] The first is a telemetry data platform,

[00:16:11] which creates a fully manageable

[00:16:12] schemaless time series database

[00:16:15] of all of your data from any source.

[00:16:17] The second is a full stack observability

[00:16:19] for analyzing, visualizing

[00:16:21] and troubleshooting your whole stack

[00:16:23] and third is the brains of it all,

[00:16:25] the applied intelligence

[00:16:26] that seamlessly automates anomaly detection

[00:16:29] and incident intelligence correlation

[00:16:31] using AI and ML.

[00:16:33] Best of all, you can get it for free.

[00:16:35] There’s no host-based pricing,

[00:16:37] no constant upsell,

[00:16:39] just a hundred gigabytes a month

[00:16:41] to one full access user for free.

[00:16:43] Check it out at newrelic.com.

[00:16:45] New Relic is observability made simple.

[00:16:50] So I think this is such an interesting way of thinking,

[00:16:54] but I’d love to talk about maybe one or two

[00:16:56] of the spot checking here

[00:16:59] in the principle strategies, tactics.

[00:17:02] Is there anything that you feel like

[00:17:05] is your kind of strongest or most,

[00:17:12] I won’t say most appreciated,

[00:17:13] maybe your favorite principle or strategy

[00:17:16] or tactic that you talk about in the book?

[00:17:18] Yeah, I think I’m best known

[00:17:20] for the learning public principle

[00:17:21] and that’s an essay that has been

[00:17:24] basically kicked off my weird,

[00:17:27] non-technical advice writing career,

[00:17:29] but the follow-up to that is my favorite.

[00:17:32] It’s called Pick Up What They Put Down

[00:17:34] and it’s a prescription for people

[00:17:37] getting started learning in public

[00:17:38] because a lot of people get inspired by

[00:17:43] trying to do more stuff in the open,

[00:17:45] but then they don’t know how to do it.

[00:17:48] And so this is a six-word piece of advice

[00:17:51] that will guarantee you feedback,

[00:17:54] will help to focus and choose topics for you.

[00:17:58] And basically it’s the idea that

[00:18:00] if you want to guarantee feedback,

[00:18:01] you should respond to what your mentors,

[00:18:04] your prospective mentors are putting out.

[00:18:06] There are people at the tops of their field

[00:18:09] are by definition very, very busy,

[00:18:12] but they’re also always putting out work

[00:18:14] and a lot of times the feedback is very limited

[00:18:18] because everyone has their own lives going on

[00:18:21] and the majority of people are passive consumers.

[00:18:25] So it takes some non-laziness to be active,

[00:18:30] respondent and participant.

[00:18:31] So what am I talking about?

[00:18:33] I’m saying whenever you listen to a talk

[00:18:36] or hint, hint a podcast,

[00:18:38] you might want to write some takeaways and share it.

[00:18:42] Whenever you see them put out a blog post,

[00:18:45] you might want to kind of go through that.

[00:18:48] If they put out like a demo,

[00:18:49] you might want to go through the source code

[00:18:50] and give some feedback.

[00:18:51] You might even spot some bugs

[00:18:53] and so on and so forth.

[00:18:55] Like if they put out a book,

[00:18:57] work through it and call out your top five takeaways.

[00:19:02] What that actually gets you is that

[00:19:04] they’ll probably read it

[00:19:05] because they’re very highly attuned to early feedback

[00:19:07] and that’s where it’s most valuable.

[00:19:09] So you’re coming to them and helping them

[00:19:11] with the one thing that you have,

[00:19:13] which is a bigotter’s mind.

[00:19:15] And so you can get access to very top people

[00:19:19] out there field that way

[00:19:20] because there’s just not that many people who do it.

[00:19:22] So it’s kind of a hack.

[00:19:24] And what’s also great is that it starts off

[00:19:27] your content creation career

[00:19:30] because you don’t have to come up with topics.

[00:19:32] You just respond to other people.

[00:19:34] And when people read your work,

[00:19:36] they don’t really care who you are.

[00:19:38] So you don’t have to be an authority on anything.

[00:19:40] You can just summarize other people’s work

[00:19:42] and it’s valuable in that sense already.

[00:19:46] And so your authority is kind of derives from them.

[00:19:49] So eventually if you do this enough

[00:19:51] and you do a good job,

[00:19:52] then they start to regard you as a collaborator

[00:19:55] and eventually your friend and peer.

[00:19:58] And at some point, hopefully,

[00:20:01] you start to see their flaws

[00:20:03] and you start to disagree with them.

[00:20:04] And maybe you’ll be your own expert in authority

[00:20:09] in that sense.

[00:20:10] But I think that’s a very reliable

[00:20:12] and fast way of coming up in any particular field.

[00:20:17] Yeah, wow.

[00:20:18] So what’s so interesting about this,

[00:20:21] it’s packed full of good advice

[00:20:24] and I think a lot of kind of built-in wisdom.

[00:20:26] I like that it’s a principle

[00:20:28] because it works as a heuristic, right?

[00:20:30] It’s a way of saying,

[00:20:32] okay, if you’re not sure what to do,

[00:20:35] just go follow behind the people

[00:20:39] that you aspire to be more like, right?

[00:20:43] And listen to what they’re saying

[00:20:45] and then consume and then respond to it.

[00:20:50] I think this is so insightful.

[00:20:52] And I think one misconception that people have

[00:20:55] right off the bat about the people

[00:20:59] that they aspire to be like

[00:21:01] is that they’re way too busy

[00:21:02] to ever see anything that they say, right?

[00:21:05] This is a very common misconception, I think,

[00:21:08] about anybody in the public sphere

[00:21:10] that’s gotten more than the average attention

[00:21:14] is that they’re too busy.

[00:21:15] They’ve suddenly become a superstar,

[00:21:18] untouchable kind of person.

[00:21:20] And that’s simply not true.

[00:21:22] A very simple example is all of the podcasters

[00:21:26] that I know, when they get messages from people,

[00:21:29] myself included, when I get messages from people,

[00:21:32] it’s very rare, believe it or not.

[00:21:34] It’s very rare to get a message from somebody

[00:21:36] who’s just saying,

[00:21:38] this is not me asking, by the way,

[00:21:39] for a bunch of delusion messages.

[00:21:41] No, yeah, it’s just true, it’s just true.

[00:21:46] It’s not as often as maybe,

[00:21:48] I don’t know what it is that makes us think this,

[00:21:52] but it certainly is a pervasive kind of picture.

[00:21:56] And so it feels like a very distant place

[00:22:00] that that person is living in.

[00:22:01] And it’s really not, it’s really not.

[00:22:03] It’s very likely that you could write an email

[00:22:05] to that person and they will read it like the same day.

[00:22:10] They’re very much like the rest of the rest of us.

[00:22:15] So I definitely,

[00:22:17] I think I’m going to take this advice for myself even.

[00:22:21] Going forward, so thank you for sharing that.

[00:22:24] Is there any other point in the book

[00:22:26] that you would like to bring out?

[00:22:29] And maybe for the people who are skeptical that it’s for them,

[00:22:36] like say, for example, I’m a software engineer

[00:22:39] that turned into an engineering manager.

[00:22:42] What part of this book do you feel like is most relevant

[00:22:45] to people who would identify in that same role,

[00:22:48] the engineering manager role?

[00:22:49] Well, I would not feel qualified to make a judgment on that

[00:22:56] because I’m not an engineering manager.

[00:22:58] So this book was very much focused

[00:23:00] on the junior developer to senior developer transition

[00:23:03] and to get them up that curve in a sustainable,

[00:23:06] repeatable, healthy way, not to get them out fast.

[00:23:10] I think a lot of books and advice focus on speed.

[00:23:14] And I objectively did a fast job of it myself,

[00:23:19] but I think that what we care about is sort of things that last.

[00:23:24] So I care about lasting more than being fast.

[00:23:29] There’s some sort of rhyme there, which I was trying to work out.

[00:23:32] But I think that the final topic that I end on

[00:23:37] is kind of true regardless of who we are.

[00:23:40] And it’s this idea that I call the operating system of you.

[00:23:44] It’s a very catchy title.

[00:23:45] I was very proud of it when I thought of it.

[00:23:47] And I’ve given a couple of talks on it,

[00:23:48] which we can send people to if they’re interested.

[00:23:53] But it’s this idea that let’s say there’s some error rate

[00:23:58] on the principles, the strategies, the tactics that I publish.

[00:24:02] So let’s say half of them are wrong, half of them are right.

[00:24:04] You don’t know which one to follow, whatever.

[00:24:08] So let’s just assume for a second that we had from God,

[00:24:13] from whatever your absolute source of truth is,

[00:24:17] let’s just assume that we had perfect advice, perfect information,

[00:24:23] the best courses, the best principles, the best strategies, the best tactics.

[00:24:27] Would you be able to incorporate it in your day-to-day life?

[00:24:30] And the answer may be no, and it would certainly be no for me

[00:24:36] because I don’t have a system to process and incorporate that information.

[00:24:40] We are so good at consuming information

[00:24:43] because we have an information overload society.

[00:24:48] But what we need to do is actually have an operating system

[00:24:51] to process and implement those things, which we think are good ideas.

[00:24:55] So it’s very much like if I don’t do this,

[00:25:00] then the preceding 39 chapters will be completely wasted

[00:25:04] because you would just have read a bunch of words.

[00:25:06] It would have gone into your short-term memory and then it will have left

[00:25:10] and you will be left with a shorter life.

[00:25:13] And that’s not what I’m going for.

[00:25:16] So we need to take care of our operating system.

[00:25:18] We need to tune it.

[00:25:20] And we probably need to spend more time on it than we do, which is not a lot

[00:25:26] compared to the stuff we love to talk about like,

[00:25:29] oh, how do we get promoted?

[00:25:31] How do we pick up what they put down?

[00:25:34] Oh, that’s great. That’s awesome.

[00:25:36] But are you sleeping enough?

[00:25:39] Are you taking care of your hands?

[00:25:41] You know, when you survey the most accomplished and long-lived programmers,

[00:25:46] like I’m talking Bill Gates,

[00:25:47] when he talks about things he regrets from building Microsoft,

[00:25:51] he says he doesn’t sleep enough.

[00:25:53] He did not sleep enough.

[00:25:54] And arguably, he says that because he’s successful, right?

[00:25:57] So it’s like, all right, yeah, right.

[00:26:00] But a little bit of survivor bias or survivalist.

[00:26:03] Yeah, maybe if he did not, maybe if he slept more,

[00:26:06] he would not be successful.

[00:26:07] We don’t know that.

[00:26:09] All we have is his own judgment of what he genuinely thinks.

[00:26:14] He’s got nothing to sell here.

[00:26:16] He’s got nothing to gain from us.

[00:26:18] He just genuinely thinks that at this point in life,

[00:26:21] he does think that he should have slept more.

[00:26:23] And maybe that’s a reflection that we can take home.

[00:26:26] Scott Hanselman, who’s big in the C-sharp.net world,

[00:26:31] his career advice is take care of your hands,

[00:26:33] take care of your back, take care of your neck, right?

[00:26:37] When you survey these people who have been in this game for…

[00:26:41] A lot of advice comes from people who have been in this

[00:26:43] for five to 10 years.

[00:26:44] But talk to the people who have been in this for 20, 30, 40 years,

[00:26:48] you get a very different set of results

[00:26:50] because they care about being in the game the longest.

[00:26:53] And that’s where you are achieving the most impact

[00:26:56] and being more successful.

[00:26:58] So I do think about that a lot.

[00:27:01] And obviously, that would apply to engineering managers

[00:27:04] to round back to your original question.

[00:27:06] So that’s one part.

[00:27:09] So just to break it down for people,

[00:27:11] there’s four parts of the operating system.

[00:27:14] Philosophically, there’s the firmware, right?

[00:27:17] Which is you are operating with your physical devices.

[00:27:19] There’s your memory, right?

[00:27:22] Like how do you store your state?

[00:27:23] There’s your scheduler, which is sort of prioritizing tasks

[00:27:28] and multitasking, right?

[00:27:29] You have a bunch of applications that you’re running

[00:27:31] and hopping between them.

[00:27:33] If you have a bad scheduler, then you’re not as productive

[00:27:35] as you could be.

[00:27:36] And then finally, there’s your kernel, right?

[00:27:38] The core underlying process that runs out

[00:27:41] of all the other processes.

[00:27:42] And the kernel is kind of what I want to end with as well,

[00:27:46] is basically your drive or your motivation to code.

[00:27:51] And I see a lot of people on Hacker News,

[00:27:53] they kind of just burn out.

[00:27:55] On paper, they’re super successful.

[00:27:56] They would be like super senior staff principal

[00:27:59] distinguished engineer at Google.

[00:28:02] And they would have no joy at their job, right?

[00:28:04] They just don’t feel like coding.

[00:28:05] So that is game over, right?

[00:28:06] For your coding career.

[00:28:08] So you want to stay in the game.

[00:28:10] You want to enjoy what you do.

[00:28:16] So I think those are things I wish that people

[00:28:20] would definitely think more about.

[00:28:21] I mean, people definitely do.

[00:28:23] It’s just that it’s not something that we talk about

[00:28:25] on a day-to-day basis.

[00:28:26] And we maybe should talk about a bit more.

[00:28:29] I totally agree with this.

[00:28:31] Especially right now, a lot of people like me,

[00:28:35] you’re kind of stuck in your home

[00:28:37] and the year has happened to you, right?

[00:28:43] In some regard, you kind of feel like things

[00:28:45] have kind of swept your feet out from under you.

[00:28:50] And it’s very easy to focus on the minutia

[00:28:56] when this happens, right?

[00:28:57] It’s why we can work until 7 p.m. at night.

[00:29:01] And check our email for the remaining time that we’re awake.

[00:29:06] That’s the minutia.

[00:29:07] And we’re not paying attention to your point.

[00:29:10] We’re not paying attention to our operating system.

[00:29:13] And certainly that is the kind of thing

[00:29:15] that can wear away at that drive,

[00:29:18] at the kernel that you mentioned.

[00:29:21] And so it does make sense to take a step back and remember.

[00:29:25] And unlike computers, we are,

[00:29:27] all of these systems are deeply integrated with each other.

[00:29:33] So the things that are happening at the edges

[00:29:37] actually affect things that are happening at the core

[00:29:40] and vice versa.

[00:29:42] So I think we do have to take a step back and say,

[00:29:45] okay, what am I forgetting to take care of?

[00:29:48] Especially at that firmware layer,

[00:29:50] I think that is so often forgotten.

[00:29:54] When we’re going through stressful periods,

[00:29:58] we’re willing to put ourselves,

[00:30:00] you know, our health especially on the line.

[00:30:03] And that can be really detrimental.

[00:30:05] So that’s such a good reminder.

[00:30:07] I did watch that talk, by the way.

[00:30:09] Excellent talk.

[00:30:11] A little Easter egg for people.

[00:30:14] You do have this idea of virtualization.

[00:30:18] I don’t want you to cover it right now

[00:30:20] because I want people to go and watch the talk

[00:30:21] to find out what it is.

[00:30:23] I basically ran as far of the analogy as I could.

[00:30:27] I know, I loved it.

[00:30:28] I thought it was great.

[00:30:29] In my head, I was like, all right,

[00:30:30] so what is HTTP in this analogy?

[00:30:34] Yeah, we have communication protocols with other humans.

[00:30:38] Exactly, right.

[00:30:39] What is the networking protocol?

[00:30:41] Who’s on my local area network?

[00:30:45] Thank you so much for taking the time today.

[00:30:47] I know we’re running up right on our time,

[00:30:49] but I appreciate you sharing your wisdom,

[00:30:52] your thoughts with the engineers

[00:30:55] who are listening to this,

[00:30:56] the managers who are listening to this,

[00:30:57] and the people who have nothing to do at all

[00:30:59] with engineering right now

[00:31:01] who are listening to this episode.

[00:31:04] I think they also probably gained some insight from you.

[00:31:07] So thank you so much for taking the time.

[00:31:09] Yeah, thanks for having me.

[00:31:10] And you may be pleased to know

[00:31:12] I’ve been having tea while we did this.

[00:31:14] So let me bring some developer tea.

[00:31:17] Excellent.

[00:31:18] I’m going to pass you a coupon for some discounts.

[00:31:21] I love giving out some,

[00:31:23] like a 30% off discount for people

[00:31:25] who make it to the end of one of my podcasts.

[00:31:27] So hopefully that helps people

[00:31:30] over the hump in checking this out.

[00:31:32] Awesome.

[00:31:34] Do you have it to bring out now?

[00:31:36] Yeah, it’s learningpublic.org slash c equals

[00:31:40] and then I’ll do devt30.

[00:31:43] I’ll type it in and you can put it in show notes.

[00:31:46] Perfect.

[00:31:47] All right.

[00:31:48] Thank you so much for your time.

[00:31:50] Thanks, John.

[00:31:51] Thank you so much for listening

[00:31:53] to today’s episode of developer tea.

[00:31:54] The second part of my interview with Swix.

[00:31:56] If you missed out on that first part of the interview,

[00:31:59] I encourage you to go back and listen to it.

[00:32:01] It’ll make the second part that much better.

[00:32:04] Swix has very kindly provided us

[00:32:06] with a coupon for developer tea listeners.

[00:32:10] You can get 30% off the coding career handbook

[00:32:12] by going to learninpublic.org

[00:32:16] and using the promo code devt30.

[00:32:20] You can also find a link to this

[00:32:21] that will automatically apply that coupon.

[00:32:23] It’s just using C as a URL parameter

[00:32:27] for those of you who want to enter it manually.

[00:32:29] But that is devt30 and you’re going to get 30% off

[00:32:33] and it’s any of the packages that you find

[00:32:35] at learninpublic.org.

[00:32:37] Thank you again to Swix for joining me

[00:32:39] on today’s episode of developer tea

[00:32:41] and thank you for listening.

[00:32:43] This episode was made possible

[00:32:45] by today’s sponsor New Relic.

[00:32:47] New Relic is observability made simple.

[00:32:50] Head over to newrelic.com to get started

[00:32:53] with a full access user, 100 gigabytes per month,

[00:32:56] totally free.

[00:32:57] This episode of developer tea

[00:32:59] and every other episode of this show

[00:33:00] can be found on any podcast platform of your choice.

[00:33:05] If you would like to ask me a question

[00:33:08] and it might even be a question

[00:33:09] that I can cover on this show,

[00:33:11] you can email me at developertea at gmail.com.

[00:33:14] You can also reach out to me on Twitter at at developer tea

[00:33:17] or my personal Twitter at at jcatrel.

[00:33:20] This episode was produced by Sarah Jackson.

[00:33:22] My name is Jonathan Catrell

[00:33:23] and until next time, enjoy your tea.