#164 - Lead Developer Career Guide - Shelley Benhoff

[00:00:59] Career Journey

Henry Suryawirawan: So Shelley, in the beginning, I’d like to ask you probably if you can share a little bit about your career journey, especially the highlights or turning points that you think we all can learn from.

Shelley Benhoff: Sure. Yeah. So I have been in tech now for 25 years. And my journey, you know, started as like a junior dev to senior and then lead. And I think that my career journey is interesting, because I’ve also had experience as an author now and a trainer instructor. I have 20 so like Pluralsight courses. I have courses on Udemy and in about a couple weeks, probably by the time this is out, it’ll already be out, but now I’m a LinkedIn instructor as well. So I’ve had a lot of interesting experiences, but I think my hardest journey was in leadership, trying to learn how to, um, transfer technical skills and then learn soft skills and then lead people. That’s very difficult for people that are technical. So that’s why I’m here today.

[00:02:20] Tips for Building Courses

Henry Suryawirawan: Wow, you have so many courses out there. So maybe a little bit of tips and tricks for people who would like to also build their online courses. I know it’s like very trendy these days, after pandemic especially. So maybe some tips from you.

Shelley Benhoff: Sure, yeah. Oh, people ask me this all the time. First of all, when you write courses, keep in mind your audience. Generally, when I write a course, I have had that same problem previously, right? I always teach stuff that I struggled with that makes the best content overall. And with online courses, especially the production quality really matters, because people expect high quality now, even on YouTube. Any platform! And when you are writing code and you are walking people through code and teaching it, increase your font size, make it like 18. Okay? Because people are watching this on their phones. So, yeah, like I can’t read 10 point font on my phone very well. I don’t know about you, but…

Henry Suryawirawan: Yeah, so neither do I. But I think those are really good tips, right? So teaching what you struggled before, right? And also keep in mind about your audience. And I think, yeah, production quality these days do matter, especially with all this, like Mr. Beast production and all these, you know, great, great content creators out there. So I think we are competing against them as well.

[00:04:28] Writing “Lead Developer Career Guide”

Henry Suryawirawan: So let’s move on to the main topic today which is your book, right? Which is you’re still currently writing, with Manning Early Access Program. So Lead Developer Career Guide. So in the beginning you mentioned that you also struggled a little bit about leadership, you know, learning about soft skills. But in the beginning, right, tell us what made you wanted to write this book.

Shelley Benhoff: Yeah. So, I guess this whole thing started, I pitched it in October 2022, so it’s been a little over a year. It takes a long time to write a book, by the way. But I was really inspired by Alyssa Miller. She has a guide on Info Sec. And I saw it and I was like, InfoSec career guide. Like there should be one for lead developers, because we’re not managers. And we’re not the person who is hiring people, right? So it’s this kind of step up from technical to leadership, but not like all the way, so you still have to do technical stuff.

But then you still, you have to learn leadership as well. And it’s really, really hard. Most people like me who excel at technical stuff are sort of just thrown into this role with no mentor, no guide, no nothing to like learn leadership skills, how to run meetings, how to interface with clients. That was the hardest part for me, was being the face of the development team to the clients and being trusted to make decisions, you know? And it was just very overwhelming at first. And as I said, if I struggle with anything, I’ll teach it after I figure out like how to do it properly. Yeah, cause I don’t want anybody to struggle as I have.

Henry Suryawirawan: Right. I think most of the engineers when they studied computer science or software engineering, right? I think most of them were not taught about leadership. Or even soft skills, like great soft skills, right? We all have to self learn books and also painful experiences. You know, having deal with stakeholders and clients, just like what you mentioned, right?

[00:06:45] The Different Lead Developer Titles

Henry Suryawirawan: Like I mentioned, there are so many different flavors of lead developer title, right? So what are some of the other flavors in the industry that you know of so that people maybe can set the same level of understanding.

Shelley Benhoff: Yeah. So the multiple flavors, I think it comes from company cultures and kind of each company’s approach to tech overall. I’ve heard lead architect. So there are some overlapping skills there. But the main thing is that if your company has a lead architect, that position is more technical. It’s more like you’re in charge of the architecture, right? Architect architecture. So you are, making diagrams and flow charts and, you know, stuff like that. Whereas a lead dev is more the person that has to be talking to the project managers, the clients, the actual team to relay all of this information, make decisions, and be trusted with that process. Yeah.

