A worry junior engineers frequently have is that they ask too many questions | Hacker News Reader

A worry junior engineers frequently have is that they ask too many questions

twitter.com

104 pointsluu73 comments

The perennial impostor syndrome problem is not so much worrying about asking questions, it's the lurking fear that asking questions means you don't already know and are therefore bad.

At least for myself, this manifestation is not "oh i don't want to be a bother", it's "if i ask questions {my peers will sneer at the idiot, my boss will take note that i'm disposable ...}".

This failure mode has, at many times over my academic career, been really vocally reinforced by my peers at the time. It's extremely damaging, really stupid groupthink that usually winds up with a silent classroom of people too cowed or proud to admit that they, the student, don't already know the material that they're here to learn. And it produces engineers who have to consciously force themselves to not do that, in industry. Like me.

I think this really hits the nail on the head. People naturally associate competence with a sense of self-worth, which isn't always a bad thing, but can become one. It's very strange to me because even when I know there's no reason I would be competent at a particular thing and it's perfectly fine for me not to be, I still struggle with fear that I'll be looked down on if I'm not good at it.

I went skiing for the first time in my life recently, and even there I had a substantial fear around looking like an idiot, despite the fact there should be no expectation I would be any good at the sport, in fact I should be quite bad. It didn't stop me from doing it, but it did mean I needed to spend conscious and concerted effort reminding myself that it's okay to be bad at something when you're learning.

Engineering and asking questions is no different.

EDIT: a necessary addendum to this is that it's important to be cognizant of the time of the person answering the question. If you find yourself asking the same question repeatedly, or asking questions that were addressed by resources you had previously been directed to, or asking investigatory questions that would require the answerer to do your research for you, you may require a bit of self-reflection.

Have you read Feeling Good? It has a part about mastery vs pleasure, specifically how they are independent.

https://en.wikipedia.org/wiki/Mastery_and_pleasure_technique

The fear for me is less about seeming less intelligent or having low self-worth and more about seeming like I haven't looked hard enough. A lot of the time, I can find the answer after 3 hours at work just by trying a bunch of things but it's hard to know when it's better to stop looking and start asking questions to unblock me faster.

When I try to learn a new skill with the help of the professional, e.g. hire a ski coach, I usually get compliments like "you're learning it faster than most people". I often think that they probably tell that to every single customer but damn it feels great. Playing on insecurities is powerful.

One thing I have seen work to get people to build up confidence, healthier interactions etc is to break up large groups into groups of 5 and give them a reading list, where one person every week is appointed to talk about a paper on the list.

So 15 minutes present thoughts on the paper, 15 mins open for questions, doubts etc, 15 mins to go around the room where everyone talks about something they have learnt over the past week or some issue they have run into.

The small group setting makes a big diff. I have seen lot of introverts feeling comfortable enough to open up and grow confident dealing with groups.

My favorite working situations are when asking "stupid" questions and/or burning 6-12 hours on a subject is normalized and endorsed. I don't expect to live long enough to transcend anecdote, but both are necessary to learn and that's almost always important. I certainly had this in academic environments but they were somewhat cloistered or the educators expected them to be. In jobs like sysadmin/programming 6-12 hours on a thing could be 1 day or 15.

The 30-90 minute rule is to force people to search for answers themselves. If you don't know why that's necessary, I encourage you to spend several hours answering questions on sites you browse for answers (SO, HN, reddit, IRC, twitter, discord, slack, zoom, signal, mailing lists, GH issues, bugzilla, phpbb, anything) -- it'll take less than a week. People exist that don't do basic reading or research and will expect you to do everything for them. You'll get jaded.

The downside to this environment is a sort of pathological self-reliance. That's when these rules become upper limits: to keep someone from chasing waterfalls ( https://www.youtube.com/watch?v=NoKufWbP_L4 ). Collaboration always helps, some personal research is always needed... when to mix them varies.

