This would be a pretty nerve-wracking position for an employee. Sometimes it takes a long time to hunt down a single-line change to the code to fix a bug.

I believe it's the responsibility of the person hunting down that one-line change to communicate to their team what was involved with tracking that down. Everyone can learn from a single person's deep dive. An engineer shouldn't feel like they're doing something risky for their career by carefully working through a hard problem with unimpressive code results.

If the engineer can't convey why it took a week to find that one-line, they should work on their communication skills. A good manager can help set expectations for an engineer who has underdeveloped soft skills.

I just spent a week and a half tracking down a bizarre issue in a 3rd party library and filed a fix for it. It was simultaneously frustrating and fascinating, but I never once was worried that the team didn't support my effort because I kept the team in the loop during daily standups. I've also been lucky to have excellent managers who believe in letting the engineers work.

Agreed. If it takes a week to make a line change it'd be very unusual IMHO if the entire team were not aware by that point of some the challenges involved. It may even warrant a short presentation on the technical challenges and how the issue was tracked down or solved; good learning opportunity.

On the other hand, if somebody is constantly disappearing for a week+ with a low complexity ticket, gives cagey standup updates, and then submits a PR that looks like it was thrown together in an hour.. That's a red flag that needs attention.

Daily standups make me focus on what sounds good to be doing for the next standup. A one line bug that drags on for weeks can be magnified at those meetings.