Supper Club × Sarah Drasner on Engineering Management

I sure hope you're hungry.

Oh, I'm starving.

Wash those hands, pull up a chair, and secure that feed bag, because it's time to listen to Scott Tolinski and Wes Bos attempt to use human language to converse with and pick the brains of other developers. I thought there was gonna be food, so buckle up and grab that old handle because this ride is going to get wild.

This is the Syntax supper club.

Welcome to Syntax. This is the podcast with the tastiest web development treats out there. Today, we have, a colliding of 2 things that have been highly requested.

First is, can you have Sarah Drasner on the podcast? And the second The one is can you talk about management? Both of those, I I can try to get Sarah on, but I don't Really know a whole lot about management, so excited to have her on here today. She, just released a new book called Engineering Management for the Rest of Us that is,

taking the world by storm, so we're pretty excited about that. Welcome, Sarah. Hey. Thank you so much. Thanks for inviting me. It's so great to see both of you again, even if virtually.

Yeah.

Yeah. We're we're we're so excited to have you on. Just, I, you know, I picked up your book, when it first became available, just arrived. So I'm still still hammering through it, but, I think everybody was just really, really excited to see this thing hit their hit their mailbox

Right about now. Yeah. I'm I'm pretty excited to see it out too. It's been a couple of years in the making.

You know, it's Been kind of a labor labor of love here. I was really trying to write the book that I wish I had when I got started in management. So, Yeah. I've been so happy with the reception. Thank you all for inviting me here and also just, picking up a copy of the book. Yeah. For sure. Why don't you give us a quick rundown of,

who you are, your history, where you've worked, kinda how you got into management, whatnot? Yeah. Great idea.

So I'm a director of engineering for core developer web at Google. So the group that I, and the director of engineering for at Google, runs all of the web infrastructure. So TypeScript and JavaScript languages and libraries at Google, all of the frameworks, including some that are internal. And Angular is one that you might know in external.

So and a lot of the, you know, the build serve, web tests, SaaS, and CSS, those types of things. So all of the infrastructure that it takes to run some of the apps that you know and love, like search and Gmail and Docs and Mhmm. YouTube and things like that. We build all the infrastructure that powers those experiences.

Previously to this, I was a VP at a company called Netlify.

It is, you know, quick and easy hosting and serverless functions and all sorts of cool stuff.

Before that, I was a principal engineer, so more IC track, at Microsoft, and I worked in Azure.

And before that, I worked at Zillow as an engineering manager for UX and, kind of did a lot of, like, component systems that went across multiple, properties. So, yeah, I'm excited to be here.

The the reason I wrote this book is because I was an engineer long before I was a manager.

I went into engineering, Got good at that, and then all of a sudden was moved into being a lead and being a manager, and I had 0 tools. Like, It's like saying, you know, you you're really good at building bridges, now you're a baker. I was like, I have no idea how to do this job at all.

And I found that there wasn't you know, especially when when that happened for me, which was like a decade ago, that I didn't have any of the skill set necessary for that job, and yet I was thrown into it. And I think a lot of peep that happens to a lot of people. A lot of people start off as engineers, And then they're moved laterally or promoted into management, and they don't know exactly what they should be doing in a role like that. And sometimes at bigger companies, there's Trainings and things like that, but those are just things you kinda watch on the screen. It's not as, you know, hands on. And then sometimes at start ups Mhmm. There isn't a system for things like career laddering, and there isn't a system for things like performance management. And so, You know, I had a I had a bit of a rough time just, like, trying to understand what I should be doing in order to help my employees and Make sure that they were productive. And a lot of the things that the tools that I had built as an engineer were no longer applicable. Like, My work was about my work previously. Now it now it's about making everyone else productive, and now it's about being less flow driven and more interrupt I didn't know how to do all of those things, and especially because people aren't pure functions.

They're not the same.

You know? Yeah. Given different inputs on different days, you come out with different outputs, and and that was confusing to me. So there's a lot that I had to learn, so I thought I Would put it into a book in case folks wanted to read it. Yeah. That's it. That's such an interest I love that people are not of pure functions because it's like, It's so it's so hard to get that out of life. When when you talk to somebody, you could get something entirely different

