Christian McCarrick
This is simple leadership. Welcome. Thank you to our sponsor, Auth0 for helping make the internet a safer place by offering identity as a service and supporting this podcast. We’re here to learn from new and seasoned technology leaders who all share a passion for improving the craft of technology management. Let’s take a deep dive into management and leadership challenges and best practices specific to Software Engineering and Technology teams. Do you want more engineering management leadership tactics and information? Subscribe at simple leadership.io to receive the latest updates from this podcast. Hi, I’m your host Christian mckarrick. This is the simple leadership podcast. Welcome back. Today’s guest is Eric Elliot. Eric is the author of the books “Composing Software” and “Programming JavaScript Applications”. He is a co founder of EricElliottJS.com and DevAnywhere.io. He teaches developers essential software development skills. He builds and advises development teams for crypto projects and it’s contributed to the software experiences for Adobe Systems, Zumba fitness, The Wall Street Journal, ESPN, BBC and top recording artists including Usher, Frank, ocean, Metallica, and many more. He enjoys a remote lifestyle with the most beautiful women in the world. On today’s episode, we discuss how important it is for managers to focus on code quality and good software development process. Eric, welcome back to the show.

I’m excited to be back.

No, I’m glad to have you. I think i think you’re actually my first repeat guests, not the only one I’ve thought about having on twice, but certainly the first one I’ve actually had on twice in actuality. So you know, you can you are a pioneer in that aspect. So thanks for coming back.

Eric Elliott
That’s exciting. I’m really glad to be back. The last episode was one of my favorite interviews ever. So I appreciate that.

Christian McCarrick
I appreciate that. And I get a lot of good comments from my listeners too. So that’s definitely awesome. And I was actually just checking and we recorded our last episode, almost like a year ago in a week. So it’s actually been just over a year. So how time flies. Absolutely.

Eric Elliott
It does. I didn’t realize it been that long.

Christian McCarrick
This it has, this it has. So I know Eric, some of my listeners, I’ll post the kind of notes where they can go back to car or listen to our earlier episode. But for any new listeners I have, they haven’t done that just a quick, you know, kind of 90 second little bit of background about yourself.

Eric Elliott
I’ve been developing and software leading software development teams for, you know, the better part of my life now. So I started as a consultant, my promise was put me 100% in charge of your development organization, your software organization, and I will deliver bottom line KPIs, or you don’t pay me nice and that that got my foot in the door with some smaller companies. And then the smaller companies, as they became more successful, got purchased and acquired and grew up to be bigger companies and pretty soon as consulting with fortune 500 companies, and that was fun. That was exciting. I spent probably a decade doing that. So in that process, I got to see a lot of different development teams and how a lot of people did different things and it was really exciting to learn about all the best practices and all the worst practices in the industry and get to see that up close and personal in a lot of different organizations. So that experience was really great. Then I went in and did some client side architecture at Zumba when it was a little tiny startup crew that grew to be great big. And from there, I went in, during the music app company, I was like developer number three on the front end, and we grew to 30 million monthly active users number one music app on Facebook. It’s now YouTube Artist Pages. And from them a video social network used by 85 million monthly users. And then Adobe Creative Cloud was the small, Adobe Creative Cloud team that is now $7 billion business.

Christian McCarrick
Nice, small, little company.

Eric Elliott
Little tiny.

Christian McCarrick
Something you said those stuck out at me the very beginning. You’re like you’ve been leading teams and most of your life and I, and I was sort of doing some mental math in my head and going “wow, I think I have too”. I’m not sure how I feel about that. But I have now too. So that’s interesting. The majority of my actually work now has actually been in leading teams versus being an IC. if you maybe don’t count, the like 12 year old me hacking on some early early systems.

Eric Elliott
Yeah, there was a 12 year version of me too.

Christian McCarrick
So now, anything kind of in the last year catching up, so it has been a year anything interesting that you’ve been doing since then? Yeah, you want to kind of fill us in on

Eric Elliott
I put together a couple more teams and you know, building from the ground up brand new teams. So that’s always fun. That’s always a great challenge. I’ve been advising more. So been talking to a lot of a lot of other companies. And when you’re in an advisory position, it’s like you get to like pop in once a month and say, “Hey, how’s it going?”, and kind of learn about the progress in little tiny bite size snacks.

Christian McCarrick
Yeah, without the pressure of delivering

Eric Elliott
Yeah, no pressure, I just tell them what to do and then they’re responsible for delivering and that’s nice.

Christian McCarrick
I think I need to start thinking about that. Because even on a good day when you’re leading and things are going perfectly if you’re the one responsible in the back of your head, you’re thinking “Okay, it’s too good to be true”. Something could go wrong with technical risk of you not being notified yet or…yes, that sounds that sounds very interesting. We can have another show about that.