Yes this is real. We all like to think asking questions doesn't make you look stupid but the reality is, it does. That's why most humans (men especially) have an inborn fear of asking questions... it's actually an evolved trait. Think about it, you have this fear regardless of what kind of person your mentor is...

All these little hang ups that humans have like biases and jealousy exist because they helped us survive natural selection. Ever wonder why evolution hasn't already put in place the behavioral idealisms we strive for? Possibly because that type of behavior didn't actually help us survive.

You are a petty person who lacks self control and is too cowardly to ask questions because in certain ways these qualities can actually be good for you.

It goes even further then this, because there's a huge possibility that asking too many questions IS actually a good metric for how stupid you are. If evolution evolved in you a fear of asking questions, it may be that this was an evolutionary response to another evolved trait of people accurately judging intelligence by measuring the amount of questions someone asks!

Is there any data correlating IQ and amount of questions asked? I would like to know.

> We all like to think asking questions doesn't make you look stupid but the reality is, it does.

This is the opposite of my experience. I hear alarm bells when a junior engineer says they understand something without asking many questions. Conversely, those who ask the most questions stick out as engaged and intelligent. Even silly clarifying questions often reassure me that the engineer is diligent and doesn't want to waste time due to silly misunderstandings. That's not something I 'like to think' based on some theory I'm pushing. It's just the pragmatic outcome of years of experience of junior devs fucking things up or wasting time because they didn't make sure they understood something first. Even if you're right that somehow we evolved to find people stupid when they ask questions, I imagine that would play a tiny role compared to the intuitions we develop from actual experience on the job.

https://www.boredpanda.com/socially-anxious-girl-friendship-...

The above is an example on how the entire school thought some girl was stupid because she asked too many questions. They were right in a way but also wrong.

This is anecdotal evidence, but the fact that an entire school thought this way makes it pseudo statistical as the population of a school is quite large.

The quality of the questions you ask matters and yes like all inborn behavior it can be overridden.

Richard Feynman's account of teaching in Brazil talks about this.

I tend to look at it from a slightly different perspective, where it is about he type of question you are asking. Such as:

1. Information gathering - If you generally know where you might find the info or is low priority, try to find it on your own first before asking someone to find it for you. If you have no clue if the information exists or know that someone can take a minute to give you information that you would take 30 minutes to find otherwise, then go ahead and ask right away.

2. Blockers - If you are stuck from progressing then don't hesitate to ask. Even if the person can't help you right away, they at least know that someone is waiting on them.

3. Decisions - Think on these questions a bit and try to determine the path forward before going to the person to make a decision. The more junior you are, the more you should present the details of all sides, where for a more senior person they can just give a quick justification why they want to go a certain route.

Overall, it is better to err on the side of asking too many questions, you can always turn away a person that is bugging you too much. If I think someone is asking questions they should figure out on their own I have no issues giving a friendly, "Why don't you take a stab at it and let me know how it goes." The person that doesn't ask enough questions is far worse, as they could end up days down a wrong path or wasting time spinning their wheels.

Definitely agree with 3. a lot. One thing I find with juniors is that they always want the right decision to be given to them, yet, it's important to do self discovery.

Sometimes people think that getting inexperienced people to try and help themselves is simply because the experienced don't want to be bothered or are being lazy.

But that's not the case at all.

At some point it's important to make a choice, any choice instead of being paralyzed and do nothing but wait until an experienced person tells you what to do.

I mean, that's the key of being experienced. Having been there before, having made the mistake and learning from the poor choice.

At some point it's important to make a choice, any choice instead of being paralyzed and do nothing but wait until an experienced person tells you what to do.

Totally agree with this. Part of a senior person's job is being the safety net for a junior person when the decision is bad, but the decision itself is unimportant to the pedagogical process. It's getting practice investigating and making thoughtful decisions that matters.

I'm used to not holding back at all and asking as many questions as I please. I did this in school, I did this at university, I do it now at work.

At some point, I think it was the second year of university, it occurred to me that I was the only one asking questions in my physics class. And then it slowly dawned on me that this wasn't restricted to this particular class! Come to think of it, I seemed to be the only student doing any talking.

