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.
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.
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.
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.
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.
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...
> 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.
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.
^ 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.
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 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?
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".
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.
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.
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.
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.
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’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.
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.
74 comments
[ 576 ms ] story [ 2207 ms ] threadAt 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 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.
https://en.wikipedia.org/wiki/Mastery_and_pleasure_technique
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.
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.
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.
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.
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.
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.
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.
^exactly
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.
Explaining how the result differs from expectation when asking the question makes answering the question so much easier.
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.
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.
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.
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".
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.
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.
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.
Seems to put them at ease :)
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.
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.
I interpret this as ask anything you want, you won’t be judged for asking. I will be judged in how I answer.
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.
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 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.
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.