- Asking a question can be humiliating, especially if you are expected to know its answer. When a junior asks me something, I keep that in mind.

- Things that are obvious to me are not obvious for juniors. They might know X and Y but have no clue how to draw a line between them. They might not even know an alternative exists.

- If the junior does not come to me with a question, he might spend 20x actually needed time on the problem. Helping juniors is one of the best ways to meet deadlines.

- Regularly helping someone establishes trust and makes it easier to delegate to them later. More of my time saved.

- The main thing that I am teaching them is patience, I lead by example.

- I focus on explaining how to them more than what, even if I spend an hour, or have to do a pair programming session. If the lesson gets ingrained I just helped save a heck of a lot more time.

- If the same kind of questions get asked a lot, I create a doc or a recording and reply with a link.

- Different people need a different approach. It is quite likely that I am doing something wrong in how I provide help. If the person trusts me with questions but does not seem to adopt the advice, I sit down and have a "crucial conversation" with them to figure out if this is the case and adapt my behaviour.

- Some people are just stupid.. "Against stupidity the gods themselves contend in vain". Knowing when things are out of my control helps me avoid stress. That said, this is the very last resort, and rarely true. I usually try everything else before I start brushing people off and saving time for others.

*2000x. Very true.

> Different people need a different approach. It is quite likely that I am doing something wrong in how I provide help.

A thousand times this. If you think they couldn't possibly misunderstand you, think again. Then again. Every time.

> Some people are just stupid.. "Against stupidity the gods themselves contend in vain".

Sure, but check with someone else--someone outside of your comfort zone--before confirming that.

I want people to feel confident asking me questions, so I will never treat a question as nonsense or a waste of my time.

Curiosity is having a problem and caring about finding out why it isn't working. Grit is having the resolve to keep chipping away at the problem until it's solved. Patience is realizing that things take time.

Whenever a junior starts asking me things when I'm on a deadline, I politely tell them to "keep looking". I'll potentially provide a hint if it will help. Some get annoyed and scoff at me and tell me "I've been searching!". Others keep looking.

That's it. And I have the feeling that with programming being considered as a lucrative career a lot of people come into this profession that don't have these qualities and would be better off doing something else.

I lose my patience when the documentation is awful. I lose my patience when searching gives hundreds of irrelevant results. (I literally looked up a command today and half the page was dedicated to telling me how to not change a password with the password change command.) I lose my patience when simple things are hard, when systems aren't self-explanatory, when I get text dumps of nonsense rather than what I need, and when have to spend half my time wrangling with finicky tools and processes built by the people who came before me. And I really lose my patience when I realize that nobody values my time except when it wastes theirs.

I say this as someone who regularly asks for help I shouldn't need to: I can't remember our processes and policies because there is no structure to them. If anything goes wrong, there's 50 places I could look to find a solution, and knowing which ones to use and when is a process of memorization, and getting it right is so unrewarding that I'd rather not try at all.

Oh boy, this is a deep topic, but generally speaking you have to come to the realization, that losing patience is almost never in your own interest. When you are faced with incompetence or laziness, or being accused for something clearly not your responsibility or fault, it's very easy and natural to let anger dictate your response. It feels right and justified.

But this is not to your benefit. Because your goal is not to defend your standpoint against an opposition - a quick shortsighted affirmation, that you are indeed "right". But to resolve the situation in a calm, rational & constructive way. In the end you can only win, when everybody wins, and that is your real goal!

And you have to incorporate that mindset and live by it. Doesn't matter if we're talking about work issues or getting angry about people in traffic.

I know you mentioned that, but often times asking that question makes people try again, or doublecheck what they are doing. Giving them the couple of hours gives them room to maneuver and _maybe_ save face. Do it a couple of times and the people with good intentions learn to learn.

Then I got kids and I finally got it.

Loosing patience DOES NOT HELP. Ask yourself "What I am trying to achieve here, with this young padawan asking me questions? Are those questions stupid? What is the underlying reason the padawan asks the question? How can I maximize my help, what kind of response to the question supports what I want to achieve the best?"

Anyway, loosing patience only puts off the padawan and while it may help you achieve the immediate goal of not having people ask you questions I think it is just bad long term strategy. Senior people are traditionally meant to help shape younglings. If you make them not ask questions then you are very likely not doing an important part of your job.

On second point, some people need to hear that discovery and googling and figuring out and trying wrong options until you stumble onto right one is what they should do. It is not just matter of laziness, some juniors think that if they are confused and lost they are wasting time and something is wrong. They need to hear that it is ok and normal and that it is their turn to train figuring out part.

When you help people too much, they may become too used at that and wont realize when they are ready to start the harder part by themselves.

Ask if they tested it, if it worked. Let them use git history

Continue your work, help with the third time

For starters, I try really hard not to think of the professional engineers on my team as "juniors." They're adults with thoughts and ideas and a different context than me and they're better than me at many things. Thinking of them as juniors in my mental model makes it way too easy to condescend to them and be patronizing.

Second, what is one's value as a senior engineer? A senior engineer is usually expected to be a leader. People will follow a leader's examples - not just in writing code but how he carries himself. If a leader loses his patience, his team will think that is acceptable behavior and start trying to get away with it.

In the context of a senior programmer - they can only accomplish so much on their own while coding. They bring so much more value to the group by helping their teammates be better. That manifests itself in code review, in being present and available, in providing reassurance to people finding their footing, in answering questions, in showing people how to do things, and just being an all around mentor. You can bring so much more value to your group by elevating your teammates to your level, rather than being the lone all star.

Third, I would try to think about this from their perspective. They're probably worried they're not doing a good job, they're probably feeling some heavy imposter syndrome, and they probably look up to you as someone who knows what they're doing. They have no clue what you know and don't know, or why you wouldn't know something. Cut them a little slack and realize that you have a presence among them, whether you're aware of it or not.

Fourth, think of this practically. You're squandering so many opportunities to teach and help the engineers on your team grow. I love when someone comes to me and says, "this doesn't work," because it is such a great chance to teach someone how to use precise language to describe a process, which is a very important skill in software engineering. It's a great opportunity to show someone how to debug a problem!

When someone asks you something you don't know, and you lose your patience, you miss a huge opportunity to show them how to find knowledge themselves. If you'd said, "I don't know the answer to that question, swing over here and let's try to find it out," and then you drove through some searches and articles while they sat by, you could show them some of the things you take for granted - whether that's how to skim search results, what to search for, or just knowing your tools like keyboard shortcuts.

So I'd say try to reframe how you look at things and how you look at your own role, and how you look at yourself. It might be helpful to look at advice other types of leaders have - NCOs (Non-Commissioned Officers in the military) or Sergeants in police forces for example.

I am OK with this from time to time but there are plenty of people who are simply too lazy or incompetent to figure out things themselves and want somebody else do things for them. I generally enjoy helping but I know people who even after I type their question into StackOverflow right in front of them and read the answer to them they still don't get the hint to look up things themselves.

To quote Ian Fleming: “Once is happenstance. Twice is coincidence. Three times is enemy action.”

(ducks)

That being said, I can't help but feel some sense of poetic justice that someone complaining about everyone making stupid mistakes that could have been avoided if only they had spent some time thinking, made this stupid mistake.

Although to be fair, they do seem like they feel like there is something incorrect about this behavior ... perhaps it could have been put in a better way, though.

Although, to clarify, I do not mind people making stupid mistakes. Not in the least. I mind them not trying!

Seems fair to me.