And then there’s kind of like a tech lead. Tech lead I feel like is more in line with lead architect, but like I’ve seen so many companies approach things completely differently, right? So tech lead, architect, lead dev, they’re all similar, right? But they just have some key differences. I hope that answered your question, it’s pretty abstract.

Henry Suryawirawan: And I think, it confuses a lot more by, you know, going into specific industry or big tech versus, you know, traditional companies, right? But I think we mentioned a few titles already, like hopefully people at least have the same level of understanding. Okay. We are talking about this kind of role.

[00:08:43] Leadership Skills

Henry Suryawirawan: And you mentioned that this role specifically, right, is expected not just be good at tech, which is probably in the beginning, they are really, really good in tech. But also they have to exercise their leadership skills. So tell us why this leadership skills is also becoming equally important in this role.

Shelley Benhoff: Yeah, absolutely. Leadership skills, in general, they are kind of important for everyone, actually. But for this role particularly, it’s just so hard to learn while you are trying to also be technical at the same time. But these skills like holding meetings, outlining approaches, you know, just talking to people, talking to stakeholders, interfacing with humans, is what I like to call it. A lot of us, me especially, are people that like to not talk to humans all day, right. Like we got stuff to do. We’ve got code to write and me, personally, like I just like quiet time, right? I just like to be alone and all of that. So with leadership, it’s more like you have to understand how to resolve conflict, how to assess conflict. I’ll talk a lot about conflict, because that was definitely the hardest thing for me to learn. But yeah, you have to be organized. You have to be a mentor. You have to lead an entire team, a project, a product, I don’t know. There are a lot of different aspects to it.

[00:10:28] Main Responsibilities

Henry Suryawirawan: Wow. You, throw so many different things, right? Different responsibilities, so to speak. When you get into this cycle, I hope people are not scared, right? But maybe from your experience, right. And in your book you also outline this, what are some of the main responsibilities that we should expect when we deal with a lead developer?

Shelley Benhoff: Yeah, absolutely. Lead devs, I think, one of the most important responsibilities is mentorship. You have to be able to help people grow and improve, because without that, it’s just like, people need a guide, right? And like, I personally have many mentors. But lead devs, I think, need to be able to understand dev’s problems as well. And communicate to project managers and ensure that people aren’t overtasked as well. That is a huge one. Help the project manager help your team.

And then, on top of all of that, handling client requests, making sure that when clients, and this is something that happens a lot that’s why I’m smiling, clients will try to tell you what to do and how. And they’re usually wrong, they’re usually completely wrong. So you have to find a way to like diplomatically be like, that’s a good start, but let me show you this. This other way that’s actually new and actual best practices. Without saying that, with like an attitude like I just did. Yeah.

Henry Suryawirawan: Yeah. So for people who may not work with external clients, right? You can also think client as internal clients, I guess, right? So you have business stakeholders. Yeah, we have product managers or whoever in the company when you build product. That you are given the requirements. Sometimes they give you the how as well. But yeah, I think what you said is right. So the task of the lead developer is to actually help guide this kind of conversations with them.

[00:12:42] Mentoring

Henry Suryawirawan: So you mentioned about mentoring, right? I think many of these engineers also, as they grew in their career, sometimes they have good mentors. Sometimes they didn’t have good mentors, right? How can they become confident as a mentor now, now that they assume this position?

Shelley Benhoff: Yeah. I love that you brought that up. Not all mentors are good. And honestly, having no mentor is better than having a bad one. But to avoid being a terrible mentor, I think we need to keep in mind that everyone’s experiences are their own. My experience and advice wouldn’t apply to everyone all the time. So that is why everyone needs to have a group of mentors. But leads, especially, need people to help them. Besides my book, you should also just talk to people, ask for help, because that is something I did not do and that is why it’s in my book. I’m sorry if I didn’t answer your original question. I think I went off on a tangent.

Henry Suryawirawan: No problem, right. So yeah, I think like having bad mentors sometimes… Sometimes it can give you the reverse effect as well, right? So you know that that was bad, so that you will avoid it. Yeah, you will avoid it in your next, maybe, experience, right, when you mentor people. But I think, yeah, bad mentorship sometimes can leave a lasting effect. Sometimes that person also may not want to go to management or leadership because of that.

