If you look at the valuation of companies that hire or were started by top talent, all companies should want them. Crab mentality can make you rationalize scaring them away.
Generally agree that rabbit holes (or as my wife calls mine: black holes) can be conducive to learning. But I suspect that there's diminishing returns. At some point, you may end up spinning your wheels and reaching out for help does not distract from learning the valuable lesson.
If you're doing a PhD, that point is a weekly chat with your supervisor. I don't see why a few hour "rabbit hole" would be a problem in software engineering. If we're even discussing hours unless billing hourly, that's a red flag for micromanagement.
Indeed. There may be a toxic or stupid management culture at that company if they're worried about someone going down a rabbit hole to learn. In my experience this is usually in teams that are run by people who don't have technical ability.
Going down rabbit holes and getting something out of it is fine, but that doesn't always happen.
Sometimes people are just frustrated and spinning their wheels, or doing work that turns out to be pointless because they failed to understand something which would have been clarified by a short conversation.
That can be measured by frequency of code commits. You can tell which juniors are making the most of a rabbit hole and becoming better versus which ones are mindlessly surfing because they don't want to think. The first group will have things to share or talk about if they go some time without committing code and their mentor or manager starts getting worried.
If someone hasn't pushed something in a week or two, that's a good time for their mentor to initiate a conversation and see where they're at and when they think they will push something.
Anything else is micromanagement by a company that has hired someone without giving them any amount of runway to actually work and learn the space they're in. You can also tell on company hardware and on company accounts if the junior's browsing history represents getting better or just resting on their haunches because they want someone else to do the thinking. Let's not pretend the micromanagement cultures where "fear of rabbit holes" exists are not already doing this.
>You can also tell on company hardware and on company accounts if the junior's browsing history represents getting better or just resting on their haunches because they want someone else to do the thinking.
Are you saying the mentor should actually go and check the browsing history of one their engineers to verify whether they've actually done "correct work" or what are you trying to say exactly? This sounds to me like micromanagement of the highest order.
What I'm saying is that they already do it and already have access to enough information to know who is making the most of a rabbit hole and who is not. Code commit frequency is sufficient in itself.
If you're able to identify these situations at all reliably, you can make a lot of money as a consultant. Like, way more than whatever you're earning right now.
“Came up with?” None of us invented Agile/Scrum/wtfe malfunction requires daily standup meetings. Management insists, management observes, management signs the paychecks, so … here’s your DSM.