I turned a bit red in the face and realised I might have been making a fool of myself. After the lecture I quietly slinked over to the professor and privately apologised for wasting his time with so many questions.

He had this confused look on his face and then he very quickly corrected me: "Oh no! You have it all wrong! We love it when students ask questions! That means they're engaged and listening!"

I actually didn't entirely believe him, until ten years later when I was teaching a bunch of junior techs how to program in PowerShell. I was faced with a room full of blank stares and slow blinking. Except for one guy. He kept asking questions. Question after question.

I loved that guy: I knew he was listening. I knew he was trying to understand.

In that moment, I finally understood my university professor's comment.

I find that the opposite problem is more common - the 30 minute rule of thumb, to me, is to make sure that people don't spend more time stuck than that.

In a lot of domains of life, people expect you to know the answers, and become peeved when you don't. Much of software engineering is research, where asking the right questions is the job itself.

I tell people I'm mentoring that the maximum time they are "allowed" to spend stuck is 2 hours. (Nobody is policing that, just for emphasis). Ask as soon as you feel like it, but if you haven't made progress in 2 hours, you gotta reach out or else it starts to spiral.

I think it takes courage and humility to ask questions, qualities in the world that are often in short supply. The more we can provide positive feedback for embodying those values, the more we can all live up to them.

"asking the right questions is the job itself"

^exactly

Hard to know what the right questions are until you've asked enough wrong ones.

^ and who decides what question is a right one vs a wrong one? There are obvious ones but wouldn’t the “right questions” be in the eye of the beholder so to speak?

"There is a skill of knowing when and how to ask questions, and this skill can be learned." ^ this

Ask the questions well and more senior dev isn't going to be nearly as annoyed and be way more willing to dive in and help. Show that at a minimum you understand why you are stuck.

"This doesn't work, help" is bad.

"This doesn't work because when X happens I get Y instead of Z which is what would have expected" is much better.

That is such a good point, and thinking about it makes me realize why certain help requests bother me and others don't.

Explaining how the result differs from expectation when asking the question makes answering the question so much easier.

Agreed. Often the answer is embedded in the error message, but people see an error and come to a stop instead of reading and thinking.

I dunno. Some people really don't like being questioned.

I was porting a network management (SNMP) app to Java & Swing. The app had no documentation and I'd never done anything like SNMP before. The only requirements given were "make the Java app look and work exactly the same." Can do. To respect my manager's time, I batched my questions together for the upcoming 1:1. I was told that if I couldn't figure stuff out on my own, perhaps I should find another job. Um, ok, I guess I'll figure it out.

I was trying to explain why burying blocking I/O under layers of abstraction (Spring FTW), and just eating the exceptions (no logging), makes debugging the app a wee bit harder. The "senior architect" expressed surprise that someone with my experience didn't understand design patterns and brushed me off. Um, ok, I guess I'll just have the debugger break on every exception.

I considered myself tenacious, if not especially fast. And I have zero problem admitting "I don't know".

But experiences like this have made me gun shy.

You have to realize that sometimes, your work environment is just not good for asking questions. I've had the same experience in recent years. My whole career I haven't been shy to ask questions, until I started working at a certain client where a certain developer would react negatively when I'd ask questions. But that's just one particular case.

I know it's not always a feasible option, but perhaps you should find another job indeed. That sounds like a very hostile work environment.

Asking questions people can't answer that they should be able to answer makes them angry. It isn't more complicated than that, you just triggered their "impostor syndrome".

Sounds like a case of an insecure manager and architect not wanting to admit that they don't know either, so they use their status as argument why they're right and you should automatically know what they know.

It's utterly unreasonable, but probably far too common.

I have some seniority now and I still get shit for asking questions. I think there are a lot of assholes out there in a lot of companies that make people feel this way. In particular, I've met many smart and insecure people in tech that like to make others feel bad for not knowing something; I suppose that's human nature.

