I've been in this career for almost 20 years. I've climbed the ladder from junior to senior to team lead/manager throughout, and for the past year one of my responsibilities is delegating tasks to my team which ranges from veterans of our codebase up to fresh out of college graduates who have varying skills to work with.
Throughout my career, it seems the typical course for anyone new is to start out being handed bug tickets, usually low-priority ones so they can fix them at their own pace. The idea of this is to give them raw exposure to the codebase and figure out how things work. It's what I did as an engineer throughout. And for me, it kind of worked. Many of the bugs were simple enough for me to figure out on my own, and I had help with the ones I struggled with. Some dev teams are more strict about this than others. I've been in places where there was a very strong line between, "Support Developer" and "Feature Developer" where it seemed to be a mortal sin for any support developer to ever work on any ticket marked as a 'story' or any feature developer to work on any ticket marked as a 'bug.'
However, my experience as a manager has revealed this might not be the best approach. I work for a fairly large company that my smaller team is sort of ancillary to. We kind of are our own independent team that works mostly autonomously. Their approach in their larger teams are similar to what I've seen before: Maintenance devs who fix bugs are typically the junior devs who have to prove themselves before they're promoted to more mid-level or senior devs who would then work on new features. It's a pattern I see in a lot of dev outfits.
I apply the same thing here, and I've found it seems to result in less productive work. We have three new developers:
-
One is among the weakest skill-wise. He graduated college recently in comp sci, and seems to lack motivation and gets frustrated easily. The bugs I assign him are not too difficult, yet he struggles with just "where to start" troubleshooting, seemingly opening random files to figure out where to go. I've tried to give him some help with methodology but he just doesn't seem to "Get It." However, I did give him a few net-new feature stories which he seemed to be able to figure out quicker than bugs.
-
Another is fresh out of college. He similarly struggled with bug fixes albeit not as much as the one above, but when we assigned him a few small improvement/new feature stories, he excelled far greater in that.
-
Another is another new hire, but he is more senior level. We basically gave him a couple bug tickets before sending him into the fire working on some new features. He's proven himself in that.
The pattern I'm seeing is the inverse of what seems to be the defacto norm. Bug fixes are more easily solved by those well-versed in the codebase, especially those with code ownership. Now, really, this certainly makes sense. After all, it's easier to fix something you built yourself rather than come at it clean and having to figure out the moving parts before coming to a cause and solution (often times fixing it with a poor approach, requiring alterations in the PR). New features, on the other hand, you do need to know enough of the codebase to understand the patterns and overall architecture of the software, but it's more on a big picture level usually, so you're more apt to be able to accomplish something sooner than you would sorting through lines of code to figure out a bug.
For the second developer, we decided the senior dev who worked primarily on that part of the codebase and has ownership of it should be the bug fixer, while the junior should work more on new features rather than bug fixes. This approach has worked well for us. The bugs get fixed quickly, and with some assistance, the junior is able to produce those new features. And he may then become the owner of some of that codebase so he can then work on bug fixes as necessary.
It seems there is sort of a stigma among developers who's primary purpose is to "fix bugs" rather than "create something new." And I get it... it's more exciting and rewarding to create new stuff rather than fix what broke, but from a performance standpoint, it seems more effective and time efficient to let the seniors handle the bug fixes for what they had previously created, than let the meek juniors inherit the machine the seniors created and figure out how to fix what was reported broken.
Certainly there's going to be exceptions to the rule. And obviously there are lots of new features that require an experienced architect to come up with at least the groundwork and scaffolding necessary to build the feature. Juniors can't do all of it on their own and they'll need mentoring and assistance from the seniors. But in my experience, bug fixes just doesn't seem to really help people learn the codebase as well as people seem to make it out. Not saying they don't learn anything but I have seen better craftsmanship skills developing by having them work on smaller feature items and work up from there and, over time, gaining more and more confidence building bigger and more complex features with the help of seniors and leads. Juniors can still solve bugs, but I don't think it should totally exclude them from ever working on new features.
With that, they do gain some experience with troubleshooting because they're going to be troubleshooting what they built. They can adapt those skills to cases where, for instance, a feature owner leaves the team, requiring one to inherit the codebase. A suitably experienced dev who's worked on the overall codebase and likely certain things tangental to the feature set can still be an effective problem solver.
Is there something I'm missing?