based on Any number of thing that's going on in their personal life that is, you know, causing them distress and then all of a sudden their work is suffering or they're suffering or The response that they're they're giving you is more abrupt or aggressive than what you'd expect. So you got put into a a management role, and and then we're just kind of tasked With figuring it out as so many people are, is that that the case? And if so, like, how did you go about

Figuring it out. Yeah. I mean, first, I was put into a lead role.

So that wasn't, like a tech lead role. So that wasn't so far away from what I was doing previously because even though I was kind of leading the team, I was leading them because, you know, the reason I was put into that role to begin with was because I knew the most about the system. I had the most experience of, you know, the engineers on that in that group and so could kind of guide them. So that one wasn't quite As part of a transition as going into something like management where it's you know, there are some skill sets that are just not about the code base anymore, But they still help make code. Right? Like, the people systems are still critical in order to be really productive developers, in order to make really, really important and intrinsic systems, come to life. So, when When I was put into these kind of management roles, I think that the things that I had to kind of learn was Where to align with people as far as being their partner and how to understand them and their within the context of their work and visions and dreams and goals And connect that to, you know, the things that we needed to produce.

So that took a lot of time and understanding, Karen. Mistakes. I go over mistakes in the book because I, of course, made mistakes along the way too.

So,

yeah, that's that's That's kind of the framing of of the thing. That's interesting. I'm I'm curious about like, you say productive engineers in putting out code.

It's kinda funny. Like, as developers, we often think like, managers. Like, leave me alone. You know? Like, let me let me go. Just meetings all day. And, You know, and, obviously, that's not everybody out there, but certainly, I I think there's there's quite a few out there.

Like, how do how do you get out of Engineers weigh and and make them productive so that they can actually write code and get the stuff done and and write good code. Yeah. I think that the getting out of the way is a really important asking, like, how much overhead you're really

like, is necessary in order to do jobs like that, but also, so making sure that your engineers aren't stuck in meetings all day is one thing. Making sure that people have 1 on ones so that they have, you know, venues to speak to you privately about things that Might not be working within a system that you know, some some of those things are personal, and some of those things are letting you know that something there's a risk, That something's broken. That's you know, there's something to address, that maybe there's an escalation that you need to take care of. A lot again, a lot of it is Going from being flow driven to interrupt driven so that you can help unblock them.

So that's that's a major part of it. Another part is There shouldn't be real there shouldn't be ambiguity to where their career path lies. That can be distracting. Right? Like, if you're an engineer, you're working your butt off, And you're not really seeing your career progress and you don't know where this is all heading, that can keep you from being able to do good work. Like, Yeah. A job of a manager is to connect the dots between the work that they're doing and where they need to go and show Career paths and progress and and let people know with you know, under no uncertain terms so that there's no surprises that, you know, you're doing a great job when you do x. Keep doing that. Oh, you need to grow a little bit over here. This would really help the whole system or, you know, this was really not helpful. Like, we should, you know, kind of avoid this in the future. And and so, you know, Providing that clarity can also allow focus because you're not distracted by, like, hey. I'm doing, you know, 200 PRs here for this project, and I don't even know if my boss cares or

if the company cares or, like, you know? Yeah. Yeah. Yeah. So is that something that you you do when you sit down with people? You say, like, like, look, where where do you wanna be? What kind of stuff do you wanna be working on? Like, is is that something you do? I always thought, like, I should give a disclaimer if you never had a job before.

I was just out, like, of course, like, managers probably think about that, but, like, they want they need to get their stuff done. You know? Like, they have a road map of product that needs to get done, and Here we are putting out a quote. But do you do you spend a lot of time on that? Like like, where do you wanna be to be happy in this job? Absolutely. I mean, that's, like, a huge thing. I mean, in an ideal world,

People are working on things that they are excited about. Right? Like, in so, like, there's a couple of things in that. 1 is, As much as possible, what the company needs and what the person wants to be working on, like, as much as possible bringing those things together. Right? Like, making sure that the person who, like, is loves compilers, is working in a compiler space, and maybe they need to grow, you know, on in terms of refactoring. They have projects that allow them to do so. There's It's a bit of a Venn diagram of, like, what the employee wants to do, what the company needs them to do, and trying to find that sweet spot in the middle where both are happening.