Eric Elliott
Yeah, that’s a totally different topic because it’s a really different skill set. And you know, you’re not looking at the same things like if your hands-on on the company like actually embedded in the team and helping to lead the team directly. You might be personally responsible for diving in and and looking at like, what is going right what is going wrong at a more detailed level, whereas like as an advisory positions, very, very high level. You don’t have time to go into the Those kinds of details. Yeah. So it’s really different. Like, you have to figure out what are the KPIs that are really, that they’re going to give me the most insight in an hour a month. Right. So it’s a lot it’s a really different approach.

Christian McCarrick
Exactly. You know, let’s jump right into the meat of this this episode, I think I want to focus a little bit on something near and dear to you lately. Quality software bugs, you know, how managers deal with them, you know, how people talk about them, everything else around that. So they seem to be a fact of life, people deal with them. Sometimes, unfortunately, especially if you go to some teams where maybe you’re parachuting into a team as a manager and they’ve been around for a while the there’s a sense of almost learned helplessness about “Oh, there’s bugs, there’s so many of them, there’s we can’t even deal with like, squashing them or anything” right? But everyone talks about the benefits of kind of reducing bugs, defects, improving quality in your code base in your product. What are some tangible benefits to actually reducing the number that are there?

Eric Elliott
The first tangible benefit is that you spend a lot less money fighting fires, which means that you can put additional headcount on actually getting work done. Because fixing bugs is not work that’s delivering direct value to your customers. It’s rework. Customers don’t look at bug free as a benefit, right? They’re trying to get a job done. And they just assume there’s going to be no bugs. And if there are bugs, then they’re like, “I’m out. See you”. So you will lose customers. If you produce buggy software, it’ll drive customers away real fast. Another thing is you’ll spend a lot more money on marketing because your customer is going to be too high. So your marketing budget goes up. Your development budget goes up a lot, like 20-30-40-50 or a hundred percent. It’s really a matter of saving a lot of time and saving a lot of money. Fighting bugs is the most expensive and time consuming part of software development. And it’s really good to understand that because then you realize how we do have time to do like code quality processes like TDD and code review, because it’s going to save us a lot of time. Every hour spent in code review saves 33 hours and maintenance. This is things are that are really good to know, having a good handle on the economic effects of having bugs in your software’s of crucial importance to every manager. And the hardest part of being a software manager is understanding that software takes the time that it takes, and rushing it is going to make it buggy. It’s gonna make it buggy and it’s going to slow down your process. So patience is everything. So investing in that process of reducing bugs in your application is it’s crucial. It’s hard to think of something that’s more important, other than just making sure you’ve got a good customer feedbacks. Like you’re actually solving the customers problems.

Christian McCarrick
That’s right. We’ll go into a little bit later about, maybe what you said is the most important thing will run up by the salesperson. And again, the head of engineering, right. But you do mention things like churn and retention, especially as a SaaS company. One of the top metrics you want to measure is your is your retention and your churn right and your customer growth. So clearly, you’re not going to have a good Net Promoter Score, you’re not going to like you talked about the marketing budget, all those things are going to cost more money. So we’ll get into a little about translating the benefits from and speak to, you know, business speak, because that’s important. But do you have any idea and this probably changes the type of company that we can go into some of the new ones, what should be maybe a baseline metric for about for a decently running software engineering with a decent product? About how much of your time do you think baseline should be spent on sort of fixing any kind of defects or bugs escalations?

Eric Elliott
So that really depends, because if you’ve got your code quality process, right Then you’ll spend almost no time on it. Because you’re catching all the bugs before they happen. And then your rework drops to like almost nothing. So for example, I lead several software development projects pretty actively. I’ve got people managing that I kind of pop in and say hello, right. But I keep a really close eye on those things, because they’re, they’re my business. Yep. So this the software that runs that actually runs my business, I keep a close eye on those things. And we spend extraordinary little time on rework and fixing bugs and things like that, because we invest so much in preventing bugs in the first place. Number one, because every engineer on my team goes through like six to eight months of really high quality training before they even start producing on the software. And you know, not everybody has that luxury but we do on this project.

Christian McCarrick
Yeah, we’ll come back to that topic in a second. Tell me where that Somebody.

