Hacker News Reader

I really don't think I agree with this. The thing that's always frustrated me the most is when someone new doesn't ask questions when they don't understand something or aren't sure if they're doing the right thing then powers ahead anyway only for me to inevitably have to come along and waste even more time fixing the problem than it originally would have took had they just asked first.

Whatever the work is, the important thing is that it gets done, usually as efficiently and as good as possible. If it takes me explaining the same thing 3 times in a row to get something done properly the first time I'd rather do that than have to go back and fix things later.

And honestly, everybody starts somewhere, the best way to learn is by asking questions. If someone is asking me questions, it tells me they recognize they don't know everything, care enough to learn and are humble enough to ask for help.

Such qualities are rare in people and i've found every time, the people like that make the best employees and coworkers.

> The thing that's always frustrated me the most is when someone new doesn't ask questions when they don't understand something or aren't sure if they're doing the right thing then powers ahead anyway only for me to inevitably have to come along and waste even more time fixing the problem than it originally would have took had they just asked first.

Until you get the person who questions everything, draining all your time. Then they become reliant on you, and stop thinking for themselves.

This can usually be solved by coaching, not only for this person, but for the teammates who are spending more time answering questions.

For coaching the questioner, I ask them how they approach finding information, and recommend they time box their exploration, and only ask their question if they've given it a good try. I I also will describe my personal workflow to find answers when answering their questions.

For coaching the rest of the team, I often suggest they ask "what have you tried so far?" or "where have you looked so far?" before just giving an answer. This can help show knowledge gaps, and oftentimes the questioner will take another look and discover the answer themselves.

And yes, if they never get away from this behavior even after getting feedback multiple times, then that turns into a different sort of conversation.

I guess maybe I could clarify. I do agree there's a difference between a person who asks a lot of questions and one who just asks questions out of laziness. There's a difference. If a person is asking a lot of questions, especially the same ones over and over without any clear signs of gaining understanding, yeah there's definitely a problem, that person is dragging down work then.

But I do think there's a difference. If a person generally asks a lot of questions, but there's clear signs of improvement and they're trying to pull their weight, then I really don't see it as a bad thing.

I agree both as a junior and as a senior human.

That is what I believe you believe and I understand where it is coming from. I've managed juniors and I know they make mistakes.

That said, if a junior brings up a question like "why does this error for some tests, but not others?"

    records = some_orm_thing()
    some_model_ids, other_ids = map(list, zip(*records))

The answer is obvious. Some tests return no records for the ORM thing and that doesn't unpack. If you ask this type of question it makes you look bad. I'm not saying it's the end of the world or anything, but we should at least be realistic about how juniors are treated. A private, friendly slack message is much less likely to get them fired than a post in a channel or pull request.

My wording was maybe a little strong, I did try and clarify a bit in another comment below but, I was maybe a little bit unclear and think I might not have fully understood the point you were making. I admit, I did take it as juniors should just shut up, which i admit probably wasn't the most good faith way to interpret it.

I agree there's a difference between the kind of question like the one above vs. something like 'Why isn't there a check in there before unpacking a record?'

The first question is basically 'Teach me stuff I should know' the second is more along the lines of 'Why do we do it this way?'

And there does come a limit, if after a month they're still asking the same questions, not really seeming to have learned anything, it's probably not going to change.

I dunno, really I guess it usually comes down to the person and I hate to say it but, how annoying I find the questions and the person's behaviour.

I'm really happy you responded because I fully agree with you.

I think my larger point was that smart juniors should seek to get clarification privately after exhausting their own skill, but you're absolutely right that they should raise issues as they come up in a thoughtful way to accelerate the team and their own growth.

I agree. Whatever level a developer is, there is a mountain of tedious work to be done. Asking is more like getting directions, not taking a free ride. Good developers grow in a method negotiation skill, not in a complete autonomy, because exact methods and their details may and will be very important for future integrations. In a complete isolation, no plural number of seniors will create a good system. It’s strange to expect that from noobs.

Of course there is always a level of knowledge too low to participate constructively, but that’s another scope (fire your HR along with yet another zero-skills guy, etc).

I am in a senior(ish) position and honestly I prefer talking things out with at least one other person before making larger decisions. Even if they're a "junior" person, explaining my ideas to someone helps me see the spots where I don't really understand the problem before I get to solving it. I especially like it when people disagree with me because it forces me to construct a real argument in support of my approach.

> is that the developer that is stuck isn't really ever sure if it is something they really should know about the library, framework, or language or if it really is something hard

It's also important to know if it is a bug or incomplete implementation of a feature. Sometimes the code is over engineered or there are no docs to help understand its intent.

If junior devs get fired for asking questions, or because that makes them look like idiots, I'd take a hard look at whether they have the support needed to set them up for success. Maybe the solution is actually "don't hire Jr devs" because the organization isn't able to support them.

I think speaking up is fine. It is when ANY engineer is lazy and doesn't bother to:

  a) do any research before asking the question, 
  b) trying to understand the answer given or 
  c) doesn't follow the answer given.

I will help anyone that asks but if they are just using me for quick answers and never learning anything then eventually they will use up their credits with me. I cannot do their job and mine at the same time...

> The problem with encouraging developers to speak up when they're stuck

I'm not actually encouraging that. I'm encouraging them to not have imposter syndrome when they actually manage to fix something, regardless of their methods. The ones who ask stupid questions, in my experience, don't end up fixing the issue ever because they don't understand what they're doing enough to ask the right questions, so they wouldn't be at this point.

It varies widely by company culture. At a previous job we had a Slack channel called #dumb-questions, specifically for exactly this type of thing; a no-judgement zone where everyone could share the job of filling in each other's mental gaps (one problem with finding just a single friend to ask questions of is that you start to worry about bothering them too much; this way no one person was a choke point)

I've never worked at a place that treats juniors like that, so my experience is opposite of yours. It's totally fine for the more senior dev to push back and say, "I think you kind figure this one out, maybe look into X", but juniors should be asking questions, it's one of the primary ways to become un-junior.

I've never even heard of a junior fired for "asking too many questions".

IMHO the rule of thumb is - no stupid questions, if repeated refer to previous answer, if repeated consider firing an idiot, if it came from above you - consider promotion or giving a notice.

My intuitive response as I started to read this was a sort of "gentle-art" thought: Would it be helpful for someone to start their question: "I don't know if I should know this [already]..." ?

If the answer is [in context] indeed "yes", then that could help tune their threshold for when learn-by-self vs learn-by-others will be appropriate [again, in that context].

> developers fired because "they require too much hand holding" and I don't think the advice should be "speak up" but rather "make at least one friend as soon as you possibly can that you can privately ask questions to so you don't look like an idiot" and I know this advice is better for the individual than the company, but it's the reality. The selection function for new, junior employees is "can they get the things done with minimal hand holding" not "do they ask questions" and I'm not ok with that, but it is the reality and we shouldn't push juniors into situations that would get them fired before they're up to speed.

Thank you for saying this. I haven’t heard it being said anywhere else, but knowing people that you can DM and ask about things first is “socially” a better strategy than an ask tons of questions in a public thread. What’s also worked for me is to have a private channel meant only for developers (no manager, PM etc. Just devs, free to ask any question without judgement).

People instinctively assume the junior person asking questions is less competent.