Another piece of this is making sure that there's good growth. Like, people, you know, want to eventually go, You know, learn more things, grow as a person, you know, guiding them along that journey and saying like, hey. This is an area where I think if you had a little bit more And this is kind of why being an engineer first is really helpful because you if you, like, go to become a principal engineer and then move into Engineering management, you can actually see where they may need a little bit of growth, or, hey. You you know, in that CL or PR, You, you know, got devolved it devolved into a comment stream that ended up not being helpful for the work. Like, you know, some of that soft skills guidance is actually hard Skills too. Like, we couldn't get the PR through because we got trapped in this, like, never ending social situation.

So guiding them along those journeys and And leaning on things that you've kind of seen in the past. And then the last thing I would say is, like, in trying to find where they're gonna where they wanna go, learning about people's values can be really helpful because not everybody's built the same. And making the assumption that everyone's gonna be just like you Can be a little off base. Like, people have things that matter to them either because of experiences in their lives, that's how they're raised, or, like, Things, you know, happen that made them really value something over another thing. And making sure that people first of all, you understand their values and then also, like, You're honoring their values because what I've noticed is that people don't burn out as frequently from Lots of work as they do from values misalignment, and they can absolutely burn out from too much work. But when I personally burn out at a job, It's usually not because I was, you know, clocking in every day. It was because something was going on where I wasn't, like, living The things that were important to me, and I needed to find another job where those things were appreciated.

So Learning people's backgrounds and experiences, their values can can help on that guiding

journey and help, especially when people are trying to resolve conflicts and understand each other's perspective. And that makes a lot of sense if you consider, like, just in general motivation. Right? Like, What what pushes people to want to do good work? It's just like, why would you want to support this company if this company is not Aligned with your values or what you're wanting to do in general in life. So I that that totally tracks for me.

Did did you spend a lot of time, like, thinking about managers that you've had that were really good in the past? I know I I could put, Like, all of my managers kind of in a timeline of who rules and who is not so good at their job. But, like, is that something that you really put into consideration when you became a manager? It was like, Who who did a really good job for me, and what lessons can I learn there? Yeah. Absolutely. I mean, those are the experiences I had to draw from, for sure.

I think also, like, thinking through I have some peers who are managers. So thinking through, like, there's there are a lot of people that I know that I really look up to. And so understanding their perspective and behind the scenes what they're dealing with, making kind of like a manager cabal system so that there's Other managers that you can kinda lean on and soundboard off of, it can be really helpful. You'll note in the book that there's some quotes from some such people. Like, one of them was from my friend, Ashley McNamara, who's a great manager at, she's at Google now. She used to be at Microsoft. We worked there together. And, You know, one day I came to her, and I was like, you know, I'm really worried, like, going into management that I'm gonna, like, mess something up, and, like, these are people, and and that gives me some stress. And, like, I don't really I don't wanna negatively impact people.

And she said, you know, I'd be worried if you weren't worried, because the thing is is you are, you know, caretaking over other people and affecting other people's lives. So it's a good Sign if that actually is something that you're thinking about and reflecting on.

So yeah.

That's kind of a good Sign in general for growth as a person. Right? If you're a little freaked out about what you're you're doing, that's, like, usually a good sign that you're headed in someplace where you'll get to grow. Yeah. A 100%.

I think the last thing there is just, like, making sure that you're aligning folks to the whys of their job, and that is something that, like, I looked back on other leaders and other leaders that I've seen around, who did a really good job of connecting the whys of people's work so that You kinda they know the gauntlet is thrown, but they're not micromanaging the how. Like, that was something that I really had to, like, learn and and was hard. It's it's hard to Sometimes it's easier if you're a very senior engineer. Just do the work yourself.

So you kinda, like, wanna dive in and just fix it.

So, like, taking a step back and looking like like Scott says, looking at the other leaders that I've seen not micromanaging, be able to throw that gauntlet,

really helped. So a question about coding and managers. This is kind of 2 part. Should managers Code and do how much code do you write on a day to day basis, if if any at all? I I think that it really depends company to company.