Eric Elliott
Yeah. But then we also we have a good code review process. Everybody practices TDD. They’ve been really, really well trained on TDD and code review. And they’ve got really good examples of what good code review means, and things like that. And our rework is almost none. Right? So we spend very little time on doing that. But we spend a lot of time on things like training and code review and TDD. Right? So but that time, more than pays for itself, because it prevents us from getting interrupted later by some critical bug that we have to, you know, stop the presses and fix that before we can move on. Sure. You know, taking it back a bit to the quote, you mentioned about the hardest part of yourself a manager is understanding that it takes time. What are some of the things that happen if you don’t slow it down? Like what is something what happens when you rush engineers? Right, what are some of the things you start seeing? I run organizations with a mentorship culture like we talked about that last time, right culture. Yep. So the developers won’t feel like they have time to mentor each other and help each other out. And that’s extremely problematic. So that gets skipped. And when that gets skipped, knowledge sharing gets skipped and your ability to prevent bugs get skipped. Alright, so that it adds on itself, right? The bugs pile up, test gets skipped. Communication suffers developers burnout. And sometimes you’ll lose completely lose developers. When a developer burns out. It’s a really big deal because it impacts their health. It impacts their ability to do their job, and it can even impact their ability to do another job in the future. And those effects can be really long lasting. So you might think a developer who burns out can just you know, take a long weekend and come right back. That’s not how it works. A developer who actually burns out, can get physically ill can suffer heart attacks and die. There are people in Japan this is a severe problem. People work themselves so hard that they die.

Christian McCarrick
There’s a word for that. And I can’t remember what that is. Yeah, yeah. But it’s

Eric Elliott
a real, it’s a real phenomenon. And you don’t want to see that phenomenon on your team. I’ve never actually seen that in person, but it happens. And it’s something that you need to be aware of. So you really want to avoid getting anywhere near that line on the developer burnout scale, right? And then productivity because of all of those other factors, productivity really, really starts to suffer. Yeah. So when you rush developers, the opposite of what you want comes to fruition.

Christian McCarrick
Now, let’s go for an interesting side case, especially talking about managers. You’re late, you’re getting pressure. The manager decides to step in, you know, grabbed a bunch of tickets starts, you know, writing stories and doing code, like what’s the outcome of that?

Eric Elliott
The outcome of that is then nobody’s watching the overall process. In manufacturing. There’s a floor manager who is usually perched up high above a factory floor so they can see everything on the on the factory floor. And they can see where things are piling up. So on an assembly line, you know, work comes in one end of an assembly line and goes out the other end of the assembly line, but then all these different processes in the middle, take different amounts of time to complete. And optimizing that process is the job of the floor manager. And if you’re not sitting up a higher level, right, and seeing that big picture view, then you don’t have the information that you need to do your job. Know what happens when the manager jumps in and starts spending too much time on code a little bit here and there. I actually love to code myself. So a little bit here and there is okay if you’re just helping somebody else out, right. But if you take your eye off of the factory floor to do that job, you’re going to get pile ups in the assembly line and there’s going to be the parts of the process start to go wrong. Ideally, the manager kind of disappears from the organization, the developers don’t really have to interact with them very much. And they’re just like, up there overseeing the process and making sure this the process goes smoothly. And then the developers talk to you maybe like, once a month on your one on ones, all right. And you don’t really have to intervene very much except for maybe tweaking meeting schedules here and there or saying, Let’s focus on this or let’s focus on that, like chiming in once in a while and the check ins like daily check ins and things like that. And you can just like nudge things in the right direction, and then the developers do the right thing in response.

Christian McCarrick
You also mentioned an interesting analogy related to the assembly line and blog article you wrote, which is good, I encourage all the listeners to read it, it’ll be in my show notes as well. You said when, if I remember correctly, when the assembly line piles up, to kind of stop it and figure out what the problem is. That was software engineering. This is interesting because I just read the unicorn project book too. And like you don’t try to fix the sort of problem, you just try to shove more things in the assembly line.

Eric Elliott
Yeah, which makes the problem worse. Right, exactly. I don’t know how many of your listeners have ever tried to use a copy machine. But sometimes copy machines jam the paper going through like jams. And the only way to get that you can’t just keep pressing copy. All right, that just makes the jam bigger and harder to fix. You have to like pop that thing open, pull out the jams paper, reset the whole thing. Start again, that’s the same thing happens in software. You can’t just push from the beginning and say work harder work faster. That makes the problem worse instead of addressing the actual issue. And the actual issue may not be that the developers are moving too slow or that the project is even moving too slow or slipping behind schedule. The actual issue may be that your expectations are not aligned properly with what is actually happening in the software development? So you might give somebody a task and they take a week to do it. And you’re like, Why is it taking you a week to get this done? Well, maybe it’s a week’s worth of work. And you just need to realign your expectations with that. And you just assumed that it was easier than it actually was. That’s a very, very common mistake that managers make is they think, Oh, I could do this in a few days, or I could do this in an hour. And you’re not factoring in all the other components this like, maybe they’re solving a problem that’s never been solved before, which is ideally what you’re doing when you’re creating software. If there’s already a solution to the problem, just pull it in as a module and use it.

Christian McCarrick
Right. Buy it open source something like build versus buy. That’s a yes, I agree. 100%. Yes,