[00:14:22] Success Measure

Henry Suryawirawan: So I think another thing that as with all this kind of role that has multi-dimensional kind of a task and responsibilities, right. Sometimes it feels very difficult to gauge how successful we are in that role, right? Some people will think, oh, I just go into different meetings, communicate with a bunch of people, you know, maybe write a bit docs here and there, write a bit code here and there, but I don’t seem to kind of like finish something end to end. So how do you actually measure for, you know, someone who is successful in this role, the developer role?

Shelley Benhoff: Yeah. First of all, I mean, hopefully, your job has reviews and will actually tell you if you’re doing well. However, that is not always the case. I would say that honestly, the number one result of a really good lead is reduced technical debt. Seeing technical debt just melt away and then stop occurring in the future. Because a person is making the correct decisions so that the tasks are performed just the one time instead of, you know, oopsie, this task isn’t exactly correct. We’re gonna push this code anyway and then fix this resulting bug later, right?

If you have a clean code base and you know what you’re doing and you make the right decisions. And you do the maintenance, do the system maintenance. You know, oh my God, I, my number one pet peeve is when people don’t do maintenance. Things break. And they fix them, and they think that that’s an okay procedure. Things should never break. If you are a good lead, your systems will be stable all the time.

[00:16:19] Getting Appreciated

Henry Suryawirawan: That’s really a great point. Because as we build a lot more features, right? Technical debt definitely pile up. As you add more people, normally also, we’ll have more technical debt. And I think some people might also have this kind of impression that if everything goes well, right? Sometimes you are not appreciated. So what do you think about this kind of a mindset?

Shelley Benhoff: Oh, goodness. I love this topic when you are not appreciated. Oh, that is the worst. That kills your motivation, right? So I would hope that you would be appreciated by your team, at the very least. In my experience, generally, it is leadership that kind of fails you in that instance. But that is really, really hard. Generally, if I’m not appreciated by leadership, I leave. And I just find another job, which is why I have unfortunately had like 27 jobs now. I’ve, I’ve had more than that. But, yeah, it’s so hard to feel unappreciated. It makes you want to just not show up and to be complacent and all of that. But I am here to tell you, you do not have to stay at a job that doesn’t appreciate you. There are lots of jobs out there. Yes, the market is very tough right now, but trust me, like there are better jobs out there. You deserve the best.

Henry Suryawirawan: Right. Thanks for bringing up that point, right, because I agree with that, because if you’re not fully appreciated and it is prolonged for a long time, right? I guess, it’s pretty miserable. You also want to feel fulfilled, right? Doing your job that you love, but at the same time also appreciated, right, as a result of that. So I think, yeah, probably it’s time to take some other jobs if you feel you are stuck in this kind of role at the moment.

[00:18:13] Career Trajectory

Henry Suryawirawan: So for people who are listening to this, probably, they are not there yet, right. In your book you mentioned about the career trajectory someone might take in order to get into this path. So maybe if we can outline a little bit, like how do you actually start in your career until you get to this position? What kind of milestones or kind of like checklist probably that we can aim to be a good lead developer?

Shelley Benhoff: Yeah. So kind of the standard path is the dev path, right? So junior, mid, and then senior lead, right? My path was actually different. My path was really interesting. I was a dev first, then a trainer, then a training manager, then a lead developer. So there are different ways to learn all of these skills. But I’ll tell you, I do wish that I had been a lead developer before I was a manager, because as a manager, I was hiring and firing people. And so it would’ve been a lot easier if I had kind of eased, if I had done the lead developer thing first where I was a leader and I was learning leadership skills. But I didn’t have to like interview or hire and fire people, ‘cause that was just awful.

Henry Suryawirawan: So, apart from the normal career path, right? If you’re an engineer, you know, you start from junior, medior, maybe some people call it, right? Mid developers, senior developers. Sometimes you also went through like yourself, right? You went through different routes. How about if maybe they have different specialty, right? Is it purely because in some people’s mind, the perspective is like most lead developer comes from the backend engineering point of view, right? What about frontend? What about test engineer? You know, what about mobile developer? Can they also become lead developer?