There are too many egos in this industry, probably egged on by the hiring process. After 20 years I realize that a good team player is far more use than an algorithmic whizz kid.

I wrote a bit about this a while back and I largely agree and think she’s right: https://zalberico.com/essay/2017/02/21/asking-questions.html

There’s a lot of nuance to this I think is worth going into. How to do this well is both how to ask questions as a new engineer and how to make junior engineers feel comfortable doing so.

People are often afraid to ask because they’re afraid to look stupid (or worse, afraid they are stupid/can’t do it, etc.)

This is a mistake for a lot of reasons, the smartest people I know ask more, say when they don’t know or understand something and as a result learn faster.

A good lead will also direct when they should spend some time figuring it out or where they should look to learn more. I think it’s good to encourage people to ask early and often especially when starting out. It’s also good to reinforce this by example (asking questions yourself as a senior engineer when you don’t know something).

The worst thing someone can do in response to a newbie’s question is feign surprise, “you don’t know what X is?!” - whenever I see that I shut it down.

Really agree with this and your approach of batching questions. Yes asking questions can be an interruption, but it can also save so much time in terms of preventing you from spinning your wheels and the potential of taking things in the totally wrong direction and having to undo your work later.

> Learning from messing up does NOT come for free.

This is a bit further down in the thread, but really is the core point new engineers need to hear.

Many of us have sat through retrospectives after spending hours writing up what went wrong and even more hours fixing a problem. Sometimes the problem has arisen because the person making changes should’ve asked more questions or looked for more answers regarding the system they were changing.

The only problem I’ve ever had with questions is when the same question is asked too many times. That can mean a few different things, maybe that the team’s documentation is poor, but most of all it means that the person asking the question isn’t learning from the answer.

Just ask the question. There's no sense beating around the bush. Chances are someone on the team might have the same question and didn't ask it. That's what my peers have told me at least.

If you ask alot of "dumb" questions (e.g. junior level questions while in a senior-position role), you might not be the best for that company. Someone made a mistake down the line in hiring you, likewise you oversold yourself. If a company does not support you learning and getting up to speed with what you should know, it might also not be a great fit for you either. That's not necessarily a bad thing either.

Assuming you did your research on the company, and were a good fit for the company, there is no "dumb" questions. It's the company's responsibility to hire the right person for the right seat.

Many times you have to ask a question because implementing solutions can be complex. There's multiple solution paths, each with its own pros/cons. You also may not have all the contextual information you need to make a well informed decision. You need to know who to ask for what information, so fire away with questions.

Sometimes you get stuck on a problem, but if you know someone already has solved something similar on your team, just ask how they did it. Likewise if someone asks you in return. Knowledge gating doesn't benefit anyone, especially in this industry

I don't think there are stupid questions or even poorly worded questions. Even "bad" questions like "It's not working, help!" are a learning and a teaching opportunity, which I think is mostly up to how the more senior developer responds and works with the more junior one. It's true that "it's not working, help" is not all that actionable by itself, but I assume we all had moments like that when we were learning to write code. I certainly did. (and still do sometimes lol).

I think the tweet thread's thesis is "allow messing up," which I'd couple with the senior developer's responsibility to be nice and friendly and supportive. Anyone's first dev job is going to be a formative experience and if they ask "stupid" questions and are met with kindness it's going to echo through their entire career, the same way being met with rudeness would also have a lasting effect. I don't really have any hard or fast rules about how juniors should ask questions, I don't think they're really necessary as long as you make them feel supported and comfortable in a general sense.

This is a question of time wasted vs time invested.

Are there times when asking immediately is more efficient? Absolutely.

Are there times where asking my roommate to do my homework would have been more efficient? Absolutely.

Now what about if you encounter a similar (but not exact) problem in the future? Do you have the skills to figure it out now or do you still need to ask?

In both cases, when you view the time to work through a problem as wasted, you're failing to invest in your future. Take the 30 minutes to read the documentation and understand it, everything is not a sprint to "make it work".