Eric Elliott
exactly. So by definition, your developers should be building something that nobody has ever built before. Right? And if you’ve never built it before, you have no idea how long it’s going to take to build right. There may be a lot of Hidden complexity that you’re just not seeing yet. And as the developer, they’re seeing it and dealing with it. And it takes how long it takes to get it done. And if there really is a problem, and one of the things that I like to tell my developers that are working on my teams is you should write commits that you can, like finish within like a day. And then they can be merged in the code base safely and shipped to production within a day. Alright. So properly scoping and sizing those commits can help you see the progress instead of the alternative to that as they go and disappear into this rabbit hole for two weeks. And you have no idea what they’re doing and what’s taken them so long when they make a commit. And you can actually see the PR, outstanding, and every single day you can see, oh, they’re solving this problem. They’re solving this problem. You can see the progress being made. And you have this built in sense of Oh Now I know why it’s taking so long. Right? And you don’t worry, right? So the real problem is often the anxiety of the manager, not the work being done.

Christian McCarrick
Mm hmm. corollary to that more frequent check ins, less massive merges, you know, catching bugs quality things earlier, you know? Yeah, better quality software, right. It’s, it’s the other side of that as well.

Eric Elliott
Yeah, exactly. And seeing this, because when they go down those rabbit holes and they disappear for two weeks, they might be running off in the wrong direction, and you don’t even know it, because you can’t see what they’re doing. So if you start to think that they’re going to slow on something, just, you know, encourage them to like, what piece can you break off and make a PR out of right now that we can get merged within a day or so?

Christian McCarrick
Yeah, I think that’s good, good, tangible advice. asking your advice on something else. If you’re a manager, and you have pressure from above because maybe the person above you Because ever again, maybe they’re further away from the code, maybe it’s the VP of engineering. Maybe it’s someone else, nothing to do with engineering sales or what? How do you communicate up? Or what tools would you give to manage screen upward? The benefits of slowing down? design? TDD, code reviews, all those things? How do they make their point?

Eric Elliott
I frame it completely differently. I frame it like it’s not slowing down. It’s creating an efficient development process. So you can move fast. And you’re right, slow is smooth, and smooth is fast. Right? So I’ve talked about it in terms of making a slow, smooth, but because of that fast process, all right. And then when you’re communicating reports to your higher ups, the key is to let them see that there is good progress being made and let them see where the investments are being made and what the outcomes of those investments are. And the investments if every question part of your code includes proper quality process code reviews, TDD those kinds of things, then those things are not cost centers, they’re just part of delivering software responsibly, right. So what your higher ups need to see is good consistent deliverables. And you can’t get that if you’re spending so much time on rework, that you can’t properly make a chart that shows really good gradual, smooth, consistent burndown. Right, because what you’ll end up with is you’ll get stuck on this many outstanding issues that need to be done. And the chart will like bounce up and down on one little spot over and over again and not start to go down. Right, which is perfectly normal in a project that is continuous that’s ongoing. That’s lik, there’s no such thing as done. But when you set some milestone it says we’re going to ship this features on this date or whatever, right? You set some kind of, we’re putting together this package that’s focused on these benefits, right? Then you have some kind of burndown, that should start to go down over time when you get close to the finished results. If you see too much upward growth in the outstanding tickets instead of more sideways linear with like little ups and downs, or downward. It’s the upward like the continuously growing upward kinds of charts that you want to avoid. So I always have burndown chart that doesn’t predict the future. I hate those future predicting ones because they always lie. The ones that try to say, “oh, we’re doing this many tickets a week” they ignore the fact that there’s going to be discovery, right? There’s there’s going to be scope discovery along the way. But you don’t want your chart to go up, up up, right. When you’ve got a deadline coming up. You want it to start to go sideways and then turned downwards. Right. So keep track of those kinds of metrics and report. So I produced two different kinds of charts right, those kinds of burndown charts that move sideways and then start to trend downwards in the ideal situation. And then I produce another kind of chart, which is percent complete month over month. So I’ll have a percent like you are 60% complete with this particular scoped project. Alright. And then the next month, we’re going to have more open tickets, because we’re going to discover along the way, but the percent complete is also going to move hopefully it moves up, which means you closed more tickets than you opened. So I do that month over month, and then they can see this kind of progress graph that usually will have this curve, you’ll you’ll get a big spike at the beginning and then it’ll curve gradually down, and it’ll move a little bit slower and slower towards the end. Because, you know, when you’re 90%, you’ve got the first 90% done, right. That’s right.

Christian McCarrick
That’s right. And that brings up a good point because I often find to that what a lot of other people are interested in is also clearly if it’s a deadline or some date driven thing, that’s important, but to typically more important is to predictability like you said. You mentioned if you can consistently show progress, movement features, iterative stuff. unease goes away. They focus on something else in the business.

Eric Elliott
Yeah. If you don’t give them that, they’re going to say, We want this done by such and such date. And if you don’t hit that deadline, you’re not doing your job. Right? The alternative is you give them demos, the finished features on a regular basis. So demos over deadlines, right?