Shelley Benhoff: Absolutely. Yeah. I actually had a job recently where it was the first job that I ever had where they had a lead frontend developer, and I was like, thank you, thank you. Because I don’t know anything about frontend development. Frontend and backend, they’re completely different. The processes, the procedures, all of that. So I asked them for a really long time. I was like, can I just get a lead frontend on this project, because I don’t know what I’m doing and I need help. And they did it. It was the best. I’ve never worked anywhere that did that. And I don’t know why, because like I said, frontend is completely different and it’s, really grown a whole lot, because when I started in tech there was no frontend. There was no, you know, it was all just the dev, I was the designer, I was the, you know, backend, frontend. Yeah, just everything. I’m so glad that they split it up into different specialties, yeah.

Henry Suryawirawan: And these days, there are so many different technologies for each stream, right? Like, you know, you have mobile, frontend, backend, all have their own permutations of technologies, libraries, and all that. I’m sure it’s pretty hard to catch up, right? The industry has moved along so much I think compared to our time back then. So last time, I also had to do a lot of all this full stack engineer, right? But I think it’s pretty hard to be full stack these days with a lot of these technologies.

Shelley Benhoff: Absolutely.

[00:21:42] Readiness Check

Henry Suryawirawan: Another thing is like when you actually are given this opportunity, right? Sometimes you are hesitant, you are not confident. How can you assess that you are ready for this, right? Is there any kind of a science or is there any kind of checklist again that we need to think and consider about before we agree and assume this role?

Shelley Benhoff: Yeah. I love that you asked this question, because I’m actually writing this chapter right now. And overall, I mean, when do you ever know that you’re ready for anything? Parents will tell you this, like no one’s ready to get pregnant or have a baby, right? Like it just happens. You just kind of toss yourself into the deep end and see what happens. But with this particularly, I mean, I think that people will signal you. For me, specifically, like I was told kind of early on that I had leadership qualities. And so over time, I just learned more. And for me, the moment that I knew that I could manage a team, was really when I was, holding meetings and just organizing agendas and speaking publicly. And just trying to keep everything organized. Like you definitely have to be organized. But I think all of us are. We’re devs. I think devs in general have to be organized to keep our code clean. But yeah, I think that’s pretty much it.

Henry Suryawirawan: Yeah, it’s a fair point, right? I think like in any kind of roles, especially if a step up, right? Uh, you’ll never feel ready, right? So I think for those who are still thinking, okay, what kind of things you need to consume or maybe prepare, right? So sometimes it’s just a leap of faith, right? And you mentioned about signals from others. So it could be your managers. It could be your mentors, right? I think that provides some kind of cue that probably you should be more confident in assuming you will succeed in this role as well. So that’s, I think, a very, very valid point, right? Don’t try to be ready. So sometimes even like people say, when you feel you’re ready, you’re too late, right? So I think we all don’t wanna…

Shelley Benhoff: That’s exactly right. Yes. Oh, I love that. If you feel like you’re ready, you’re already too late. I’m totally gonna write that down. That was a great quote.

[00:24:12] Leadership Styles

Henry Suryawirawan: Alright, so, you mentioned in the beginning about the leadership skills, right? So maybe tell us, what kind of leadership skills that we need to think about, because leadership is a wide range kind of thing, right? You mentioned about leadership styles in your book as well. Maybe a little bit of both, so that people can learn what kind of leadership that is important for this role.

Shelley Benhoff: Sure. There are a lot of leadership styles. I talk about 10 in my book. So there’s like autocratic, democratic, transformational, transactional, servant, visionary, coaching, laissez-faire, affirmative, and commanding. So all of these approaches have been around for a really long time. So the one that you wanna stay away from is commanding. Commanding is great in the military, and that’s all. You can’t be a commander of a dev team. People need support and not pushing down to like push them to work harder or faster or whatever.

So my style, like I have a combination of a lot of them, but I guess for me, my overall approach is coaching. Coaching and servant. So I am not in charge, right? Like I am helping teams to provide quality products. I am not there to make anyone feel inadequate or slow or anything like that. If anybody has performance issues, that reflects on me as well. It’s not one person’s fault. There’s never like a problem that one person caused. There was a whole path of stuff that went wrong, right?

