Hacker News Reader

Comment by joshstrange | Hacker News Reader

> Every junior developer is told they should feel free to ask questions - and now they have a financial incentive not to.

This is such a fine line though, encourage developers to ask questions, but they also need to try problem-solving before they immediately go asking for help. If I _consistently_ get asked for help on problems that I can solve it within 5-10 minutes using no “company knowledge“ (just plain debugging), then that cements someone as “junior” in my mind.

Contrast that with the people who ask lots of questions but they are well thought out questions that require knowledge of the inner workings of the system.

“This isn’t working” vs “I can’t figure out X works, I tried Y and Z but that gave me this error that I don’t understand but I did find….”

View on HN

I have a similar mindset though less focused on the type of questions being asked and more about how many times I have to answer the same question.

Ideally, the number is one time. As in one conversation where the person walks away understanding the answer. If I have to have that conversation more than once it’s a problem.

Obviously there’s nuance - it can take time to get your head around a new concept or hard problem. But in any case, I like that as one dimension when thinking about a person’s skill/level/potential.

> I have a similar mindset though less focused on the type of questions being asked and more about how many times I have to answer the same question.

Yes, I completely agree and do that as well.

The focus on “type of question” has been something I’ve done more recently after helping someone out. Just reflecting on “what type of problem did I just help solve and how can I make it easier for them to solve on their own in the future”. Very often the answer is “more documentation” or similar, getting things only in my head down where everyone can benefit. On the other hand I walk away from some problems I’ve helped with frustrated that the answer was 1-2 Google searches away and the issue had nothing to do with “our stack”.

I mostly agree with you, but there’s another angle that is similar. How many times does the person come to you with a similar question but on a slightly different topic and you need to guide them through _how to find_ the answer. I’ve supervised mid level engineers in the past who will just drop a stack trace in a slack DM and expect me to tell them what’s wrong - I didn’t write the code so why do you expect me to figure it out for you. But when I have the conversation of “we’ve talked about how to dxooore these kinds of problems a few times now, next time you need to apply these techniques”,it often doesn’t land.

Reply on news.ycombinator.com