Christian McCarrick
Yeah, yeah. But that’s great. I like that.

Eric Elliott
Yeah, show them consistent deliverables, and they’ll be happy. If you don’t do that. Then they’re going to say we want this done by x date. And if you don’t have it done, you’re out of here, because they have the same problem that you have. When a developer disappears down a tunnel for a couple of weeks, and you have no idea what’s going on. Yeah, they have that same visibility problem into your work. So if you’re giving them good reports, that show, that prove that you your team is doing a good job, then they’re going to be happy. If you don’t, then they’re going to say, “we want to see this result by this date or you’re gone”.

Christian McCarrick
been there before. Yeah, I know, I definitely understand that. So I want to go into, you know, you talked a little bit about the things that you you create some charts. And clearly, you must measure, I believe, anyway, you have to measure what you really want to improve, right? You can’t improve if you don’t know, your baseline you don’t know targets. So what are some of the things that you can talk to, to our my listeners about to about what are the things that should be measured? Like what are the tangible things that you would recommend to measure, not just for good project sdlc process but also that can help you with better quality software?

Eric Elliott
When it comes to measuring? I have to caution about what not to measure. Sure,

yeah. “what gets measured gets managed”, but that’s just the first part of the quote, the rest of the quote is, “even if it’s harmful to the organization to do so”. Yes. So there’s some things that you should not measure. Let’s talk about those things first, right, perfect. So the most important thing that you should not measure is an individual developers number of closed tickets. And the reason that you should not measure that is because then you could start to manage that. And sometimes your most productive developers are closing the least number of tickets. And that’s because your most productive developers are the ones with all the answers that everybody else comes to. Right. So they’re going to have a higher number of assists, they’re going to be looking at more pull requests, and giving more feedback and answering more questions. And they’re, ideally they’re spending most of their time doing that, because then they’re spreading that knowledge across the organization and helping your other developers improve. So your other developers are 1x developers. Hopefully, this developer is helping them become 2x developers. And then that’s multiplying the productivity of your organization, so you don’t want to discourage that behavior. So mistake number one is measuring individual developers contributions in terms of closed tickets. So don’t measure that. Instead, what you do want to measure that can really move your productivity KPIs is there’s this concept of bug commit density, I say, but commit density instead of just regular bugs per line of code, which is a different measure of bug density, because commit density tells you how much rework is being caused by bugs. So there’s a simple formula. If you have a file in your code base that has 51 commits, and 14 of those are bug fix commits, then you’ve got about 20% bug commit density, and that’s for that file. Right. And the interesting thing about this kind of measurement is that if you have a whole bunch of files in your project, and you probably do, right, what happens is you get a power law curve of those commit density metrics, right? But commit density metrics. That power law curve gives you this prioritized, refactored target, because the ones with the highest bug commit density are indicating the most rework has been done on this file. Alright. And if you also factor in the recency of rework, then you can see this file is causing us bugs right now, right freshness, right? This has been getting in our way actively getting in our way of our productivity. So you can actually see those and they become hotspots that you can then tell developers let’s refactor this in the next sprint, and that can deliver huge wins because a lot of your rework is concentrated on those particular files. Sure. So if you start to look at your project in terms of health, what part of this project is sick and what part of this project needs fixing? And then you concentrate on being the doctor Being the project doctor instead of the people police, right, then you’re going to make your developers a lot happier. Because those are the files that are frustrating them the most. And those are the things that are causing them the most problems. So you’re solving the problems to the developers on the team, you’re making the team more productive. You’re shipping faster. Everybody’s happy.

Christian McCarrick
I like it. I like your term before two assists. In other things, it’s very common term, and even measure it, right. It’s sports and whatnot. Like you get an assist. But in software, it’s assumed. But like I said, it’s really I’ve really loved that term, I’m going to start using that now. I love talking to people get new terms, suddenly want to go back to my teens and then be like, did you have a podcast and talk to someone this weekend? You know, because it’s sort of suddenly I’m using some new terms I didn’t use the format teams are like, “okay, you read that blog post”. Okay, so those are definitely not measuring yet what not to measure. Excellent point. Anything else that you would recommend for managers to start measuring and/or things that they, you know, the top three things that they should do to either start measuring and or do to try to improve the quality of their code.

Eric Elliott
If you don’t have a non-predictive burndown switch from the predictive burndown chart to the non-predictive burndown chart tomorrow, that’s gonna change your life. Excellent.

Christian McCarrick
You hear that? Tomorrow, everyone, tomorrow. You’re going to go back to your teams and be like, “Did you just listen to Christians podcast?”.

