Hacker News Reader

Comment by windward | Hacker News Reader

Out of scope for this article, but:

>Most leveling systems are too granular, with the levels separated by arbitrary characterizations. It’s makework. It’s fake science. It’s bureaucratic and encourages a non-thinking “climb the ladder” approach to career development. (“Hey, let’s develop you to go from somewhat-independent to rather-independent this year.”)

This is a funny, common requirement. Every junior developer is told they should feel free to ask questions - and now they have a financial incentive not to.

View on HN

I’ve managed a few people who have come to the same conclusion as you did there, and had a mixed success rate there.

It’s not about not asking questions, it’s about knowing which questions are appropriate to ask, and if you don’t know the answer to that it’s my job to guide you to finding it out.

I’ve never held back on a promotion because someone asked too many questions, but I have recommended we don’t promote because they’re asking questions that they should be answering themselves. The gauge of skill is “do you know what you don’t know”, basically.

In big tech these overly-granular, arbitrary systems are designed specifically to avoid this kind of variance in promotability from how managers infer the rules. If they're designed badly, you have to lie to get your example through the pipeline.

>It’s not about not asking questions

If the spec says 'doesn't ask questions', it is!

> If they're designed badly, you have to lie to get your example through the pipeline.

Agreed

> If the spec says 'doesn't ask questions', it is!

It's not. At anywhere I've ever worked, it's about meeting enough of the criteria and your manager coming to bat for you. If the spec says don't ask questions and your manager backs you, you're getting promoted. If the spec says you must make 3 widgets a day and you make 4 widgets a day more than anyone else, but your manager won't back you, you're not getting the promotion.

If your manager is a rule stickler, follow the rules. If they value breaking the process, then break the process.

But dogmatically pointing to the rules, and saying "but the rules say this" is unlikely to get you very far. To quote Geoffrey Rush - "They're more like guidelines"

I'm glad for you. I'm paraphrasing a previous employer's guidelines.

> 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….”

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.

Asking questions and unblocking yourself is a required competency for acting independently.

Developers should aim to be resourceful and respect others time, but I expect my reports to seek out help if they get genuinely stuck for more than 15 minutes (no clue what to do.)

It's much better than waiting around for your manager to find out you were working on the wrong problems (or nothing, waiting for instructions.)

Reply on news.ycombinator.com