So leadership styles overall, you need to curate your own style, a style that will match your personality. And that’s also why you need multiple mentors to show you different styles to choose from. So it’s important to be comfortable as well, which probably won’t happen for a while. But yeah, if you just know your own style and personality, then it’ll really help you to be successful as a lead dev.

Henry Suryawirawan: Yeah, so you brought a very good point right at the end, right? So before we know what kind of leadership style, we also need to know our so called personal tendencies or characteristics, right? There are many personality tests that we can do as well. Also importantly, you mentioned about not commanding, right? I think in some places I could still think that there are people who are more commanding rather than, you know, supporting. Sometimes even maybe they do the work themselves rather than teaching others to do the same kind of work.

So I think a leadership style is something really, really important for someone to maybe find your own path, find your own style. And I think the good thing these days, there are so many content, maybe autobiography book that you can find inspiration from. And I think, yeah, maybe you can find the styles that work for you. But again, just a reminder, commanding probably is not the right thing to do in most of the organizations these days.

Shelley Benhoff: Yep.

[00:27:50] Development Standards

Henry Suryawirawan: So let’s move on to the technical side a little bit. So, in the beginning we mentioned technical debt. Another point in your book you mentioned is about development standards. So tell us why it is important for tech lead to take care about development standards.

Shelley Benhoff: Yeah. So standards are really important, because every company has a coding style or a code library of just like plugins, and yeah, all kinds of stuff. I’ve worked at places that prescribed to the point where comments were sent back in code review. If there was like a typo, misspelling in a comment, not the actual code. Like that’s not what I do, you know, like I’ll tell you it’s there. But that doesn’t have to be fixed like right then. But standards overall provide us with a way to write code on a team that looks like one person wrote it, right? So it’s all the same kind of style, overall. And just the overall kind of architecture, right? Every company should have a prototype so that when you start a new project, you don’t start from scratch. There’s already something like to use. And that, I think, is the most important part of having standards is creating that prototype, that project that people can just load and go.

Henry Suryawirawan: Yeah, so I think the usual stuff, right, like code conventions, like your linters, right? Or maybe even guidelines, how you do stuff, right? Code reviews, maybe peer reviews, right? So I think, importantly, as a lead developer, right, I think you should take this role, even if nobody cares about it. But I think you should take charge and set the standards, because the code base that has different flavors of how people writing it, right? So I think it’s very, very confusing and it won’t be maintainable in the future as well, right?

[00:30:02] Optimizing The Development Process

Henry Suryawirawan: So apart from standards, of course, the development process, right? Development process is also very important. How can a lead developer also take charge on this part?

Shelley Benhoff: Yeah, some companies have a overall process, and then each project has completely different processes. I hate that. I’m just like, every project should have the same process, because then, you know, if I’m on multiple projects and they all have different processes, then I’ll get confused really easily. So making sure that everything is aligned to your organizational standards. Listen to me sounding like a president of tech or whatever.

But yeah, it’s making sure that your process for checking in code is the same. And you would think, what are you talking about? There’s only one way to do that. No, there’s a bunch of different ways to check in code. Trust me, I’ve seen people push write to master or yeah, main. Like don’t ever push write to the main branch, especially in production. That’s why we have standards to avoid these small errors and to help the team have a guide to success.

[00:31:29] Learning From Different Stakeholders

Henry Suryawirawan: Yeah. So I think it’s a valid point, right? So if you have a process that is too confusing, right? So I think it creates a lot of variance and sometimes mistakes could happen, right? And I think you also brought up a good point in your book. That you need to understand a different perspectives of your stakeholders before you probably set up the process. Just like what you mentioned, pushing to main branch directly. So maybe tell us how people should, you know, incorporate different perspectives from different stakeholders and incorporate that in this standard and process.

Shelley Benhoff: That is a great question. I think that everyone has expertise to learn from. So learn from managers, learn from PMs, learn from designers, right? Everyone can participate in the dev process. And actually, that really, really helps, because in almost every company I’ve worked for, people were like afraid of the devs, you know. We’re all people. There’s this like mystery about us being able to control computers and just like make things happen with code. But you don’t have to be afraid of us.