What if you don't have a solution after 30 minutes? Take another 30 and write down your problem. If you can't clearly explain your problem in plain language (including background, code snippets, links, screenshots as needed), you probably should - as a matter of courtesy prior to bringing anyone into a surprise debugging session.

One thing missing from this discussion is that being a junior engineer often means you are inheriting someone else's code and, in general, a large number of assumptions or decisions.

So a big part of the issue is that senior developers do not realize how many assumptions or system decisions are built into their system, and therefore do not realize they need to tell the new person about that stuff. So coming onboard can involve a lot of what amounts to mind reading. Sometimes things that actually are not the least bit obvious seem obvious to the senior person, so they may indicate (inadvertently) in their tone of response to a question about them that it was a dumb question. And so that makes the new dev try harder to figure out what the assumptions are without asking.

Generally, the people that say junior engineers ask many questions are not the people that have to answer the many questions.

The people that can answer the many questions are very busy senior engineers. They have their own questions and things to do in their projects.

Some of these senior level engineers put out articles, books and video presentations on technical topics, that can answer most junior engineer questions.

Junior engineers have the entire internet and wealth of content to read and analyze.

Engineering is about solving problems. Junior engineers have to ramp up quick and be able to solve problems, with or without help from others.

Additionally, how does the junior engineers know the answer to their questions are correct? They still have to do their own research to verify the answers.

The problem with 20 minute rule, is that there is just so, so much arcane knowledge embedded into systems we really should not make everyone spend 20 minutes or more each time.

So many little things especially - it's the job of the people holding the knowledge to spread it so they can be unencumbered by it.

I never want my jdevs flailing around wondering why this or that was done, re-inventing things we've already done, going down rabbit holes we've already been down.

Batch them and ask.

Other devs have to get with the fact it's part of the job there's just now way around it.

Figure out a way to socialize it ie open hours, or extensive training etc. - or even - better documentation.

To add to your comment, when you do get a question that the junior dev has been sitting on, it's a good indication for you that this area of the system needs better documentation. If following the 20 minute rule, when you do get a question, it might be worth spending 20 minutes to answer it (and provide appropriate background) as well.

Right now, I'm a junior software engineer at my company and I've been non-stop asking questions. This is what I notice after asking questions.

1. Most People Like Answering Questions

I notice that most often people are receptive to answering my questions. They like giving quite in-depth information about the project or certain parts of the code. Sometimes even more then what I was asking. In fact, sometimes they explain about parts I wouldn't be able to google or search up because it pertains specifically to the project.

2. Knowing when to stop.

Sometimes I notice some people do get annoyed at my questions so that's when I know that I should stop for the day. Knowing when to stop is also a skill to be developed over time.

3. Batching Questions

This both helped me to understand what I didn't know and be able to verbalize it. I write down my questions and 3 things happens in this process.

One result is that I discover the answer to my question. I was framing the question in the wrong way. I either know the answer or through framing the question realize what is the answer.

Second thing is just clarifying whether the question is something I am able to search or find on the web. This tells me it's that my knowledge on this topic or subject requires more research on my part.

Lastly, it displays that I respect the other individual's time. My working time is not worth the same value to the company, wage or impact as the senior engineer. Usually, they have more responsibilities and important tasks to delegate or manage. By batching together questions, they know that I made the effort to list these questions to ask at the same time.

All this is what I gather after 1 month of working at my company.

Edit: Also I stopped caring about looking competent. I feel confident in the fact that if I don't know something, I'll be able to find it or learn it. Rather than, being confident in my own ability to appear smart or look competent. That at the end of the day is more important to me. Competency in engineering is managing what you don't know and learning how to find the resources to tackle what you don't know.

I've found slack (or other asynchronous tools) to be helpful for this. I'm able to ask a question without actively interrupting someones work. Once they get to a breaking point they can respond.

With caveats. In my workplace I’ve seen people (well, one person in particular) frequently use @here for non-urgent questions, which is frustrating.

