It’s a popular opinion that bugfixes are a good way to get acquainted a codebase. I say they’re not. Here’s why.
When a new developer starts at an organization, I find it helpful to keep the feedback loop tight. When a new developer can complete a small and easy task, then complete another small and easy task, then complete a slightly bigger and harder task and so on, it helps the developer get comfortable, gain confidence, and know where they stand.
This is why good early tasks have the following characteristics.
- They’re small
- They’re easy
- They’re clearly and crisply defined
- They don’t require any context that can’t be built into the task instructions
- They have a clear expected completion time (e.g. “half a day of work”)
Here’s why bugfixes fail every single one of those tests.
Why bugfixes don’t make good onboarding tasks
Bugfixes aren’t always small and easy
Sometimes a bugfix is quick and easy. Often times a bugfix is really hard. Some bugs are the symptoms of underlying problems that are so deep that they can never reasonably be fixed.
Bugfix jobs are often hard to define
In order to fix a bug, the bug needs to 1) be reproduced, 2) be diagnosed and then 3) be fixed. It’s hard to convey to another person exactly what they need to do in order to carry out those steps. It’s going to vary wildly from bug to bug. There’s a lot of room for a person to “wander off the ranch”.
(Note, if the bug has been diagnosed with certainty before the bugfix is assigned to a developer, then the bugfix can be clearly defined and can make a perfectly good onboarding task.)
Bugfixes can require context
Many bugfixes require familiarity with the domain or the application itself in order to be reproduced, diagnosed and fixed successfully.
If a developer is faced with a task that requires him or her to go get some context, that can be a good thing. But often a bugfix requires some narrow piece of context that’s not all that profitable to know. In this case the context-gathering work just adds drag to the developer’s onboarding experience.
Bugfixes almost never have a clear expected completion time
Some bugs take five minutes to fix. Some bugs take weeks to fix. Some bugs require so much work to fix that they’re not even worth fixing.
It’s not great if a new developer is given a task and nobody knows quite how long to expect that developer to take in completing the task.
Unless the root cause has already been diagnosed and the fix can meet the “good onboarding task” criteria above, bugfixes don’t tend to make good onboarding tasks.