In so many professions, the reward for exceptional work is a promotion to management. Unfortunately, for developers whose programming gets them singled out for promotion, the skills to manage a team have nothing to do with the work that got them recognized in the first place.
James Stanier, Director of Engineering at Shopify, understands the pitfalls of being promoted from an IC to an engineering manager, and began writing as a way to think through the mistakes he himself was making.
Today, James is an accomplished author; his first book Become An Effective Software Engineering Manager debuted in 2020, and his second book Effective Remote Work was published earlier this year.
On this week’s episode of Dev Interrupted, James talks about how developers can prepare themselves for a role in management, or alternatively, why they should avoid a career in management altogether. He also discusses why Shopify loves remote pair programming, how to find your voice as a developer and why writing a book can be a spiritual experience.
Episode Highlights Include:
- (4:06) Why so many devs are afraid of becoming managers
- (16:51) The 90 day management test
- (22:46) Remote work has increased dev productivity by default
- (27:47) Why Shopify loves remote pair programming
- (33:01) Finding your voice as a developer
- (41:17) Writing a book can be a spiritual experience
Our Interact conference featured content from the best engineering leaders in the world. Watch it on demand on YouTube now.
Transcription:
Dan Lines: Host
James Stanier: Director of Engineering at Shopify
---
James: [00:00-00:36] But I think the thing that you said, which was, you know, how could an individual contributor be listening to this thinking that that could be for me, I think it's about understanding where you derive your happiness in your job. If it's mentoring, if it's coaching others, if it's helping groups of people come to decisions to solve problems, building relationships with people so that you can make them increase their skill, increase their happiness, increase their effectiveness, then if those are the bits that stick with you at the end of a week, yeah, maybe management is a good idea for you. If those are the things that at the end of your week, make you feel exhausted, and you wish that you could just get back to writing code again. And yeah, fair enough. Maybe it's not for you.
Producer Ad: [00:36-01:06] Over $30 billion in engineering wisdom will be at your fingertips and interact on April 7. Join engineering leaders from Netflix, Slack stack, overflow, American Express and more at interact, a free virtual community driven Engineering Leadership Conference, one day 20 speakers, all selected by the 1000s of engineering leaders in the dev interrupted community. If you are a developer, team, lead VP or CTO looking to improve your team, this is the conference for you go to Dev interrupted.com/interact to register today.
Dan: [01:07-01:32] Hey, what's up everyone? Welcome to dev interrupted, I'm your host, Dan lines. And today I'm joined by James Stanley, air director of engineering at Shopify. He is a distinguished author, his first book become an effective Software Engineering Manager. It debuted in 2020. In this year, he'll release his second book Effective remote work, James, thanks for joining us.
James: [01:33-01:36] My pleasure. My pleasure. Thank you for inviting me, I appreciate it.
Dan: [01:37-01:53] Awesome to have you here. Let's start by giving our audience the opportunity to get to know you a little bit better. You have a Ph. D. In comp sci Did you always know you wanted to be a developer and kind of study the space?
James: [01:55-02:31] When I guess right at the beginning, it came from a fascination with the internet, like I grew up in like the late 80s, early 90s, the World Wide Web boom, the very early days of you know, piping modems, and very, very slow loading times for-for images, and so on. And, you know, that really captivated me as a teenager. And it was definitely something I wanted to be involved in. I felt I didn't know how at the time. But yeah, like, my teenage years, and my hobbies, it always gravitated towards spending a lot of time on computers. And, you know, my parents like that, you know, I kept out of trouble on the computer. And yeah, gravitated towards what I do today.
Dan: [02:32-02:40] Awesome Time to grow up the early public internet days. Can't ever go back. But I think about it all the time. What a great era.
James: [02:41-02:55] Totally, we had a friend of mine, his-his dad was an accountant who was like the first person in our little community to get the internet. And everyone was around his house, like every single night. And yeah, there was those were fun times, I'd love to get back.
Dan: [02:56-03:11] You got your PhD in computer science, which not that many people I mean, a lot of the people that I talk with, they might have gone to like undergrad and maybe a master's. What are you doing in a Ph? D? Like comp sci? Program?
James: [03:12-03:58] That's a really good question. And I think PhDs generally are defined as a couple of things, like one of them is training to be a researcher, in one sense. And also, it's usually your first time, mostly where you're starting to do work that hasn't really been done before. So the idea of a PhD is you produce a thesis, which is an original piece of research, which, in the grand scheme of things is a tiny, tiny thing in knowledge when you do it. And at the time that you do it, it is your entire world. And it is a full-time job. And it's very intense. And but really, it's about you know, getting people coming out of the university programs, able to do research as a career, or to go on and do more advanced things in industry.
Dan: [03:59-04:35] It's really cool. Thanks for sharing that. Because I know, you know, there's probably some people listening should I get into a program like that continue or not? One of the concepts that you've written about is this phenomenon where people learn to write code, develop code, you know, study in school, but have no background or experience when being promoted into management. I think that's something a lot of us can relate to. You've talked about the fear that developers have when making the transition to management saying people are afraid to become managers. Can you dive us into this topic?
James: [04:36-06:02] Yeah, it's, it's interesting that you-you opened up with the part about, you know, doing PhD and going into school and going to university and so on, because, you know, very much that is a manifestation of how people get into the industry. They spend years and years, learning how to program learning all the fundamentals, you know, they go through lots and lots of training. And then many engineers, software developers finance Those in industry, looking at their career and going, how do I progress? How do I do something more? You know, how do I maybe get a promotion? How do I get paid more? How do I get a more prestigious career, job, title, whatever change. And one of those things that happens is lots of engineers get almost forced into management as the way in which they should progress their careers. And it's interesting, because at that very moment, where they begin to make the transition to management, they're stepping into something that they've never actually done before. So you've kind of got to this point where you've been extremely competent and qualified, and you've been performing exceptionally well. So, we reward you by giving you were told that you've never done before. And you're incredibly uncertain about and therefore, you know, people are afraid to make that step. Because I think, not only is it an unknown world, I think lots of people are also worried that if they have been a really high performer, and they've been really impactful, then all of a sudden, they're stepping into somewhere where they think that they don't know what they're doing. And they could do a terrible job. And therefore, they're sort of like backing away from it, because they're almost setting themselves up to fail if they don't have the right support.
Dan: [06:03-06:36] Yeah, there's actually really scary I have a sports on my mind. It's like an American thing, football, but even soccer, it's like, it would be really odd if you were training to be great in one position. So like, I'll do like a soccer reference, like I'm a forward, I'm scoring goals, but I was on the bench. And I was really becoming better and better at that. And then I was promoted to be the goalie. That would be like, so weird, you would never do that. Yeah, that in our industry, it's like kind of like that.
James: [06:37-07:14] And it's and it's often like in a high-pressure situation, as well like to use your soccer analogy there. It's a bit like when it's a penalty shootout at the end of the game. And then all with flow to usually score rowers have taken the turns, and then like the pressure is ratcheting up, and then the only person left to shoot is the goalkeeper. And you're like you don't want to be the goalkeeper in that situation, you know, you want to have arrived in the new role as being a manager, someone who knows how to do it, who's got a safety net underneath, and they know how to succeed? And then how to get access to the skills to do the job? Well, and I think so many engineers take that step or are afraid to take that step and have no support.
Dan: [07:15-07:20] Why do you think that is in our industry, that's the promotion path.
James: [07:21-08:22] I think it's changing. And I think if you sort of see a lot of the big tech modern companies now it's a lot better in that there are better career tracks that are for individual contributors, as well as managers. And the two things are actually two separate roles, two separate tracks, the progression of both of them is in a very defined way. But I think it's to do with like maybe smaller companies that need leadership, it comes from companies that maybe haven't spent a lot of time defining their career paths. And it's kind of just a thing that happens in many other parts of the industry, other industries as well, where if you're really great, then what's the next step? Well, you run a team of great people, you know, that's the go back to the soccer thing. It's like the Great player becomes the great manager in the future. It's a progression that it feels quite natural. However, I think it's something that is very unnatural. Because what you do to become great as an individual player is not the same thing that makes you great as a manager is a totally different thing.
Dan: [08:23-08:38] Absolutely, I think it's probably really fair to say that there is a lack of resources, and there's a skill gap. And when it means like, what does it even mean to be a great manager? How significant is that gap out there?
James: [08:39-09:54] It's better than it used to be. And I think when I first took my management role, getting on about nine years ago, now, there really was a lack of resources, there were very, very few conferences that had any talks about what it means to be an engineering manager. There weren't that many modern books either. I remember, I bought a whole bunch of books. And there were some that were very kind of Business School II that didn't seem particularly relevant to me. And there was one or two that were very, very old and academic and didn't seem relevant to me. Now, the situation is a lot better. There are great books out there. There's what's the lead dev conference, there's tons of blogs and resources online. But in the grand scheme of resources, it's still a tiny microcosm, in a sort of a galaxy of skills for software engineers. And I think many people don't know those resources exist because they don't know what to look for. And also typically you learn by osmosis by the people that are around you. And if you've got a great manager, if you're the one of the lucky ones, then that's fantastic. Because you can mirror them, you can be coached by them. But I think for a lot of us, you know, often we feel that we're being managed by somebody who maybe isn't the best manager in the world, maybe because they're in the same position that you're about to go into and it just kind of self-perpetuating problem I know really gets the skills they need because they don't know where to go.
Dan: [09:55-10:10] What do you think we need to do to address this skill gap? I mean, I definitely see the Scope. AP is well, one of the reasons that we even have this podcast dev interrupted, I think we're contributing to lessening the skill gap or whether you think we need to do to reduce it?
James: [10:11-11:22] I think the first thing is a real clear, concrete identification that running a team and being a manager is a totally different job from being a software engineer. Yes, it's sort of supported by the skills that you have of being a software engineer, I, you know how to build software, you've got that bit covered. So therefore, like running a team, you know what they're doing, you understand how things are built for the actual way in which you're effective as a manager, the way in which you do your job, the way you think about your day to day, week to week is just totally different, because it's a different role. And you have different outputs, you know, you think a software engineer could be impactful while at writing really great code, or shipping features, or mentoring others and coaching others and increasing their skills. But those things are pretty different for a manager is talking about having a productive team efficient, happy team retention is about influence. It's about owning things, it's like it's very, very different. And yeah, identification first, then assuming is identified, and there are all career paths that are for managers, as well as ICs, then it's about getting access to those resources that you were talking about. And, yeah, there's plenty more places to get them now.
Dan: [11:23-11:39] Do you think an individual contributor that's listening kind of needs to decide at one point, am I going to go this route or that route? How do you think about that? If I don't know maybe I'm a few years into my career, things are going well, for me as a developer. Now what?
James: [11:40-13:20] That's a really good question. So, I think one thing that came to my mind when you were saying that to begin with, is that it isn't necessarily a one way street. So, some people, again, I have this preconception that you kind of are a software engineer for some amount of time. And then you kind of hit this threshold. And it's like, right, now you become a manager. And then as soon as you've sort of left on that boat, you can never come back again. So firstly, it can go both ways. I think you can be a manager for a while. And if you get the opportunity at your current company to be promoted into that role, and to give it a go, then, if you think that might be for you, then you know, I would advise going for it. We can talk a little bit about how to make that successful in a bit. But I think the thing that you said, which was, you know, how could an individual contributor be listening to this thinking that, that could be for me, I think it's about understanding where you derive your happiness in your job. And the times in your days in your week, where you feel that you've done something that makes you happy. And if those things that make you happy are things like working with other people in order to help them solve problems, if it's mentoring, if it's coaching others, if it's helping groups of people come to decisions to solve problems, if you're really interested in building relationships with people so that you can make them increase their skill, increase their happiness, increase their effectiveness, then, if those are the bits that stick with you, at the end of a week, yeah, maybe management is a good idea for you. If those are the things that at the end of your week, make you feel exhausted, and you wish that you could just get back to writing code again, then yeah, fair enough, maybe it's not for you. So, it's about listening to yourself, and understanding what really motivates you, and what makes you come into work every day and enjoy yourself.
Dan: [13:21-13:37] That's a really good point, which kind of, I think, will lead to this next question. Do you think that it's possible for any developer to become a good manager? Is that possible to gain the skills for anybody or not?
James: [13:38-14:47] I personally believe, yes. You know, anyone can be a good manager, I believe, you know, anyone can be a good engineer, if they've got the right time, and space and training and feedback and all the things available for them to grow. And it's a bit like a nurturing plant. I'm not saying that engineers and managers are plants, you know, we're all humans. But when the right conditions like we can grow, but certainly some people are more talented at it than others, in the same way that I knew when I was programming, that there were some people that same with exams, like some people would just go in with no preparation, and they would just knock it out the park every single time that I was never one of those people, I was always a very sort of disciplined practice or in order to get good at something. So, I think that some people may have more talent than others. But fundamentally, if people have the right resources, to get the right guidance, and coaching and support, then yeah, anyone can become a good manager. But the important thing is that you have to want to do it. And I think that's the same with anything in life, isn't it? Really, it's like, yes, anyone could do anything if they try hard enough. But the people who are the really excellent managers, the ones who really have a passion for it, that comes from themselves, rather than being told to do that, or thinking that they have to do that.
Dan: [14:48-15:30] We have a range of listeners from developers to VPs of engineering and CTOs. Everybody in between. But we have a lot of people that are at what I like to call scale up companies. That means that they have a rapidly growing engineering team, because they're working on a product that's so great. Or maybe they received, you know, $70 million in funding. And let's say that I'm a VP of Engineering, and I'm trying to grow this manager level, which is a very important and strategic layer to get right as you're scaling. What do you think someone in that position or companies can do to help developers make that transition into that management layer?
James: [15:31-17:28] And that's actually pretty much what happened to me. So, in my previous company, when I left, I was the vice president engineering. And I came up from an individual contributor in a startup group. And I think one of the things that you notice, especially in the bigger tech companies is that if you want to get your first management role, and you haven't done it before, then it's really difficult to apply for it. Because obviously, people are looking for those that have had experience. So, scale up startups are actually the perfect opportunity to give engineers that opportunity, because they'll have the context, they'll be earliest stage engineers who know a lot of the architecture in the company, they've got the domain knowledge that's already there. So, like that is, is a check. And usually in startups and scale ups, because it's smaller, there's a higher level of trust. People know each other better. And what I would suggest to, you know, VPS CTOs, who are looking at how do I get great talent to be a manager later, yes, you want to hire some people externally, it's great to have experience, but also put aside some number of headcount for bringing up people from within, because you can work with them to have a brilliant safety net, to say, hey, like, we're looking for managers, you want to do this, neither of us know whether this is going to work for you, maybe you just won't even enjoy it, you know, that's one of those things that can happen. You say, hey, like we're growing, you could run a team maybe come up with a 90-day plan to be really successful in that role. And then mutually at the end of that 90 days, you could decide as to whether it's still working, whether you want to continue, if not just go back to being an individual contributor, again, you know, it's not a problem. So I think that growth is a really great wave to catch in order to do it for the first time. And you see that pattern quite a lot actually, in startups is that you know, engineers come in, they get a chance to do things that are sort of way beyond what they'd be able to do at a bigger company, because it's small, and it's growing. And then that's sort of ammunition for the CV, and then you can go and do it somewhere else afterwards, as well.
Dan: [17:29-18:12] Yeah, actually, one thing I really liked that you said, They're going from a developer to a manager, first time, it's pretty high risk. It's not like you're changing careers fully, but it's a different role. And I liked that idea. Maybe if you're leading an engineering organization, you do put a couple of heads aside, you want to promote from within, but maybe you put in a program in place that checkpoint after 90 days. Because I remember when I was promoted from developer to a manager, there was no feeling like I could ever go back to be honest with you, it was like you are here. And like, now we need you to manage more and more, there was no option. And maybe having that 90 Day check, I think I really liked that idea.
James: [18:13-19:00] Yeah, and I mean, 90 is just an arbitrary amount of days, you know, could be six months, it could be a year, but I think it's just like you don't know, if you really enjoy doing it until you do it. It's, it's just hard to predict. You know, I've seen people on both sides, I've seen people very reluctantly take the role and then love it. And I've seen people who've wanted to do it for very long time. And-and they hate it when they do it. So having that sort of safety net, that kind of, you know, clawback clause in the contract as it were is super nice. Because if you're running a team for the first time, and you want to run a team that feels psychologically safe, trusts each other, and then the person that's running them is so completely anxious and self aware that they might be doing a terrible job. That is a really hard position to be in, you know, so allowing people to do it confidently where they know that they can go back and there's not gonna be any problems, I think, alleviates a lot of that stress.
Dan: [19:01-19:12] If you are in a position where you know, you're a developer, and you are going to make the transition to be a manager, what advice or what do you need to know what would you tell someone in that that's going through that transition?
James: [19:14-21:04] Yeah, so there's a few sort of principles that are really useful. And, I mean, one of them is from Andy groves, high output management, which is like a classic management book. And he used to be the CEO of Intel when he was alive. And he has this equation in his book, which is fantastic, which says that, like your output as a manager, is the output of your team, plus the output of the organization that you influence. And that was really sort of game changing for me, because all of a sudden, it wasn't that my output was the stuff that I did. In terms of the concrete lines of code or lines of text that I write or hours spent in front of the keyboard typing, it just kind of shifted the whole thing to okay, it's like my team's output, and also everyone that I worked with around the team as well. And that sort of just comes He shifts your mindset. So that's one of them. And the other one is to become comfortable and to know ahead of time that being a really good manager, and especially as you go up the ranks in a company, and you have teams of teams, and many, many people reporting into you, is it you have to let go of control, you can't do everything. And you know, the function of you being really good, and your team being really good. And your organization being really good, is delegating all of the sort of autonomy and power to those that work for you. So that you as a manager can focus your time on the bits that do need your help, while the rest of them run fine with-with less check ins. And, you know, that was very uncomfortable, especially if you've been a really highly performance productive, efficient individual contributor, which really much is about having control. And it's about, you know, building things and deploying things and providing things for others all these like immensely measurable things, it becomes so much more subjective and harder to measure as a manager that you can go back into old behaviors have too much control, when actually you need to step away.
Dan: [21:05-21:42] I can totally relate, I also read the book that you I think it's called high output management, right? Good. It's-can be a tough read a little boring, but it's actually really interesting. At the same time, I love the idea of having like a perspective change, because it also comes down to self-worth, right? You want to feel like you're doing something my self-worth, or the way that I'm measured is my team's output as the impact. I think it like making that mindset shift sets in a North Star direction and the other things can then fall into place. Would you agree with that?
James: [21:43-22:23] Yeah, I agree. And one of the ways you can kind of model it in your brain is to sort of explode your current situation into something that's like 10 or 100 times the magnitude look at someone who is the CEO of a 15,000-person company. And you think, Okay, well, that's a person managing a team. It's a very, very big team, but they're managing a team. So what do you think they're doing with their day to day? What do they do on a Monday morning? What do they do on a Friday afternoon? They're probably having a lot of meetings, you know, why is that? You know, okay, how do they control everything? Well, they don't. And it just kind of helps you put that mindset into your smaller version of that by modeling some of the behaviors of a very big version of that.
Dan: [22:24-22:57] Amazing. Thank you, you know, for all of that advice, and tips. There's another topic that I want to hit on with you, around productivity, especially in a remote world. There's some, you know, people out there or companies that are questioning, are we more productive remote? Are we not? synchronous versus asynchronous work? You don't seem to question that at all. You've said something like remote work has increased productivity by default. Let's dive into that a bit. What are your views on productivity?
James: [22:58-24:07] It's very hard to measure. And it's subjective. But I think but everyone who's spent time working remotely, which is probably most of the people that have listened to this podcast in the last couple of years, given everything that's happened with the pandemic, I'm sure everyone has experienced that with appropriate setup at home with no distractions, and sometimes that's hard for some people. But if any of your vote will open plan, office arrangements have been part of your life in the past, very distracting, noisy crunching of keyboards, people talking, you get distracted, so easy. So I think individually, yes. Like, can I more easily focus at home on a task? And get it done? Absolutely. I think productivity is easier at home. But I think productivity is only one measure within an organization's effectiveness. And, you know, certainly remote work has made other things a lot more difficult, because we've had to completely rethink about how we collaborate, we have to be much more mindful of time zones, and all of the other things that have come along with it. But you know, I do think that many people when I've seen your article was in surveys, I think it's easier to be productive at home or remotely away from a local environment.
Dan: [24:08-24:22] Do you have anything or any thoughts that are specific to an engineer, or an engineering organization as it pertains to remote work? Have you seen anything that's changed? What are your thoughts there?
James: [24:23-25:53] So there's suddenly a whole bunch of things that are way harder. So, you know, personal things. I'm sure we've all felt isolated at home, certainly, by removing the many social interactions that we would have in the office every day we, we lack those, you know, and that and that's hard to easily fill them in. And certainly the other thing with remote work that we've-we've lost as well, I think, is having an observable rhythm to our days. That means that say, we don't work too much we have breaks because these would naturally be occurring in the office environment, you would see people come in in the morning, you see people go to lunch, you kind of copy the behavior receive your team and those around you, you know, oh, everyone goes out for lunch at one o'clock, alright, I just go-go out for lunch as well. Whereas if you're at home, you can be very easy to overwork, and overworking leads to stress and burnout, and so on. So there's a lot of things that we need to be careful of. And the final thing sort of in that bundle of things that are different is that in the office, you have so many things that are sort of just sort of pushed at you. socialization, interactions, seeing something talking to somebody learning something, because they are just there, the office spaces, physical layout, and the people in it, dictate what happens. Whereas when you're at home, you have to much more full, in order to find out what you need to know, if you want to have a coffee with someone once a week who don't know, you have to be very proactive. If you want to find out things that you don't know, you have to be very proactive. It's a, it's a very different way of working in that kind of push pull configuration.
Dan: [25:54-26:21] I guess to me, it's pretty obvious, we'll see what the future holds. But remote work is here to stay, regardless of COVID-19 or not. And I know developers really like it. But what do you think, maybe environmentally or behaviors of an engineering organization that needs to change to support remote work for developers?
James: [26:22-27:47] That's a good question. I mean, I think there's a few things like at a macro level, during the pandemic, and for quite a few companies still, now, everyone has been remote. Therefore, the playing field has been fairly level, everyone's interface into each other. And the company has been through their own computer, their webcam, microphone, and so on. As the world returns to work, and as some companies mandate returning to work, or some go to a hybrid model, then actually the inequality starts to set in. So, I'm sure we've all had situations, years in the past, where you've been the only remote person and you've dialed into a room and you're coming out of a screen and a webcam that's like on the wall in a meeting room, and everyone's sitting at a table and you can't see everybody properly, because they're all on one camera, you can't hear them. So, you know, physical spaces have a different type of interaction and gravity than the remote one. So, I think as the world becomes more hybrid, there's a mindset change that needs to happen if they want to support remote work well, for engineers, and that's, you know, treat everybody as remote. Even if they're at home, if they're in the office, you know, everyone has to be treated the same and give them the same interface into the company. Otherwise, it's just not an equal experience. Yeah, that's the main one that comes to mind is that, you know, we have to continue remote working, but do it very intentionally. Even if you are in the office.
Dan: [27:38-28:02] I have a note that you're a fan of pair programming. What do you think are the benefits of that type of, you know, working pattern? And then I'm trying to think to myself, well, what would that even look like in a remote world?
James: [28:03-29:38] Yeah, yeah. I mean, this is one of the cultural things that Shopify really promotes. And I think it's very, very valuable, which is, which is pair programming, and you go, Okay, well, how does that even work when you're remote? Isn't? Isn't that just a nightmare. I mean, there are good tools out there now. So, we use a tool called tuple. It's a third-party tool, and, you know, just-just Google tuple and programming, you'll find it. And the whole idea is that you're sharing your screen, you're able to take turns, you know, with mouse and keyboard control, when you're pairing together, and actually, I found that you know, pair programming remotely, I find a lot easier than doing it in real life. Because in real life, you're sitting next to each other on the screen, you're sort of mouse and keyboard, and you know, you're kind of close to people, it can sometimes be a bit uncomfortable to do for long periods of time. But doing it remotely with your own setup with all of your things, as you expect them when you're working individually, is actually really easy. And I think, not only does pair programming allow you to solve problems better, and sometimes to write less code and to do less work than you would if you're doing it individually, because you can really discuss, it's just a great tool for socialization as well. You know, I've found that pair programming during the day is just a great chance to, you know, bookend it with a chat and coffee and see how someone's doing and just, you know, feel that you're really connected to people and you're collaborating with people because if you're very, very asynchronous, and you're spending your entire week just writing sending messages and emails, then you can easily forget that you're working with other human beings, whereas paper around brings those human beings together.
Dan: [29:39-29:51] At Shopify, for I guess for your team or your area of responsibility, is it is everybody doing pair programming is optional, or like how do you think about it for your organization?
James: [29:52-30:44] It’s definitely optional but is highly encouraged. And it's kind of the first go to tool for how do I learn about this thing? or how do we solve this problem? So, say for example, you've got a new engineer onboarding, or maybe an existing engineer working in the part of the codebase, they haven't done before, then usually the initial answer to the question of like, okay, I don't know how this works, like, how do how do I make a change? How do I learn more about this error of the code base? The answer is, let's pair on it. And even if both people don't know, you know, two people that don't know, often come to some really interesting solutions compared to one person on their own, that doesn't know, that can either come to a Nazi great solution, or can just feel very isolated. So pairing sort of just creates a nice sort of play, feeling to solving problems, and often results in better outputs as well.
Dan: [30:44-30:59] Yeah, I was gonna ask you about the outputs? Have you noticed anything with, I don't know, like quality of work, or like, you know, speed to completion? Or is there any characteristics that you've observed along the way?
James: [31:00-31:48] Yeah, I definitely find that pair programming tends to produce less code. Because between you, you're, you're far more sort of rigorous in like, Okay, well, what, what really do we have to change, you know, and then as soon as you've thought of the solution to the problem, you end up discussing her work, is this the best way of doing it. And I think that sort of accountability that two people synchronously give each other tends to lead to better solutions. And if you're just doing it on your own, and I also find that sort of when you work together, and you come across some technical debt, where you come across some cruft that needs cleaning up, you actually kind of gravitate towards wanting to do it at the same time, you think, oh, you know what, we're here. We should probably tied to the auction that yeah, totally, let's do it. Whereas sometimes, when you're on your own, and you're maybe focused just very singularly on just getting a task done. You might not tackle that particular thing.
Dan: [31:49-32:20] That's really cool. Yeah, I mean, one thing I know for sure, I mean, you had the insight, the usual behavior is less code. Well, what I know, from our company, Linear B, we're studying code all the time and pull requests and things like that. Less code always leads to good things. Like, how fast can we get this code out to production, less code also equates typically to less bugs, less change. So that's really cool that you have that insight. Thank you for sharing that.
James: [32:20-32:45] One other thing that I just thought of, as you were talking as well is that pair programming gives you that great opportunity to just see somebody else's IDE setup, like there will be doing the programming, and it's their turn, and then they might have a certain macro or shortcut set up that does something you've never seen before you like, what did you just do that like that? That was cool. That Oh, yeah, it's just this plugin that I'm using, like, you can use it. Wow, I just learned something. You would never pick that up on your own?
Dan: [32:46-33:22] Oh, yeah, absolutely. I mean, I'm, I'm really big now into, I guess, saving time for developers. And one way to do that is through the choice of tools that you're choosing to use or choosing not to use. Very cool. Yeah, we have an interesting, somewhat final topic here around finding your voice as a developer. So, you've established yourself as an author, you've become an authority, on the subjects of remote work and management practices. I do think about, you know, finding your voice as a developer.
James: [33:23-35:22] Yeah. I mean, what's interesting is that the things that you just said were never intentions. That's the first thing I'd say. So, in terms of finding my voice, or beginning to do some writing, and it did come from just very, very humble beginnings. And right back to the beginning of the podcast, where you were talking about, okay, you've become a manager for the first time, how do you find some things out? You know, where do you go to look to learn skills. At the time, there wasn't a huge amount of resources for me. So, I was learning on the job. And I was piecing things together from books that I was reading, and I sort of felt okay, I've learned this thing. And a lot of my colleagues were saying, How do I do that? Or have you got any advice? So, what I did was I just started a blog. And I was just writing a little article once a week, and I just sort of gave myself that as a, as a hobby to do really. And then the intention back then was that, you know, for every post that I write if one or two people read it, and they learn something, and that's great, right, like, that's, that's a valuable outcome. So, I started this blog, and I believe the engineering manager.com and it's still going now. And I thought I wrote a post every week. And then I just kind of found it fun. It was a nice way of you write to think as well as you know, writing to communicate. And I found that by putting together just 500 words a week on something that I thought was personal, it was a really great way to organize my own thoughts and then send it to other people that I was working with, say, hey, like, you know, if you're just doing one to ones for the first time with a new member of staff, here's his exercise I learned about here's a post I wrote, that's where it began. And then from there really, it was just a case of enjoying it, and then sharing more widely on the internet, like, submitting things to Hacker News. And I got a few front pages out of it. And just slowly the flywheel began to turn there. And it just, it just went in that direction.
Dan: [35:23-35:56] Wow, that's Yeah, that's really awesome. One kind of culture that I've observed with the development community are kind of like engineering style people, sometimes not to stereotype. But self-promotion is usually not a characteristic of some of the greatest engineers that I've known. And so, there's a little bit of a timidness, to maybe do something like a blog, or, you know, even a podcast like this. How you think about self-promotion?
James: [35:57-37:54] Yeah, so I guess, sort of building off the previous answer, it's way easier to do it, if it's something that you feel you're able to give back whilst doing that activity. So, when I was doing my initial writing, it was legitimately, my colleagues asking me some things I thought I would just write up for you this week, you know, as a, as a way of just writing it once. And then and then it's a reference. So, it came from quite a sincere place, a place where there wasn't particularly an outcome or a goal I was aiming towards other than just trying to be helpful. But I think ironically, the people that are at the far, far end of the scale with hundreds of 1000s of Twitter followers, and all they are doing is being helpful, but the core, I think, so the self-promotion thing doesn't have to be this, you know, stereotypical, I'm marketing myself all the time, or I'm trying to play a part or play a role in order to be a thing. I think that's quite insincere. And that's quite hollow, and it doesn't feel right. And I think that's why people shy away from it. It's not, it's not the craft at that point. So, you know, the advice to people starting, so everyone is unique. Everyone has their own perspectives on themselves and their skills and their role. And you know, every single day, you come across new problems, and you come across, things that you solve. And, you know, there are blog posts out there that have had 10s of millions of views, which had some obscure, particular scripts, you know, like, like a bash script, to solve some really common problem, and just somebody has gone to the effort of just spending 20 minutes of writing it up and say, Hey, this thing, use this script. It's a great idea. And that's an amazing blog post that has huge, huge impact. So it's about problems that you're solving, written sincerely, on something you're passionate about. And if you keep at it, and you write once a week, or once a month, and just continue it for me, it took years, but it does go somewhere.
Dan: [37:55-38:37] Yeah, absolutely. I would just say to our audience, again, sometimes there's not even just self-promotion. But there's a tendency to think, well, nobody will care. Like what I'm, what I have to say are like, actually, people really do care what you have, you have to say they're going through the same problems as you if you're describing a problem, and you're coming with a solution, you might be shocked at how many people actually get value from it. So just a little, I guess, promotion to put your stuff out there and your thoughts. Now, James, you've taken it to a point that you have at least one book out there and a second one on the way, what does it take to write a book? I've never written a book, like what does that process look like?
James: [38:39-41:13] Yeah, it’s a really good question, actually. And people asked it a lot. So, I guess to begin with, even if I think about the first book, I wrote my blog for three and a half years, maybe nearly four years before the book was even an idea. So, for the first book, it was very much that I'd written a huge amount of material across many, many blog posts. And I thought, hang on a second, like if this was sort of arranged in a certain way with a clear narrative, then there is actually a kind of a field manual here of how to be a good manager, if it was if it was all written well. And that's where the idea came from. And for that particular process, I looked at the different publishers, and the typical way that you, I guess, you could self-publish, but the way I went was with an existing publisher, and I found the publishers that I really liked. And I ended up going with Pragmatic Programmers who publish really amazing books for developers, and just literally sending an email. Really, it was a couple of paragraphs. It wasn't that I had to write a book first. And then send a humongous PDF to people and say, publish my book. It was hey, you know, this is me. This is my website. I've been doing this for a long time. I think there's an audience for this because I can see that I have lots of visitors and shares from my blog. Could this be a book and you know, I sent out to a bunch of different technical publishers, a few of them got back and said, that sounds interesting. You had some initial exploratory calls, which ended up for me being two pitches. So, I pitched Manny, unable to pitch to Pragmatic Programmers. And then through that pitching process, sort of it was two way like they learned what I wanted to write. And also, I learned more about what it's like to work with them. And in the end, I went through the pragmatic, and the process wasn't that I had to write the book upfront, you work with the publisher, starting pretty much with the table of contents, you know, what, what's going to be in the book at a very high level. And then from there, you go through, and you think about the high level of each chapter like you go through, like the hero's journey of the reader, like, where are they coming from at the start? What are they going to learn as they step through every chapter? And you plan that all out upfront, and then you work on a chapter at a time with it with an editor, and it took about 10 months doing it in my spare time. So it was a significant undertaking, because it was 320 pages or so. And for the last a bit of how do you actually get the time, unfortunately, you just have to find the time, late nights, early mornings, stolen time at the weekends, and just trying to do a bit every day.
Dan: [41:14-41:26] That's awesome. Thanks for sharing that process. You also mentioned that you found the process of writing these books was almost a spiritual experience. What does that mean?
James: [41:27-42:46] It's interesting. So, I mean, for the first book, The period of time in which I wrote that was one where I felt like I'd hit a moment in my career where I didn't really know where I wanted to go next. And also, more broadly, we, we didn't really know where we wanted to live in the future there lots of sort of personal life, family things we were going through at the same time. And dealing with a lot of that change, whilst writing the book was actually really valuable to me, because the book was almost this steady thread that ran through the entire experience. So, every day, I could come back and do a tiny bit of writing, even if it was just a few paragraphs, it was something that I could do every single day. And sort of going back to the things that we mentioned at the beginning, which is to do with management, and especially higher levels of management, especially during more turbulent times at a company where you're going through mergers, or acquisitions, or so on, it can just be incredibly messy as your day job, you know, you can feel that you go through days, weeks, sometimes just dealing with fires and getting nothing done. And for me having the work, which was something that I could fully control, that almost was my individual contributor role, you know, in a way, was really beneficial for me and my mental health, and just how I got through that time.
Dan: [42:46-42:57] That's amazing. It's almost like you could find your spirit as a developer. Very, very cool. It's been an amazing conversation, James. And thank you so much for coming on our pod today.
James: [42:58-43:00] No problem. Thank you for having me.
Dan: [43:01-43:08] Now, you have two books. Tell us about each one of these books and where we could find them if we want to pick them up?
James: [43:08-44:25] Yeah, sure. So, the first one is all about becoming an engineering manager. And the title was almost that phrase, it's become an effective Software Engineering Manager is on Pragmatic Programmers, you can find it in all good bookstores, Amazon, independent retailers. So, you can-you can search for it. And it's about the hero's journey of becoming a manager for the first time and giving you all the tools, you need to succeed in the job and his pitch to new managers. It's pitch to existing managers who maybe have sort of fallen into the role once or maybe build the scaffolding around themselves. But also, you know, equally as people interested in like, do I want to do that as part of my career and the books there to really give you an idea of what it means to be effective in that role. And that's part one. And then the second book, which the eBook is out now. And the printed copy should be coming out within the next few months, is called effective remote work. And in terms of the-the hero's journey is very much the same. It's like how do I do remote work well, in a way that works for me as an individual, as the worker, but also a team and best practices for working together. And also, the company at a cultural level and it and it brings you through that sort of ever-expanding remit as to how you can do remote work well at your company.
[Music Fades in]
Dan: [44:36-44:53] Awesome. So we'll make sure that we include the links to each one of your books. And a quick reminder for our listeners. If you haven't already rated and reviewed the show on your podcasting app of choice, particularly Apple podcasts, please do so. Also be sure that join the dev interrupted discord community. That's where we keep this type of conversation going all week long. And James, thank you again, for coming up.
James: [44:54-44:56] Now it's my pleasure. Thank you so much for being a great host.
[Music Fades Out]