To all the juniors reading this: Don't worry about looking stupid, just keep asking questions. In my first year programming I asked my boss so many questions that he actually got pissed once and lost his cool on me, but that went right over my head. Nobody will fire you because you are asking for more detail around something or wanting to know why or how something works. But you will def lose pts with managers if you don't finish projects on time. Just ask those questions and finish your work ahead of time :)

We have an unofficial motto of 'unlimited questions remaining'. This came initially from supporting our customers via live chat (SQL charting tool, so live help with SQL, analysis, etc) and that percolated throughout the company, especially on the eng team.

Like others said, I'd rather someone ask than spend 30 minutes spinning their wheels and not making progress. Even if it's asking where to look for something.

I think our explicit policy has helped, people certainly reference it as a positive.

If a junior can plan and ask the appropriate question, it's invaluable. But I'd rather they ask than wait 8 hours and spin their wheels.

When I joined the current team/project at work I felt the same way. It was a pretty big project and I wasn’t familiar with the structure and some of the tech. I did ask a bunch of questions, but I always felt weird about it.

Now that I’ve been part of the team for a while, and we gained some more new people I’ve been very keen on making clear that they’re always welcome to ask. Seems to be working!

My anxiety about asking questions diminished considerably when I started taking more time to formulate them more carefully.

So I guess I don't think the difference is "too many/too few". It's "did you take the time to ask a good question?" followed by "did you take the time to make the answer available to others / future-you".

As a senior tech, I make it a point to tell any new techs that the only stupid question is the one you don't ask. If ever there was an enemy in life its ignorance. Everyone's situation in life is different, but in the small sphere of influence I have sway over I do my best to make sure no one is made to feel small for asking questions.

One factor is people not wanting to do work for others or to force others to do work for them. What sometimes works to defuse that is to make an attempt at progress and then ask why that is not quite right instead of asking how to move forward as soon as ambiguity or some kind of blockage comes up.

I wonder how much of this fear is related to continuing attitudes among hackers that unless you ask questions the "right" way, the folks who could best answer your question will sneer and dismiss you as "stupid" and say you didn't "earn" an answer?

I feel this. A good way to mitigate it as a good senior / mentor is to kinda go out of your way to actively help the juniors and specifically tell them that they should ask more questions, and help them understand when and how it is appropriate.

As a senior dev, I only ask that a simple google, confluence or stackoverflow search be attempted first. Otherwise, ask away. Honestly, when you’re not looking, I’m probably going to stackoverflow. Actually, I don’t even hide it anymore...

Yes -- super important to be candid and tell the junior dev that this is how they should be approaching being stuck.

I mean I definitely judge people based on how many questions they ask - not that I think asking questions is a bad thing, but more like part of being ready for promotion is no longer having to ask certain questions.

A lot of this fear is because the uninviting style of some peers/managers.

Ideally, good engineers are made, not born.

This means everyone, but managers and leadership in particular, need to be willing to help foster a good learning environment.

I sympathize. I don’t remember where I heard it but I parrot a quote: “There are no stupid questions, only stupid answers.”

I interpret this as ask anything you want, you won’t be judged for asking. I will be judged in how I answer.

I was told once use the Microsoft rule. If you can't figure it out in 20 minutes ask.

I try to investigate as much as possible before asking. It can cut down the number of questions and you can focus on the important gaps.

I’ve been a senior dev for many years. People ask me a lot of questions all the time. I also ask a lot of questions all the time. Q&A is just a very effective mode of communication.

Ask them.

Be a good human and make sure people helping you get answers know their efforts matter. If you have personality, this all can be fun. If not, and there is no shame in that, do your best to communicate it back anyway. If you mean it, chances are others will grok that meaning. Good as it gets.

Be humble. One upside of working with people who may be smarter, wiser through experience, is the good tends to rub off. More good happens when you seek it too.

Seek this in your life when you need or want to grow. Truth is, others often see something like that and think back to their own growth and it is fun to see and be a part of. This is true for the ones growing as well as those helping them grow.

Have some faith. You are smart enough. The rest is just work, and we all have our work to do. It varies, amd there is no shame in that either.

