Hacker News Reader

Comment by syntheticnature | Hacker News Reader

3 days? Wow. Can't say I think much of this senior member of your team, who seems to be the anti-social one here. I'm sure it breaks flow for them, but a big part of being senior is amplifying the best in those less so, and helping them improve.

3 minutes, 30 minutes, sure, I've discovered a lot of junior folks would figure things out on their own when I couldn't get back to them immediately, and tended to add some delay just to encourage trying a little harder before contacting me. I would say even 3 hours has value. Buy yourself a rubber duck and have a heart-to-heart about your problem.

3 days is going to result in lots of folks getting stuck in local minima, likely confusing themselves in the process. To be clear, sometimes a problem requires a deep dive, or there is no one who can provide useful help. Even then, some guidance just to get outside perspective is helpful.

View on HN

I would argue it depends on the context. Of course, gaining enough experience on which contexts are worth persevering for which duration is it's own thing.

The rubric I give to juniors is a bit more simple: if you get stuck, consider alternatives that you haven't tried out. Alternatives are of a few types including: relevant evidence/facts you can gather that you haven't yet gathered, and attempts you haven't tried yet. As long as you have alternatives keep trying them (gather evidence, make attempts). Once you run out of alternatives then seek help (avoid spinning wheels).

This way when a junior comes to me I can ask them to list the alternatives they have already tried. If they haven't tried obvious alternatives (gathered facts and reasonable attempts) I send them back. If they've tried all the alternatives I can think of then I get involved.

I'll note that this tends to work when contact between team members is relatively frequent (e.g. once a day) so I can get a sense of how long the junior has been working on a task to avoid rabbit-holing.

I think with regards to new hires, go for the quick question up front every time. Onboarding people fast is an investment with high-ROI.

It's a really bad sign if someone keeps asking thirty second questions three or six months into the job and hasn't figured out how to answer those themselves yet.

It's a really bad sign if they keep asking you the same questions.

But when someone's new? It's your job to help them get up to speed. A thirty second question is probably something like "is there a reason we use Azure instead of AWS" or "do you want me to use library A or B, I see both in the codebase," not something that they'll benefit from diving into for three days.

Pre-internet/stackoverflow, pre-AI... I'd easily spend 3 days working out how to solve a problem that I hadn't seen before. Asking others generally didn't help anyway because they hadn't seen it either. So, if that was the formative experience of the senior person, I could understand where that attiude was coming from.

Today, yeah 3 days is a long time to spend researching and spinning your wheels. But it's still the best way to learn.

> Asking others generally didn't help anyway because they hadn't seen it either.

Fair, and there are certainly some kinds of problem for which asking questions is unlikely to help because it's untrodden ground; and for learning skills, answers are indeed less useful than practice.

But that's not the only kind of problem to be encountered. As sibling commenters point out, questions like "hey, why did we pick Azure over AWS (and is that likely to change at any point soon?)" are questions that _no_ amount of research is going to resolve, because the answer _only_ lives in people's heads. That's not about _learning_, it's about going to the right source for the information.

more importantly there should be a time once a day where asking is not a disruption. you are not in the flow for 3 days in a row. we used the daily standup for this. or any break time.

Reply on news.ycombinator.com