There are some small start ups that are super scrappy where, you know, you have, like, 4 people on a team.

And If the manager was just managing those people, they wouldn't be able to, you know, produce a lot. I've definitely seen that situation.

I don't think that even in those cases, that coding should be the most important thing to the manager. The most important thing to the manager should be Making sure everyone else can be as productive as possible.

So getting out of the kind of critical path, and making sure that they're not blocked if the manager has to be in meetings, things like that.

Typically, though, not really. Like, in good larger systems, you don't have managers who are coding so that they can unblock, so that they can be in meetings, so the engineers are not in meetings. Like, in a in a good kind of World people aren't, like, you know, so deep in the weeds that they can't look back at the whole system and help facilitate things. And that job is still about the code. Right? Like Mhmm. If there's an escalation, if there's something that's not working, if people aren't getting along and so they can't collaborate on a project, That is still coding efforts.

So I would say it's not exactly, like, 1 to 1 of, like, Literally writing the code makes for code.

Looking over people's systems and making sure that everyone can be as productive as possible Still relates to the code. So know that in those systems, managers should focus on making sure that everybody else can be unblocked for their work, but they can provide value in so many ways

that help facilitate the best code possible by that group. And what about you? Are you still coding day to day, or do you dip into doing demos and and whatnot every now and then?

You know, as a director, I am in meetings a lot that help unblock the team, so I'm not coding on a day to day except for to understand the work of my team.

So Mhmm. Like, one such example is, like, making sure that I understand all of the different framework proposals.

I read a lot of design documents and kind of get involved in that way.

I do kick the tires on some APIs and things like that, but I'm, Again, I'm not coding in the critical path anymore. I have a 125 people on my team. So Wow.

If I could Really easily block a lot of people by coding. And the value that I provide at a director of engineering level, You know, looking over systems of systems, like, I, you know, I manage many managers. I manage many lay layers of managers. If I was coding, I wouldn't be able to be unblocking them for escalations that I'm much more useful for.

If there's something with a customer team That, you know, customer PA that we have to work out, I'm much more useful to them to unblock the entire project than to write a few lines of code.

So Yeah. That's that's kind of where things are at. I'm a naturally curious person, so I do code on the side to kinda understand things. But I wouldn't say that that's, You know, typical or critical for my role either. Was it hard for you to step out of

the coding space? I know me personally.

I am the type who would block people just because I I have some sort of like, oh, I want to do this. You know? I I'm I'm a little bit distractible in that way.

Was it hard for you to to step out of the coding space and say, okay. Now I understand

Blocking and unblocking and all that stuff. Was that was that difficult? Oh, yeah. Absolutely. And this is also why I do the kind of pendulum thing.

Some years, I'm focused on management, and then I go back to IC work, and then I go back to management. I think Charity Majors calls this the managerial pendulum.

She has a great article about this because I get burned out from only coding because it's not as strategic as I would like to be sometimes.

I can drive strategy at my level in as a director way easier than I can if I'm, you know, we way deep in the weeds. But on the other end of things, I miss coding sometimes, so I'll go back to IC work. Like, I would imagine like, I'm I'm where I am right now, and I'm happy in my role. But I would imagine after this, the next thing I'll do is IC work.

I definitely had to make this mistake where I was Always trying to cope. Like, again, I you know, there were definitely projects where I could speed the project up by just getting by doing it myself.

And even, like, we're probably on this podcast and know each other more because of my code than because of my management.

So, like, that's, You know, how I got involved in open source communities and even where I am today.

So I I love coding. I, you know, Love I miss it if I don't do it enough.

However, I'd still have to be a responsible caretaker of the people system and understand that My personal desires are not the thing that's most valuable to my team. What do you think about this,

thing I've heard all the time is people don't Leave bad jobs. They leave bad managers. Is is that true? Like, why do people leave jobs? Yeah. I mean, I think that that's it's a very real statement.

