Devs and bugs — some management strategies
Throughout my career as a tech director, whenever a junior dev comes to me with a bug they can't fix, I have a couple different strategies I like to deploy...
1. When they bring me the problem, the first thing I do is tell them I'm not available to help them right away. They won't realize this, but this is sort of a trap I'm setting for them. Then I'll check in with them about half an hour later. Very often, they've already solved the problem! This is fantastic! But! Then I ask them, "Why did you bring the problem to me?" The real answer is that they were probably hoping I'd just give them the solution so they wouldn't have to work on it, and/or they thought it would take them a really long time to figure it out on their own.
So hopefully, in this scenario, they've learned they're capable of solving problems like this on their own, they feel the satisfaction of doing so, they gain a bit of confidence, and they learn that putting the time in is worth it — and even enjoyable! Solving the problem on their own also means they've learned something new and practical, coding-wise, so when this bug comes up again (and it will!) they'll already know the solution, or at least they'll know where to start poking around.
2. Okay, let's say I come back to the dev after making them wait half an hour, and they tell me they still haven't been able to fix the bug. My next step is to ask them to walk me through all the things they've tried so far. This absolutely is a trap! Oftentimes they haven't tried anything yet, and this is how I get them to admit that. Then I ask them why they haven't tried anything. One possible reason, which they'll never admit, is that they were just being lazy; hoping I'd hand them a solution. Another possibility is that they really don't feel equipped to tackle this particular problem — it may be beyond their level of ability, and that's fair, especially for a junior dev.
Of course, at this point I'll help them as much as they need, but I never just find the bug myself and tell them the solution. I'll guide them toward figuring out where to look, what to look for, etc. When they're showing me their code, I might say something like, "What's going on around lines 205 to 210? See anything weird there? That's where I'd look."
It's important to remember, we need to get the work done, we need it to be right, but we also need to focus on our team members' careers and make sure they're always learning and growing. Keep them challenged at the level where you know they can overcome the challenges as they come, and let them feel the reward of doing so. That's what kept me going as a dev in the early years of my career.
– Manning
Questions/comments? Feel free to contact me at manning@manningkrull.com. I update these articles pretty frequently — best practices evolve over time as the world of digital quickly changes, and I always welcome insights from others.