Eric Elliott
Yeah, because the those predictive ones are giving you unrealistic expectations. And that happens to be the number one complaint that developers have about like the biggest problems you’re facing at work—unrealistic expectations. So you’re seeing this unrealistic expectation, you’re passing that on to your development team, and then they’re feeling the pressure of those unrealistic expectations. And that’s problematic, that’s going to slow down your team because it’s going to make them unhappy. Oh, so speaking of happiness, developer happiness is a really big important thing to keep track of and to try to improve on. Think of your net promoter score. But for your developers, right, so yep, the developers give you, you know, net manager score or whatever.

Christian McCarrick
Yeah, well, that’s, that’s great. Yeah, there’s a couple of tools I’ve used to for that. Some companies use Culture Amp. I think it’s something I’ve used a tool called 15Five in the past and sometimes it’s just how you feeling on a one to five if it’s a maybe it’s a happy face, you know, smiley face, that’s a trend and, and those are definitely good things I think is right. Yes. You talk about also in your article, it’s one of your sections when you do talk about developer happiness, right. So you just mentioned unrealistic expectations being one of the top drivers of unhappiness, anything else and then the and then after that the kind of the the inverse, what are the things that do make them happy?

Eric Elliott
Yeah, so unrealistic expectations, time pressure, being stuck on a hard problem, they they’re not sure how to tackle. All the pressure from that kind of dissipates if you help them feel empowered to spend time on quality and spend time on learning and spend time on teaching each other and mentoring each other and asking each other questions. If they feel like they have permission to ask for help when they need it, then they don’t get stuck on those problems because somebody else can, you know, another set of eyeballs sometimes comes along, and they solved the problem in two minutes. So all those things can kind of disappear. And you know, when developers get stuck, a manager comes along and says, “Hey, how you doing on this?” Right? What we don’t realize as managers is that anytime we go and talk to our subordinates, it makes them nervous. Right? They’re like, “Oh, what did I do wrong?” Right. So unless it’s in a regular one on one kind of session and setting, right, but there are other things that you need to know about developer happiness that are really, really actionable and really valuable to them. So one of those things is that happy developers are better at finding and fixing bugs than unhappy developers right there. And they perform faster at their jobs like, significantly faster at their jobs like by up to 20%. Just when they’re in a good mood. Yep.

Christian McCarrick
Yeah. Yeah, that makes sense.

Eric Elliott
Right? Right. And what we have to remember, as managers is that when we pop in and say, Hey, how’s it going? They’re thinking, “Oh, am I going too slow?” Sure.

Christian McCarrick
I’m just trying to help but it seems like you are “helping” in air quotes, right? Because you just want an update? Or you’re nudging me. Yeah. And that goes down to the, you know, do you have this? Is it a psychologically safe team you’re on? And all those things make it much better, where people are more like “Actually, no, I’ve been stumped on this problem”. “Oh, great. Let’s dive in”. You know, let’s let’s look at what’s going on.

Eric Elliott
Yeah, you really need to approach cautiously and from a place of safety, where the developers feel safe to give honest feedback. And, and that’s not always easy to do as managers. And one of the best ways to do that is to do regular monthly one on ones so that they are accustomed to you like caring about what they’re doing, even if they’re not being slow, right? Sure, no, absolutely make the normal that you talk to them on a regular basis and check in with them on a regular basis. And it’s not about hounding them on like when you’re going to have this done. And when you set that expectation, then they feel more safe and comfortable when you ask them questions.

Christian McCarrick
Since we’re on this, like, what can we do now tomorrow thing? What would you recommend a manager to come in and, you know, start doing on their team immediately.

Eric Elliott
If you don’t mind? Let’s circle back to some other things that should be measured, and that’ll help inform this. So one thing that you should measure is how many open pull requests are there. If you’re not doing code review with pull requests, then that’s another thing that you can start doing tomorrow because it will deliver serious benefits. The most important being that your team learns from each other as they’re reading each other’s code. And they’re learning new tricks. And they’re learning the best ways to do things. They’re learning the normal process for working with your code. And that helps make your entire code base more consistent, more self consistent, and that makes it easier to learn and easier to code against. And a lot less confusing and confusing code creates more bugs.

Christian McCarrick
I can attest to that.

Eric Elliott
So right, getting everybody on the same page is super important. And the best way to do that, in my opinion, is code review. So start doing that. And then as soon as you do start tracking how many pull requests are waiting for review right now, and make sure that that Q is moving sideways or downwards and not growing upwards over time. soon as you get a growing backlog of those pull requests, that’s going to be really problematic. It’s going to cause integration issues, and rework. So you want those things to be cleared within a day or so. Not to take a week or two weeks or you know, after I’ve been on teams where an open pull request took a month, two months, three months to clear, which is just ridiculous. At that point, you might as well scrap it and start over. Right. So track the number of currently open pull requests. Another thing to look out for is too many open issues. So if your number of open issues is growing instead of shrinking or moving sideways, then you have a problem. Same kind of reason except the rework is now you or your project manager, whoever’s in charge of triage issues, has more rework to do, because every time you prioritize the tickets and figure out which ones the team should be working on next, that’s rework. All right, and the more open tickets you have, the more rework you have to get through. So you have to figure out that this is work about work. It’s not work that’s contributing benefits to the users,