I think There's a lot of times where it it it does fall on the management staff. And sometimes it's like even if it is a problem with Not understanding the whys or the company has different values than the person or, you know, though you know, people systems didn't, You know, address conflict well. Those are still managerial duties. Right? So I I do think that there's a lot of truth in that statement, and that's part of the reason why, you know, Be being a manager is once very, very exciting because you drive a lot of strategy. You help whole groups of people be productive Rather than just 1 or 2 people, you can affect a system of people. Those things are really, really exciting things to be involved in, but they are also Tough. You know? That's that's a tough task. Mhmm. And sometimes, you know, even with the best intentions, things fall over, or, you know, people don't understand The context of their job outside of themselves and, like, thinking through things from the, you know, their employees per perspective. And so I think that that That does end up being true, and that's also why the managerial work is critical, to keep everybody swimming in the same direction, working really Productively and well to, you know, create things.

So do you get into conflict management at all? Like, I I I would imagine that's, like, One of those side parts of the job that nobody thinks about until you have to think about. But is conflict management something that comes up quite a bit? And if so, like, how did you Deal with having to learn to deal with conflict amongst employees. Conflict management is definitely a part of managerial work. I think in the book, I say, like, It's one of those parts of the job that you

don't realize it's part of your job until it, like, lands in your lap, and you're like, oh, Yeah. Right. These 2 people are getting along, and now this is my job.

So I I do think that that can take People by surprise. That's why I have a bunch of chapters that kind of address things like that are tools for a conflict, things like How to give feedback, things like how to facilitate meetings where things are really stressful and people aren't getting along, or there's things that people aren't addressing, like there isn't Conflict where they probably should be conflict.

And, so, like, go into a lot of depth and detail for some of the tools I've used, just to, you know, be transparent and give people some some tools that I wish I had again when I first started managing because It's, it's tough. You know? Like, it there are there's a lot of ways of debugging people systems, and they're not exactly the same Tools as debugging a code system. Sometimes they're a little similar, but sometimes they're not. I'm thinking back to, school. So I went to school for a business degree, and one of the One of the,

classes we had was just entirely on change management, which is basically, like, people don't like change, And sometimes you gotta shake things up. There's reorgs, there's some big billionaire comes in and fires almost half the engineers on there. Do you have any tips on how to handle big shake ups or or if there's layoffs or something like that in in a organization?

Typically, you know, you wanna use different tools for different types of communication conflict, those kind of, like, big organizational changes.

It is important to have trust baked into the system. If you can build that first, that could be really helpful. But you wanna give people venues to both address things individually and locally and also, you know, in a group. Because sometimes people will bring things up individually that They don't feel comfortable bringing up in a group.

Sometimes in a group, it's really useful to bring things up in a group so that everybody's Understanding the same perspective, some changes are best planned out and then happening quickly, like Reorgs, for instance. You don't want a situation where, like, a reorg is sort of announced. It's kinda globby. Nobody knows what's happening. It It doesn't move for a long time. You know it's coming. Like, that can create a lot of uncertainty and peep and, like, make people less productive because they're like, wait. Is this code base even what I'm gonna be working the future, like, what's going on here? Yeah. So so for those kind of organizational changes, sometimes it's good to do a lot of prework with a smaller, more private group, And then rip the Band Aid all at once. Like, make sure that the movements happen swiftly so that people don't lay in ambiguity. And I think A lot of managerial work for change management has to do with providing clarity where possible. So, like, listening, hearing all of the parts that people may bring to you because they may see parts of the system that you don't. In fact, I would say any good manager probably doesn't see all parts of the system, so has to rely on their staff to understand some risks. And then, you know, there are situations where you wanna take it slow, and then there are a lot of situations for org change Where you wanna address things more swiftly so that people aren't laying in an ambiguous uncanny valley and know exactly what their work is doing, Where up is, what, you know, success looks like, and things like that. Awesome. That's great. What about,

scrum, Kanban, all these approaches. Do you have any opinions on, on

do you use these? Do you have any opinions on them? So many opinions, I I don't know if my opinion really is, like, what matters. I think it what you know? Like, again, like, being a director of in caretaking a large system of people, a lot of my groups don't do things exactly the same way. And that is okay, because The thing that's important is that we create a system that helps the people work most productively. And if The system itself is getting in the way of people's work. That's not good, obviously.