And then as leads, if you show them that by asking advice of people who are not technical, when you do that, you will uncover things that you would’ve never thought of because you are technical. But yeah, like I have worked with people who were in HR and all kinds of other things. If you work at a tech company, like you’re in tech, so anyone that works at a tech company has expertise that you can use, absolutely.

Henry Suryawirawan: Yeah, So I think talking to people again, like learning from others. Or even just ask. I think it will open up a lot of new different perspectives. So engineers or developers doesn’t have to be tough people to collaborate with, right? We are all good humans anyway, right?

[00:33:36] Writing Technical Documentation

Henry Suryawirawan: So, I think another important thing in any software development team is about documentation, right? Technical documentation, API documentation, architecture documentation, whatever that is. No matter how we emphasize about documentation, it will always get neglected. It will always get outdated. So I think it’s also partly, uh, main responsibility of the lead developer, right, to actually make sure that the documentation is done and also updated. So tell us a little bit more about this area.

Shelley Benhoff: I think this is my favorite topic, that’s why I’m smiling so much. This chapter in my book was like, well-received. Everybody has said like, this is the best chapter. Writing in a book about writing technical documentation was very meta. But it is so important, because people really need one place to go for the process and for, especially, known issues. That is something that I always have. And onboarding. When you are onboarding new devs, how do they set up a machine? How do they start a project? All of these things are so important to keep your team productive.

And for me, like I just like writing technical documentation, honestly, for each project. You should have the architecture, the features, the priorities, I guess. Each team member’s role as well, is always helpful. How to contact people. Yes, I do put that in technical documentation, because if you have questions you would have a list of a whole bunch of people to ask. But yeah, and then it really helps to set the team up for success, because they aren’t asking the same questions every time. And if people are asking the same question over and over, put it in that document, so that people don’t have to ask it again.

But just be kind of cognizant that technical documentation can get out of hand. You can have too much of it, actually. I’m actually experiencing that right now. But just sort of keep it concise to the point, readable quickly because of course no one will ever read every single word in a technical document. They will scan, right, for a specific error or like term. So just kind of chunk it in a way that is, um, easily consumable to the reader.

Henry Suryawirawan: Nicely put, right. Easily consumable. So I think another tips probably is like there are so many AI tools this day that can help you also auto generate documentation. Of course, don’t assume it’s perfect, accurate all the time, right? But it gets you started. It helps you start, you know, a lot of groundwork so that you can improve it from there on. And I think the nice things about those tools is that you kind of like consume it at the same time and also kind of like tweaking it. So it’s like you are the first reader of the documentation, right? So I think that’s helpful as well in my view.

[00:36:55] Preventive Measures

Henry Suryawirawan: You brought up a little bit about maintenance in the beginning, right? It was also one of your pet peeves, probably in any kind of a software development team. In your book you mentioned about preventive measure, so preventing something before it happens. I think this is really important, especially if you have running systems in productions, right? Serving customers, real customers, doing transactions and things like that. How can a lead developer be more proactive in doing all these preventive measures?

Shelley Benhoff: Yeah, so for me, my main experience is in .NET, right? So I always knew, I was like, okay, so the caching has to be handled. The, um, app pool has to be restarted at night and all of that. Making sure that any maintenance tasks that can be automated and scheduled are, but unfortunately, they can’t all be. So in those cases, you know, sometimes even if I didn’t like really want to, on like a Saturday. I would run a process like a batch that would take hours and I would just kind of check on it and stuff. But yeah, hopefully, because that was a long time ago. So hopefully now everything’s automated and capable of just telling you, hey, I had an error, email or whatever, yeah. But just the importance of maintenance and making sure that everything is working correctly and clean.

And making sure, the one thing that has gotten me so many times is disk space. There are some error messages that will never point you to, hey, you’re out of disk space. It’ll be something cryptic or whatever. Just check the disk space, like periodically. Put like a task or like a note to just remind you to at least check or write a script to tell you if something is out or like a problem occurs. Stuff like that.

Henry Suryawirawan: Yeah, so I think these days there are plenty of tools, right? You can write automation. You can integrate agents. You can, you know, use maybe the cloud, right? Or you can even use bots, right? There are so many bots that you can integrate with maybe your chat tools, whatever productivity tools that you use, right? So I think there’s no reason why you cannot automate some of these maintenance tasks. But I think it’s really important, especially if it relates to reliability of your system or making sure that the customer is still happy using your system, right?