Christian McCarrick
and it takes its opportunity cost at the same time.

Eric Elliott
Yeah, and having too many of those things open means that it’s harder to find the high priority ones to work on next. Right. So yeah, opportunity costs gets really factored in there. Because if you miss the biggest opportunities, because you’ve got too many opportunities to choose from, then you’re in trouble, right? So watch your number of open tickets, watch your number of open pull requests, and really stay on top of that. And make sure that if the team needs a little nudging to like, Hey, you know, once in a while chime in, during like, check ins or whatever, I have my team check in daily for slack asynchronously say, here’s what I’m working on today, blah, blah, blah, I’m blocked by such and such whatever, right? You can chime in during those those check ins and say, “hey, we’ve got a lot of open pull requests. If you have time to do an extra one today, that would be great”, right? And developers will respond well to that because they’re annoyed by too many open pull requests so they feel the pain of waiting for their pull request to be approved. So they’re like,Yeah, let’s do this.

Christian McCarrick
Well, that’s it. I think that’s the other point to teamwork. Because if you have a good team, if they’re bonding, if you had, share, go Share deliverables, then you’re going to want to help out someone else who’s not waiting, like you said, right? Not only for you getting that pain, but it’s karma. And you know, helping someone else will help everyone.

Eric Elliott
Yeah, the other kind of metric that you want to look at is like, and like I mentioned before, you want to look at your bug density. But you should also look at the number of open bug tickets. Because if those start to pile up, then you’ve got real problems because bugs reproduce critical bugs, it’s going to interrupt the developers, you have to stop what they’re working on, go fix this critical bug. And then interrupted task takes twice as long and contains twice as many errors, right? Which means that if you interrupt a developer to go fix a bug, you probably just caused another bug. Yep, right, or two or three, which is really scary, right? They can start to reproduce fast if you get too many bugs in your code base, and then too many of them go critical, right? So be very careful about The number of currently outstanding bugs. Another problem that bugs cause is they mask what’s really going on in the code. And that can cause developers to make mistakes, because they have a misunderstanding of what’s actually happening in the code, and then introduce more bugs. So bugs reproduce. So it’s important to keep track of how many open bugs you have, and fix them. Yeah. Don’t let that number grow. Make sure that number is shrinking or moving sideways, a maintainable level. I don’t mean like, lots of bugs and they’re moving sideways. I mean, like… be attainable level is and not interrupting our customers work, right? It’s okay to not fix a bug that’s only affecting one guy who’s not even a paying user. Right? There’s priorities. When we talk about bugs, which ones should be fixed first, well, the ones that are blocking the most amount of value in your application, fix those first, right? And there are… It’s okay, there’s sometimes there’s a bug that’s that you don’t have to fix, right? and that’s should just not be high priority, if only one person has ever complained about it, and it’s like really hard to reproduce, and you’ve got a million users. So you know, like, that’s a very small number of your users who are actually being blocked by that bug. So don’t worry, absolutely.

Christian McCarrick
Each one of these, we could go deep dive in, go to town, I already think part of my, my role as the host of this is actually, it’s somewhat like keeping myself in check, because I love to go on tangents and go down the holes with people. And just like how I do Google searches, sometimes, like my brain, just three hours later, I’ll have found all sorts of interesting things I’ve done, but part of the podcast too, is me trying to rein in myself, and then, you know, keep us all kind of on track, so that we can kind of get some digestible information out to people. But one last thing, and this is a whole episode in itself, so I don’t want to spend too much time on it, as we kind of, you know, come to the end, but you’ve mentioned a couple times test driven development. You know, there’s a lot of opinions on this either way. But for you, maybe if you could just give just a high level, kind of what does that look like, in practical terms? What’s a walkthrough? And why do you recommend?