If the system itself is making people have to be in too many meetings and communicate too much, that's not good, Obviously, really, what we're trying to find is the appropriate system that has the least friction possible and provides the most clarity to the most people in order to plan together. And that might change per group. Like, if you are doing a 100% UI work, you may need and you're, like, working aggressively with, like, Feature product man managers. You may need a different system than people who are working on a compiler refactor that's gonna take 5 years. Right? Like, those are 2 completely different planning processes, and it's it's okay and natural for them to be a bit different. So I guess what I would say is, like, Yeah. I have my own personal opinions on these systems as a former engineer and future engineer and also as a caretaker of these systems.

But It what really matters is that we constantly evaluate, like, and do retros that like, Is our process the process we should be using? Should we is there something that we could be doing that's less, you know, tough to work through. Is there a way that we could be communicating that's has less friction? Because setting up that information flow, That can actually help reduce conflicts and and other things that are can arise. So that's that's a tool for those systems.

Can can you explain retro? Yeah. I was gonna say, for for those of you, for listeners out there who might not know the word retro in terms of, like, context here. Do you wanna maybe give an explanation as, like, what what is a retro

and what makes a good one? Yeah. I, you know, I think a lot of people use the term like blameless.

I think that the the reason why we say blameless is because We want to be able to evaluate a system in a psychologically safe way to be able to say, yeah. I did this, and it wasn't quite right, And I would do it differently another time. And so if we're all able coming to the table with, like, really just trying to evaluate the process itself and not point fingers at people, We're more capable of kind of figuring out what systems are serving us and what aren't. There's a There's a great book called Accelerate by Nicole Forsgren and Jess Humble and, you know, a couple of other authors that talks through, you know, they did analysis of kind of DevOps, like and what systems ended up what cultures and people systems Ended up being the most productive. And probably surprising no one, the systems where people felt the safety to address the issues and concerns and risks ended up having the least amount of failures.

They ended up having the least amount of outages.

They ended up having the most healthy, and the least brittle systems because people weren't scared to bring up the elephants in the room. And so when when conducting a retro or course, postmortem, depending on what company you're gone you're at and what they use, you may wanna deploy a a few different systems. Sometimes I'll send out an anonymous feedback form that's like, what do we do well? What could we have done better? What should we do next time? And I take those inputs, and I I take whatever people said, and I group them by topics so that we can go through them in a meeting and people don't necessarily have to feel like they They can provide feedback anonymously. Now if you're in a smaller group, it might not make sense to do something like that. Maybe you've built enough trust to just address it head on, which is great.

You still wanna kind of reinstate that the purpose of it is of, like, a retro is to Come to the table without blame, without judgment so that we can improve on our systems and also to encourage everybody to understand that it's not a television show. Everybody should be participating.

If you don't think it's going well, you're an active participant in making things better and bringing things up. And I think that that Saying that out loud can also help people go from, oh, I'm attending a meeting to, like, participating in the meeting and making the meeting a bit better. It's a conversation. Right? Yeah. Yes. Yeah. Awesome.

Let's switch talking about writing a book.

How did you write the book? I'm very curious about that. Like, what's the process of doing that? Yeah. So this is my 2nd book I wrote For O'Reilly before, a book about SVG.

And Yeah. So, like, that they have this whole, like, Author portal where you log into a system and you fill out the chapters, and I I wanted something like that.

But, you know, I wasn't working with O'Reilly this time, so I I was just writing it from scratch. I didn't know who I was gonna use as my publisher when I first started kicking it off. So I used a tool called Scrivener, and that tool is great.

What it does is it kind of allows you to plot out The book in sections sort of like a Post it note, and then you can restructure those Post it notes.

And those Post it notes become the chapters.

So you could kind of, like, think through the overall structure of the book without thinking through the details.

So it's kinda like when you take a big Coding project, and you break it up into parts or systems of modules or things like that.

You can also, tell it, You know how long you want the book to be? I wanted it to be around 40,000, you know, words. I looked up a bunch of Books and you know, that were around the length that I wanted to write. And so plug that in, and it will say, how long do you wanna be writing this for? And I said, like, okay. 3 months, and then it broke down. Okay. You need to write this many words a day. And it has a little slider at the top that, like, as you're typing that day, then it will let you know when you hit your word count goal for the day. So I just made sure that I was writing that small amount every single day.

