I'd much rather have someone ask when they get stuck, or even if they're kinda stuck. If someone happens to ask me a question that's easily found via poking around a bit more, I'll show them how they could have found the answer, and then they'll have learned two things: the thing they wanted to know and a new pattern for solving problems.
As a result, I rapidly find myself surrounded by people who ask smarter and smarter questions, and who can solve harder and harder problems. And I love that result.
However, if you intervene too late you can make a student go on his way for too looking for an answer that's too complex(for the time frame given to solve the problem) or that's in wrong direction(like trying to optimize a small part of a project that's not all that important) or even more commonly, the student can remain oblivious regarding a shortcut that can make his life a lot easier.
I always think of those problems when dealing with a new intern and I'm still unsure on how to deal with it, but one thing I'm starting to understand is that different people have different personalities(that are constantly changing), so they require different approaches at different moments
As the man says "there is no silver bullet".
The style I favor when the junior devs ask me questions is to ask questions right back at them, kind of like in a Socratic dialogue. This makes them reluctant to come to me for easy answers and think more about the problem first.
In the end I get a team of people with steadily improving skills to whom I can delegate ever more complex tasks.
That's been my experience at least. My very first job was especially bad. There was an entire culture built up where tech leads and senior engineers would never answer chats/emails sent by junior engineers. If you really needed a clarification, you had to hunt them down in their cube, where if you're lucky, they would answer your question without any condescension. At my very first performance review, I was even dinged for "asking too many questions."
At the time, I thought there was something wrong with me. Looking back, the reason why I had to ask so many questions was because there was zero documentation, the code base was horrific, and we were using stone age tooling. My only regret is that I hadn't left even earlier than I did.
I was contributing from day one. I had introduced unit tests to their code. I implemented a Stripe integration for subscriptions. I added new features. After receiving one of my questions, the senior dev would take a long hard look at me, thinking of the dickest thing to say, then he'd say it. The responses were always condescending and rarely helpful. I became afraid to interact with him.
No matter what I did, I did it the wrong way. He didn't offer solutions, just criticism. When I mentioned that working with this guy was incredibly difficult, my employer said that he understands, but this individual is so good at what he does, it's just something they'll have to deal with. Life is too short to deal with these toxic individuals.
I used to do that. What would happen is people learn they _dont need_ to poke, because this sucker has all the answers on a platter, so why bother.
Bad:
> "I have an error. What do I do?"
Better:
> "I have this error: {BLAH}. What do I do?"
Best:
> "I'm trying to do X. I have this error: {BLAH}. I read the documentation and tried doing Y, but it didn't fix it. How I can I do X?"
Similarly, I try to avoid giving answers that are just "change this line to x". You're just a code-fixing machine into which you pump questions and answers are spat out. Nobody learns anything that way, and you're going to answer the same question over and over again, and get annoyed.
I like answering questions, especially when this leads to someone's growth; it's a satisfaction to me when the junior goes from newbie questions to more and more advanced ones.
But, even if I disliked answering questions, I'd still very much prefer answering questions than having to clean after a junior that didn't dare to ask a question.
Seniors like to help learn, not to be used as a walking manual.
Being a wizard developer also requires a wizard manager that the developers can trust completely.
And even the concept of "search for the error message" is a pattern someone needs to learn, once. Ideally it's one they'd learn very early on when learning. But I've found that very few people talk about or provide guidance in the processes of learning themselves. Which is why I'm glad that people write down advice like the page tweeted here.
> even the concept of "search for the error message" is a pattern someone needs to learn
I suppose if we're talking about a graduate or intern this is okay, but when you have somebody that supposedly has a few years experience this is just infuriating.
There is also the point that you shouldn't be getting a graduate/intern to be doing work they haven't the capability to google the terms of ...
You know how sometimes programmers on Hacker news talk about toxic team mates who are hard to work with and bog the whole team down through arrogance?
Becoming furious when someone asks you a question and truly wishing they'd waste half a day deriving it from first principals themselves rather than just asking you and having an answer in 30 seconds makes you one of those toxic team mates.
Modern software development is a team game. The average speed of the team is what matters, not your personal speed.
Given the choice, I don't want a "10x" programmer who works alone or only wants to work with other "10x" programmers. I want a 2x programmer who turns everyone around them into a 2x programmer while becoming a 4x programmer, and who then turns all those 2x programmers into 4x programmers while becoming an 8x programmer, and whose newly minted 2x programmers turn everyone around them into 2x programmers while becoming 4x programmers.
That sort of attitude gets seriously wearing.
As long as someone isn't being willfully ignorant, I'm more than happy to help them, as them doing their job better helps me do mine better.
Note also that there's a subtle difference between senior devs and experienced jerks.
Obviously, you could have someone that will always ask and not try. My gut, though, is that spending that thirty seconds just a couple of times will save you hours of future work.