Eric Elliott
Okay, I’ll start with why TDD has been crucial in my experience, and then put applied TDD on a number of different teams. And I’ve seen teams that use a different process where we’re still making tests, but we’re adding the tests after. And universally the teams that actually practice TDD and test first, work better. And I’ve seen, like I said, I spent the first 10 years of my career watching lots of different companies do lots of different things. So I’ve seen a lot of these, a lot of these. And I’ve also looked at a lot of the studies on the topic and testing first can reduce bug density by 40 to 80%, which is phenomenal. I can only think of, you know, spec review, design review, code review. Those are the only other processes that even come close. close to touching the benefits of TDD by a huge margin. So TDD is a very important thing. One of the important reasons that you need to test first is because when you test first, you always see the test fail before you see it pass. Right? So you’re testing your test. So your tests are more reliable. Some other benefits are that you end up designing easier developer user experiences for the modules that you’re putting together. Because if you’re testing first, that means you’re thinking of, how is the developer going to call this function, rather than how am I going to implement this function? Right? And when you do it the other way around, you tend to think what’s the easiest way to implement this thing. And then that implementation detail can leak into the public API of that thing, and make it harder to use. Yeah, so developer experience tends to improve. When you write you write your tests first. I’m going to stop there. But TDD is also going to give us better code coverage and That leads into another really important process, which is continuous delivery, right? If you have poor code coverage, and you try to do continuous delivery, you’re going to end up in trouble because you’re going to ship bugs to production. And then some of those are going to be critical. And it’s going to interrupt your developers are going to make more bugs and you get another cycle, right? So continuous delivery, and your ability to have good code coverage to stop the continuous delivery pipeline when something goes wrong, is of crucial importance. And TDD helps with

Christian McCarrick
that. Like I said, I was hesitant to even bring it up because I knew, you know, you’re a huge advocate. And, you know, we could have another whole conversation about that maybe I’ll call you in a year since we’re going to go these yearly cycles of conversations and we can we can definitely do that once a year, just our things going great. There’s lots of things maybe if there’s any resource that you would recommend a manager looking to get into TDD that, you know, you think that they should look at That might be kind of the the seminal thing to kind of start with.

Eric Elliott
Yeah. So of course, there’s the classic was it Kent Beck wrote a really great book on the topic. That’s what got me started. But it was the practice of actually using it for years and figuring it out, that really helped. I actually kind of distilled a lot of that experience into a five hour one day training that we recorded, and we put it up on EricElliotJS.com and we’ve had customers from Spotify and Amazon and Disney Interactive and you know, companies like that, that say they really enjoyed the training and that added a lot of value to the organization’s we share this process because banks are really, really careful about quality and and they they really care about getting the best quality process some

Christian McCarrick
good ones, the ones you want to put your money in.

Eric Elliott
Yeah, so we’ve shared these we share these practices with banks and they radically transformed their organizations. Quality practice as well. Yeah. So you should take a look at those. That’s my best recommendation is, is do that, because there’s a lot of other resources out there that there’s some misinformation floating around. And there’s a lot of resources out there that don’t go into very much detail about, “okay, how do you test first?” Right? How is this even possible, right? And what kind of tests should you use? Some of them say, do lots of functional tests and end to end tests, and very few unit tests and other say do lots of unit tests and very few functional end to end tests. And you really need both to get good coverage, right? Because they’re testing different things. And unit tests give you a much, much better code coverage. And the reason for that is because they’re a lot faster, easier to implement and a lot less expensive. So developers write more of them, you know,

Christian McCarrick
exactly. And for that course, I’ll put it up on the show notes as well. Simple leadership.io as usual, any other kind of resources or books since we’ve spoken Eric, that may be something interesting you’ve read recently, you’re seeing that you want to recommend to my listeners,

Eric Elliott
you know, you asked me that last time, and I didn’t have only one. But maybe I’ll just remind the readers right. So we just talked about a lot of stuff that is really, really well documented in a novel, fictional book called “The Phoenix Project”. And if you haven’t read that, you probably should. There’s another really good leadership book that I like a lot. It’s called “Turn the Ship Around”. That was guy from the Navy wrote, and it’s a really good one.

Christian McCarrick
I recommend that again, for our listeners, I’ll put up on the show notes. Eric, one last time, what is the best way for people to reach out to you you do your website socials or all the above?

Eric Elliott
Well, you can follow me on social media and follow JS Cheerleader as well on on Twitter. And those are good resources. If you want to actually make contact. We have support forums on devanywhere.io and EricElliottJS.com which is the best ways to actually get a response because we get inundated with the social media stuff and will probably miss it. But if you reach out through the support forums on those sites, it’ll go into our little process. And we always hit those.

Christian McCarrick
And for everyone there, if you’ve enjoyed this conversation with Eric, please search for and listen to my previous conversation with him, where we discuss how culture can help your team scale. And I will also put a link to that on my show notes on simple leadership.io. Eric, awesome conversation. Thank you for taking an hour of your day. I completely appreciate it. And like I said, well, we’ll meet up again next year. That sounds great. It’s a real pleasure. Thank you for listening to this episode of the simper leadership podcast hosted by me Christian McCarrick. If you have enjoyed the show, please subscribe. And don’t forget to leave a review in iTunes. Full show notes and additional information can be found on simple leadership.io. If you knew someone who would be a great guest for the show, or you want to share your own experiences, please drop me a line. We’ll see you back next week for more technology leadership tips and advice as I interview more top so Engineering leaders

Transcribed by https://otter.ai