And what I also found was that once I got going like, the hard part was starting. So if I made myself do it every single day, Then I got over the word count pretty quickly because once you are starting and going, you kinda keep going.

So I wrote it faster

than I think I thought I would. That's that's great. And what about publishing it? How how did you publish it? Like, it's a physical book that you can buy and hold in your hands. Yeah. So,

some of y'all might be familiar with Egghead. They make really amazing courses, and, do fantastic work.

They have spun up a different division for kind of Book writing and publishing.

It's called skills recordings.

They they also do like online workshops with the skills recordings label.

So, you know, I worked with Joel Hooks from Egghead, or skills recording, and he outlines, like, Here's what it would be like to publish together. Here's what we could be doing. Like, here's what we would handle and what you'd handle. And and I was like, great.

We did a lot of rounds of editing together and things like that. So I had a structural editor and a copywriter, Our copy editor.

I actually use the same copy editor from, like, my O'Reilly days because they were just so awesome to work with.

So definitely like that. You know, finding good editors that you can work with really well is really critical because you have to go through the entire book with a Fine tooth comb every single time, every single round of edit. So there were, like, I think, 4 rounds of edits, and that that process took longer than writing.

Because Even for the structural things in particular, it was like, wait.

Maybe maybe people need this information first before I get into this other part. And it's it's hard to do that on your own. Like, you kinda need another person to be like, this doesn't make sense until

You say this part. So yeah. Wow. That that's really cool. It it's interesting how you don't necessarily have to go I guess, They are a publisher, but you don't necessarily have to go with 1 of the traditional publishers, any longer because I I was seeing they use some sort of service that will just Print like the u u is there a warehouse somewhere with a bunch of the books, or are they print on demand? How does that work? Yeah. They worked with,

A design layout publisher people called Mayfly, I think they're called, who helped lay out the book and, like, you know, helped us do the physical printing and things like that. And then from there, I think, Joel and skills recording made sure that those copies end up in Amazon.

I don't know too much about that process, To be honest, because what I was on the hook for was more in, like, the kind of writing, editing, and, like, proofing the layout part.

But yeah. Okay.

And did you design the cover on it? No. No. I found a designer, like, actually before the book was fully written because I was just getting really excited about it. And I knew that, like, Having a cover that made me, like, excited would keep me on track to finishing it. Like, At the time, it was just kind of like a glob of, like, word poop.

It's like I was like, I'm never gonna stay committed to finishing. Like, because there are times in the writing process, it's it's a slog. Like, it can be really, you know, tough to get this Stuff over the line, and it's a long project. So there was a point where I was like, if I don't, like, hire somebody to write To make, like, a cover I really like, I'm not gonna get it over the line.

I'm not gonna, like, commit fully commit. So I did do that.

They kind of inspired me.

I draw sometimes, so I did all the the part and, the part illustrations that are in there. Mhmm.

So some of it some of the drawings inside the book are mine, and the cover is, this really, really wonderful designer that I can give you the Contact them. Yeah. That design design,

has got a lot of people talking because I think it stands out, especially amongst dev books, which Can be either very uniform or or or bland or maybe just kind of I I don't know if you go to Amazon and look at any sort of developer based book. They They don't look like your book cover looks. So, I think, finding that designer was really great on your part, just because of as so many people are talking about the cover, what about, like, physically typing the the book? Did you type It in word, or where did you type the bug? In Scrivener. So Scrivener is actually a tool. Yeah. So it's actually a tool

where you it's basically a word processor, but it gives you a little bit more bells and whistles that it understands that what you're trying to come out of it with is a book. I tried At first, I just used Google Docs, but it was a little overwhelming, and I couldn't understand the whole structure of the thing.

So Scrivener ended up being like I think it Cost like $25 or I forget.

But, you know, it it ended up being a really worthwhile investment.