Right here is where many of us would write, "past or younger me...", but I won't.

I won't, because I happen to have had good mentors, some of whom ended up long term friends, who I ended up helping in like kind later on as my own body of experiences accumulated.

I am sharing what was given to me.

Do think about your questions and the answers. This can be confusing, how many ways to ask, how many times, what if...?

I resolved this with some help, and the help is make damn sure others you seek help from, but in general just others, know you are working for it. And if you truly are, not just leaning on others, instead seeking to own it, your questions will be the right or good questions.

And when it is your time to share what you got out of this free ride here, you will have become one of those good, or better people. Amplify the good and pass the idea of making good people better along.

This is a powerful idea. And it does not carry any weight of judgement or blame. Good people work for it, whatever it is, and when they do that while also being good humans in that work, the good in everyone, the team, get amplified.

Yeah, I know. This all seems shallow. Maybe it is!

All I can tell you is I got a lot of consideration and opportunities in my life playing it this way. You are likely to experience the same. Others you share it all with will too. Did not really make enemies either. One never knows who may be working with, or for who.

I like to think it is infectious in the best of ways. Has been in my experience so far, and in this way we often have more ability to shape our world than we may believe.

I tell new engineers that the only wasted questions are the ones they don’t ask. I always try to make it clear from the outset that not knowing something is not a defect...

How do you deal with lazy questions? Ones you've answered over and over or easily found in the docs?

It doesn't matter if a coworker can unblock you in 10 seconds, spend the 30 minutes struggling and sweating. That's when you grow. The struggle makes you grow.

Yeah, I agree. I really don’t mind tons of questions, but sometimes, after hitting a few roadblocks, a new, junior developer will start turning off their brain and asking genuinely silly questions because they’re no longer thinking.

I’d rather tell people to take an hour break if they feel like they’re in that state. Get something to eat. Read a book. Come back ready to analyze.

Come back and feel out the problem so you can ask good questions.

This week, a new developer started asking me questions every 10 minutes that were clearly covered in our on onboarding doc (including commands to copy and paste with explanation.) If they followed the guide are by step, they wouldn’t have had half as many questions. It’s really just a case of being overwhelmed. Take a break and come back.

I don't agree with this based on the specific example that she provided. Searching for legacy files, or annoying historical lessons, especially in a codebase you're entirely unfamiliar with, is a perfect example of a time to ask a question like that.

In fact, I might even put it as an oversight of the engineer that's guiding the new engineer if they didn't tell their coworker where the files are, especially when there's been a shift between old and new styles. It's okay, though, experienced engineers make mistakes, as well.

I'd agree these are all valid, and not mutually exclusive. ie, as a junior dev use some discretion based on what type of issue you're facing, as a manager set the tone and if needed give the offer some guidance on when to struggle for a bit, when to ask, and when to take a break (still such an underrated strategy!). This is one of those problems that only gets solved when both parties understand the solution though. In other words a developer can have a good grasp of how question-asking should work, but despite a lot of lip service, this manager or the next might not get it. And vice versa managers/devs.

At $50 or more an hour, I’d rather they ask. If it’s a question where I think they could find the answer with a little more effort and I have the time, I’ll walk them through the discovery process myself.

Especially since the answer you arrive at after 30 minutes struggling may appear to be correct but have implications you don’t understand. This one bites people a lot, myself included.

I always tell my interns: “I have been in this job for 10+ years and I’m still yet to tell anyone they’re asking too many questions.”

Seems to put them at ease :)

An employer got annoyed with me once because I didn't know how to generate a new SSH key pair. Oh well. Now I know.

Not too many. Too many bad questions. Learning how to ask good friends questions is important to any junior anything.

Something I do is give people, regardless of experience, feedback when they ask good questions.

Ask questions. Do not become reliant on getting answers, learn to find them.

Spoken as a former junior engineer this is 100% accurate.

ask , and you are an idiot for five minutes.

do not ask, and stay an idiot for ever.

Reply on news.ycombinator.com