[00:39:44] Providing Estimates

Henry Suryawirawan: So another thing that is equally important when we go to lead developer, especially in a new project or a software development task, is that to provide estimates. I think sometimes this is the most tricky question, right? How should the lead developer approach this question? You know, when they are tasked to estimate a certain project, a certain maybe stories in a software development team these days, right? So any tips here about estimation?

Shelley Benhoff: Yes. Do not estimate alone. Ask your team. Because when you estimate tasks, you’re probably estimating them for other people. And you have the expertise. So the time it would take you to finish something would not be the same time that it would take a junior to finish something. So for every single task, have like a meeting, right? And just talk through the approach overall. Hopefully you are estimating in points and not hours. I hate estimating in hours.

There’s a reason we have story points, because we are horrible at estimating off of hours. But like with story points, it’s a ratio of complexity. You aren’t estimating in hours. You are estimating a task on how complex it is in relation to other tasks, which makes it a lot easier to estimate, because like, it could take me an hour to write like a function, right? But will it work? Have I tested it? Have I done everything? And definitely incorporate local testing as well, which a lot of people skip that, and I don’t love it.

Henry Suryawirawan: Yeah. Developers can be so confident, right, in their own skills or maybe in their familiarity with the domains or stuff that they have dealt with. Always do testing first before you even push it to production. So some people even go straight to production.

[00:41:50] 3 Tech Lead Wisdom

Henry Suryawirawan: So Shelley, as we reach the end of our conversation, I have one last question for you which I normally ask for all my guests, which I call the three technical leadership wisdom. So you can think of it just like advice you want to give us to listeners here. Think of it like mentorship from you to us. So can you share maybe three technical leadership wisdom?

Shelley Benhoff: Sure. Number one. Everybody feels like an imposter at times. We all do. Like I completely do. I have written a book and it’s gonna be published and I can hold it in my hands, but I still feel like sometimes I don’t know what I’m doing. We’re all trying to figure it out. So just keep in mind, you are not an imposter. You have excellent skills. You can keep improving and learning.

And then number two would be, the only stupid question is the one that you don’t ask. And if anybody ever makes you feel like you asked a stupid question, then they’re a stupid person. So don’t worry about that.

Number three. Failure is the best teacher. It really is. Don’t be afraid to fail. Just don’t. Because you’ll learn so much. Yes, it hurts for a while, but you’ll learn. And then in the future, when you fail again, you’ll be like, that was spectacular. Yay. I learned so much.

Henry Suryawirawan: Well, really unique wisdom indeed, right? So you cover about imposter syndrome, you cover about stupid question, right? So I think the last one is about failures, I think it’s really, really beautiful, right? I agree failure is the best teacher ever, right? If you think in your past, right, what are the biggest failure, I’m sure you will think that’s your biggest learning as well. Even though it’s painful, right? But I think we all agree that all the failures that we went through are the best teachers for us until this point in time, right?

So Shelley, if people love our conversation, they want to reach out or maybe they want to find more about your resources or your courses, right? Is there a place where they can find you online?

Shelley Benhoff: Yeah, sure. So I’m on LinkedIn. I’m also on Twitter. I, I’m not calling it X @SBenhoff, I have a podcast as well. It’s Tiaras and Tech. And then I’m also on TikTok and Instagram at @tiarasandtech as well.

Henry Suryawirawan: Nice. So I’ll put it in the show notes as well. So for people to refer to your places online. So thank you again so much for your time, Shelley. I love this conversation. I hope a lot of developers out there learn more about the lead developer’s role. And maybe the last thing is like, when can we expect you to finish the book?

Shelley Benhoff: Yeah, my editor’s asking me that too. Um, I should have it wrapped up at the end of this month, I think, at the end of the year. So it should be published online in full pretty soon. You can access chapters one through eight right now online. But then it’ll be printed as an actual book that you can buy in stores in the spring.

Henry Suryawirawan: Yeah. Hopefully it aligns with the release of this episode as well. So good luck with the rest of your publishing process.

Shelley Benhoff: Thank you so much.

– End –