So that was definitely a thing. I also You know, having come out with the physical book before, I felt like one thing that I don't think I'll ever Forget is that feeling of holding the physical book. So part of the reason why I went with, like, a design that I was really attached to was because I wanted to make sure that I felt that feeling. Like, that when I'm holding the hardcover, it feels like, Okay. This is 2 years of work of my life, and now I can hold it physically and give it to someone physically. And, like, that's That's a pretty cool feeling. I wanted the cover to justify and and kind of, like, be part of that that Whole experience.

What so you said about 2 years. Is that that about the the total length of the the process start to end?

Yeah. I think it was about that. Like, I I think writing didn't take so long. It was probably 3 or 4 months. And then there was a lot of, like, editing processes and Getting, you know, mayfly set up and proofing layouts and things like that. So, like, I think everything else Took a bit longer than probably the writing process. And you you have a background in writing as well. Right? Like, you you wrote for CSS tricks for years. Right? Yeah. I mean, I'm not a writer. Like, I it's not, I've never been an author.

I think, any writing Chills I have were probably thanks in part, at least, to Chris Boyer because when I you know, I went to grad school.

When I was in grad school, I wrote really lofty, heavy papers that were just, like, just dense and horrible to read.

And, you know, like, that's kind of like what they train you to write like.

And so when I first when I wrote my 1st article for Chris, He went through and edited it in a way where it, you know, it sounded like a grad paper, and he kinda edited it in a way where people could actually read Collin 10 Yeah. Nodding off to sleep. And so after working with him for a little while, I started to go, like, man, like, what Why am I writing like this? Like, what what is the purpose of doing this? So so I think, like, he didn't, you know, outright Say, like, write more plainly, but just through, you know, like, working with him, I was like, oh, I, you know, I could stand to write in a cleaner, more approachable way and so adjusted over time. So I'm not really like a writer writer, but I have done a lot of technical writing.

You know, the O'Reilly books, CSS tricks, smashing, few other, you know, platforms like that. Ant also helped with the, you know, Vue. Js docs too.

So,

yeah, over time, I think I got a little bit better at it. Awesome. I I just don't know how you do so much. Just it's honestly amazing the the background that you have in just, like, writing for CSS Tricks and and manager and Vue. Js docs. And, like, you've you've had so many different areas of expertise in your entire career. Do do you have any Thoughts on on how you've done that or why that is? 1st, I would just say that y'all have done that too. I mean, I think about, you know, Scott doing break dancing and also this podcast and all of the thing you know, the communities that he's involved in in West. You know, you're doing

A 1000000 different courses and involved in the community in so many ways and, like, contributing, you know, talks and speeches and And bits of advice and and things like, y'all are definitely, you know, people that I look up to, you know, kind kind of coming in and doing so much in the space. I think, you know, for myself, I I'm just a really curious person. I really just love tinkering. I love playing with things. I love, You know, making things and building things, that but I I think I've mentioned this before, but the concept that I can Think of an idea, and then within 2 days' time, have a fully functioning app. It's just such a cool And so that's a that is a pretty high driving force to me. It's just to say, like, wow. Like, the things that we can do and build and make and the tools that we've we have at our disposal and fingertips. That you know, I've been a developer for 20 years. Like, we didn't have some of that stuff before.

So Yeah. I think that those things kinda motivate me. It's always more, like, you know, mission driven than deciding, like, I I didn't decide to make a book. I decided like, hey, I should write down some of these things because, you know, other people Probably are experiencing it too, or, like, working on the Vue docs was like, I think if we explain it this way, then People can get going faster.

You know, making all of the apps that I've open sourced over the years, those were like, hey. People are really you know, I'm mentoring these people. Learning JavaScript is hard for them. Maybe I can make this app that makes it a little bit less stressful, and they can, you know, explore arrays a little bit easier.

It's always been a little bit more, like, mission driven,

in that way of just learning. I think mission driven is an awesome Way to, gain motivation in that regard. Right? Because your your why is at the present, and I I think that wraps nicely around back into managerial stuff too. Right? Understanding the whys and,

getting to the bottom of all that. Yeah. Absolutely. I mean, aligning people to the whys of their work is such a crucial part of strategic leadership. So a 100%.

Totally.

So now is the part of the show where we ask you some questions that we kinda ask everybody, and these are the supper club questions. So And we have them listed as dessert, but I don't think we ever settled that as them being dessert.