11 ms·

When Should I Interrupt Someone?

181 points by zwischenzug 6y ago

TedDoesntTalk 6y ago
I read the headline and thought this was going to be about interrupting someone during conversation.
- sideshowb 6y ago
  I thought it would be about - ...sorry, should have let you finish. You were saying the same thing.
- bena 6y ago
  Which would also be a helpful guide. Some people have a tendency to not so much converse as to pontificate. If you are seeking input from someone, you have to give them the chance to give that input. If you have an issue with a point someone made within their first two sentences, the rest of the speech doesn't matter, so it's almost rude to wait until they finish to tell them their original assumption was wrong. Or they go off on such a tangent that you both forget the original purpose of the conversation. Hypothetically, if someone is complaining that their back is sore from all the glass bottles they carry around to hammer nails with, waiting for them to get into the fine minutiae about the embroidery on their glass bottle bag is just wasted time. You need to ask the immediate question, "Why are you using glass bottles to hammer nails?"
  - hinkley 6y ago
    The one that gets me is people building castles in the sky. Anchoring is a thing, you don’t get to give a long sales pitch predicated on bad information. You’ll just confuse everyone. Stop.
- hiddencache 6y ago
  That's what I hoped it would be about...
  - rgoulter 6y ago
    My favourite model of 'when to interrupt' is two approaches to interruption: Those who expect an interruption once understanding has been reached, and those who expect complete statements before interruption. The failure modes from when these two different approaches mix is either "awkward" or "rude". Generally, if someone is rambling, interrupt them. (With exceptions like if someone is emotionally venting, let them release it).
- deleted 6y ago
  [deleted]
- triceratops 6y ago
  Username is relevant. I can see why that might have interested you.
- ramshorns 6y ago
  Even the blog title seems to be about interruption.
mrgalaxy 6y ago
As the senior most developer on my team, I want you to interrupt me as soon as you need help. It is a far better use of everyone's time to get you on the correct track right away. I tell this to every developer on the team, and especially the junior developers. In a sense, since I helped designed and write many of the systems, I view it as my main job to assist other developers so they can do their job to the fullest extent.
- bluefirebrand 6y ago
  This approach works best if you do in fact course correct people and not just do the job for them. I've definitely seen junior devs get used to hand holding from senior devs, and learn nothing
  - mrgalaxy 6y ago
    Actually this is a great clarification yes. You want them to begin thinking about problems and understanding tools so they can eventually do tasks without asking for help.
  - SilverRed 6y ago
    One of the things I was advised was to come to the senior devs with a solution already in mind. Then I have though about it already, and they can shoot it down/propose a new plan or agree. The end result is I had learned how to solve it on my own and a senior dev had checked it to make sure it was the right path.
- majkinetor 6y ago
  Meh... IME, that way you are rising retards. One totally needs to try and experiment on its own before seeking advice. I wouldn't ever like a job like that. Its like baby sitting. Since you assisted and wrote many systems, its better to write good docs for it so juniors can self service.
  - brmgb 6y ago
    Having confidence in your ability to do things and trying them is good. Doing pointless work because you were too proud to ask isn't. Juniors more often than not tend to err on the second side. There is a lot of value in being humble and asking. You will probably grow faster if you ask too much than too little. People who keep asking the same things are the real annoyance. Also seniors who resent helping juniors shouldn't be seniors. They shouldn't be there at all actually.
Gunax 6y ago
'when should I ask for help' might be a better title. Each org I have seen is a bit different. Some projects just seem to be more geared towards gurus (aka, the software is wonky, no way anyone could know about that without asking).
orobinson 6y ago
“When you seek advice, first write down everything you’ve tried.” Remote working has made this super easy as often the way of reaching out to people is with a Slack message or equivalent. So many times over the past year I’ve answered my own question as I type out a lengthy Slack message explaining a problem to someone.
- muttled 6y ago
  In my experience, this often reveals how little has been tried.
tresil 6y ago
This is interesting. We’ve arrived at a very similar set of guidelines on our team. One slight difference is that sometimes people want to reach out to a senior person not so much because they’re “stuck” in the middle of something, but before they even start on some new feature or development story. They want help with design or help with even determining what approach to take. Similar to the author’s suggestion to ask them what they’ve already tried, we ask for them to do their best to propose a solution, and then we go from there. That way they’re still in the drivers seat, and we evaluate the pros and cons of their approach so they get meaningful feedback for improvement.
afarrell 6y ago
I created 3 slack emojis to signal this more clearly: 1. I’m thinking harder about this thing but not blocked. 2. I’m still not blocked, but could really use a pair right now. 3. Actually stuck. They basically act like andon cords for my quality of understanding of a task.
plank_time 6y ago
When I interrupt people, I make sure I have exhausted all avenues of finding the answer, and I tell them exactly what steps I tried. If they see that I’ve put in significant effort, then it usually assuages any issues with them being interrupted. In a similar way when people interrupt me, I like to see the same.
- emodendroket 6y ago
  If I can answer a question in two minutes and it's going to take you a full day to figure it out it would be silly for me to refuse to help you.
  - Kranar 6y ago
    For how my business works, I'd rather have the person invest a day working on a solution instead of answer it for them in two minutes. My goal is to have the developer attain a position where they can eventually answer a question for themselves in two minutes and that means letting them make mistakes, try things that are wrong, and spend time learning. If anytime someone needs to invest a day to learn how to research a solution, try something out, gain experience, I simply give them the exact and specific answer in two minutes, then I deprive them of experience. I substitute my experience for their opportunity to grow. I can appreciate that it's nice to want to help people out by giving them the answer, and my advice does not mean that you leave people to hang or feed them to the wolves and suffer... it's that as an organization, in the long run time is better spent giving people a system they can use to learn and grow and that system will necessarily require developers to invest a lot of time learning seemingly trivial things and learning from mistakes for themselves.
    - kelnos 6y ago
      I think it depends. There's certainly a ton of value in getting someone to puzzle through a problem by themselves. But at some point you end up with diminishing returns. Often the person struggling will learn 90% of what they're going to learn in an hour, and the next 7 hours will only increase their knowledge and problem solving skills by that last 10%. After the first 90% it's often a better use of everyone's time to just go and ask for help.
king_panic 6y ago
I resent doing other people's work for them, I don't resent helping them when they can no longer help themselves. Interrupt me after you've tried as many ways as you can to solve the issue, and present them to me so either I can determine the remaining set you haven't tried or we can brainstorm. It shows initiative and thoughtfulness and creates a starting point for our solutioning.
- schoolornot 6y ago
  How do you reply when they haven't invested much time in solving the problem? You ask, "what have you tried?". They say XYZ. What are you going to tell them to go back, try some other things, and then come back? Sometimes I too need to brute force my way through problems. It sucks, it's how I got where I am. No one has to suffer like I did early in the career but an ounce of effort from some folks every now and then would be nice.
- ben0x539 6y ago
  The OP is pretty much a refutation of your answer, you don't think it has a point?
  - pcthrowaway 6y ago
    Isn't this basically what the OP is saying? Interruptors should try things first, and write down the things they've tried and what happened. After that, they can interrupt without wasting too much time from the interruptee.
    - waheoo 6y ago
      This assumes the time interrupted is more expensive than the time spent by the interruptor trying other things, often needlessly. There is a balance here. Hard and fast rules don't cut it in my experience. I prefer new hires have a culture of problem solving, but not at the expense of being afraid to ask for help. That is more important than my uninterrupted time. This usually means some people need to be incouraged to reach out sooner, and others need to be encouraged to try a few things on their own first. The worst thing I could to is create a culture of fear around asking for help, and I'll err towards having more interruptions to make sure that isnt the case.
emodendroket 6y ago
It is far more likely you're waiting too long than not long enough if you're thinking about this at all, imo.
ccleve 6y ago
I have a different answer to this problem. If you get stuck, send me an email and work on something else for a while. That way I don't get interrupted and you get your answer. Asynchronous communication is great.
- natmaka 6y ago
  This! The very cost of an interruption for the person who is interrupted is often under-evaluated. It is very high form some types of activities and brains, and even higher if the interruption is raised (!) after a long work session, as the interrupted has to 'swap out his context' (what he was thinking), tackle the question, then 'swap in his previous context' before resuming. https://www.perpetual-beta.org/weblog/leave-me-alone.html https://www.perpetual-beta.org/weblog/leave-me-alone.html "The average lost time is 23 minutes per major interruption ((...)) For developers, it is far worse" https://www.brightdevelopers.com/the-cost-of-interruption-for-software-developers/ https://www.brightdevelopers.com/the-cost-of-interruption-fo...
- another-dave 6y ago
  I've started to just apply this to IM too — as in, if I'm busy with deep work I'll snooze notifications on Slack & may put a status message "available at 2pm".
Communitivity 6y ago
I advocate a twenty minute rule. It's not hard and fast, but shouldn't be more than an hour, and shouldn't be less than 20 minutes. This is the amount of time the person needing help should try to solve it themselves. After that they should write down what they've done (they should be doing this anyway in an engineering notebook or worklog file), and then ask for help. The delay is to make sure an attempt is made to solve it themselves. It's long enough to get them to try to understand the problem, and short enough to not put them far behind. I've also found that if they need to get help often then it's not their problem, but the problem of who is tasking them. Their tasking, or the context of that tasking, is probably not being communicated well, or might not be defined well-enough.
- dmlittle 6y ago
  I personally like advocating after 20 minutes of being stuck and unable to progress any further. If you're stuck but keep making incremental progress, reset the timer. It might seem silly but if you're able to make slow incremental progress you'll eventually figure it out and it helps grow your intuition of what to do to fix/unstuck yourself. I don't know of any other way to develop that intuition other than going through it yourself (if you have any tips I'd love to hear your thoughts!). Yes, it might be slow at first but the compounding effect on your growth cannot be overstated. It's also not a hard rule, if you're on some sort of time crunch and need help you should obviously feel free to ask for it.
  - Communitivity 6y ago
    Thank you, I should have added that as I do the same thing. It's 20m (or whatever the interval is between 20m and an hour) or being stuck, not of making progress.
  - muttled 6y ago
    I can personally attest to this. I've been in a couple positions where there was simply nobody to ask. If you were stuck, you were stuck. It was awful for obvious reasons but my ability to self-resolve skyrocketed.
francoisdevlin 6y ago
I was in architecture for years, and I would help anyone who came to me on one condition. They would need to go back to their desk, and write up a 3 paragraph description of their problem, what they tried, and where they were stuck. It has a lot of benefits. 1. It weeded out the people who wouldn't invest anything. 2. It let a good 25% of the engineers "rubber duck" their way out of a problem. 3. When the problem got past the first two filters, the problem was much better defined when we worked on it together.
- notretarded 6y ago
  Good idea
ravedave5 6y ago
I had one developer who was VERY smart but would ask for help at the smallest problem. Usually I'd be able to help him fix it in 5 minutes, or he'd rubber duck it himself explaining to me. So what I did is he'd IM me if asking if I could stop by, I'd say sure let me finish this code I'll be over in 15. Five minute later I'd get an IM saying n/m I fixed it. I'd ask him about it later in the day so he didn't feel ignored. I think it worked out pretty well for both of us.
- Swizec 6y ago
  My rule of thumb is: If it’s a library or framework question, research on your own until quite stuck If it’s a codebase question, ask immediately (in a relevant company public channel) and continue digging. If you get the answer first, answer your own question, improve docs.
  - aesyondu 6y ago
    Interesting, I never thought of it that way. Do you think this applies specifically for junior developers, or do you think junior developers are exempt from this (allowed to ask about anything)?
- m463 6y ago
  Sounds like the company that would always delay starting work on an order until a certain amount of time went by, like a day or two. (I was something like custom furniture). turns out there was a HUGE amount of churn for a day after an order was created with changes, and this saved a huge amount of headaches.
- fartcannon 6y ago
  As someone who suffers from this problem, for me it's almost like the part of my mind that's supposed to organize thoughts is procrastinating. The stress of maybe/maybe not being able to solve a problem is removed when I finally ask for help. I cam then relax and it often solves itself. That, or the act of forcing myself to organize my thoughts so I can explain it makes the solution clear.
PeterWhittaker 6y ago
I have two rules for interruptions: 1. Please do, but 2. If I signal that I need time, respect that. #2 is the flip-side of interrupting: Don't persist if there are any signs you should not. I am more than willing to help people with their problems, and I love answering questions, teaching, providing advice, discussing thorny problems... ...but I won't countenance an "interrupt": Come to my office, knock on my door, say my name, whatever, but if my hand shoots up with the "Just a moment" index in the air, respect that. If I do that, it's because what I have in my head will take me far too long to regain once lost - and the interruption will blow it up. I need to checkpoint. Maybe even solve. I need anywhere from a few seconds to an hour (and, yeah, I may forget you were there, foibly human and all that). Pretty much everyone I've ever worked with has learned that I have all the time in the world for them, except when I don't, I will let them know when I don't, without being rude (well, perhaps debatable, it is the barest acknowledgement), and when I can I will give them all I can. Unless you persisted. On a good day, when I am feeling open and relaxed, hopefully we can talk about how to manage things differently, figure out a way that works for us. On a cross day, an impatient day, I will kill you with fire. Metaphorically. Being a foibly human. Who sometimes overvalues his time. We are both likely to regret this. Hopefully we will find occasion to laugh about it later. (Over the decades, the "just a moment" finger comes up less often, at least in part because I've learned those thoughts I was holding were neither so valuable nor so fragile as I once thought. Often, it barely starts to rise and I've already shifted gears, caching things away for later. I had to teach myself that because I really do prefer taking the interrupt and helping to breathing flame.)
- lambda_obrien 6y ago
  That's pretty much me, I told my wife if I put up the finger to wait and try again in 15 minutes, unless it's my son's daiper or whatever, then I'll happily take the loss of context. I also found that functional programming, types or type annotations, and writing very small functions glued together by longer functions helps to reduce cognitive load when solving problems. Then I can add comments to literally bracket the area I am searching for the problem or solution and slowly move them closer together as I rule out functions and stuff.
- viklove 6y ago
deleted 6y ago
[deleted]
borplk 6y ago
If you instantly "escalate" your problem to your teammate without having made an effort it gives the impression that you don't respect their time or concentration. So make an effort first so that when you go to your colleague you can tell them a few things that you have already tried. You may find an answer before you need to go to them. And if you don't find the answer the list of things that you have already tried can help set the context and help your colleague to help you better. This is particularly important if the problem is easily google-able. If you keep going to your colleagues for help and they search a few keywords on google, go to the first result and show you the answer right there that's the sign that you are not making and effort to solve it yourself first.
TechWizOfFortun 6y ago
Having some sort of "office hours" seems to solve this problem. I'd allocate certain office hours that I was willing to assist other employees. This policy was implemented when I was unable to concentrate on my work as a result of being interrupted too frequently.
alex_young 6y ago
Turning this question on its head: What should I do when someone asks for help? Coach, don't fix. If you help someone find the answer to a problem, and give them the support they need to learn, you'll find that you both resolved the underlying issue, and that you gave them tools they need to become better at what they do. You'll also set an example for them when someone comes to them for help.
- hinkley 6y ago
  Sum up at the end, what they were looking for, and why they couldn’t find it, so that you get a different question next time.
danielyaa5 6y ago
As someone who has been on both sides of the problem I think something thats really important is making sure you write down notes after you received help and at the very least make sure you searched the code and documentation for relevant information. Its frustrating when you take time to write documentation or code comments and they are blatantly ignored.

181 points by zwischenzug 6y ago

TedDoesntTalk 6y ago

I read the headline and thought this was going to be about interrupting someone during conversation.

sideshowb 6y ago
I thought it would be about - ...sorry, should have let you finish. You were saying the same thing.
bena 6y ago
Which would also be a helpful guide. Some people have a tendency to not so much converse as to pontificate. If you are seeking input from someone, you have to give them the chance to give that input. If you have an issue with a point someone made within their first two sentences, the rest of the speech doesn't matter, so it's almost rude to wait until they finish to tell them their original assumption was wrong. Or they go off on such a tangent that you both forget the original purpose of the conversation. Hypothetically, if someone is complaining that their back is sore from all the glass bottles they carry around to hammer nails with, waiting for them to get into the fine minutiae about the embroidery on their glass bottle bag is just wasted time. You need to ask the immediate question, "Why are you using glass bottles to hammer nails?"
- hinkley 6y ago
  The one that gets me is people building castles in the sky. Anchoring is a thing, you don’t get to give a long sales pitch predicated on bad information. You’ll just confuse everyone. Stop.
hiddencache 6y ago
That's what I hoped it would be about...
- rgoulter 6y ago
  My favourite model of 'when to interrupt' is two approaches to interruption: Those who expect an interruption once understanding has been reached, and those who expect complete statements before interruption. The failure modes from when these two different approaches mix is either "awkward" or "rude". Generally, if someone is rambling, interrupt them. (With exceptions like if someone is emotionally venting, let them release it).
deleted 6y ago
[deleted]
triceratops 6y ago
Username is relevant. I can see why that might have interested you.
ramshorns 6y ago
Even the blog title seems to be about interruption.

mrgalaxy 6y ago

As the senior most developer on my team, I want you to interrupt me as soon as you need help. It is a far better use of everyone's time to get you on the correct track right away. I tell this to every developer on the team, and especially the junior developers. In a sense, since I helped designed and write many of the systems, I view it as my main job to assist other developers so they can do their job to the fullest extent.

bluefirebrand 6y ago
This approach works best if you do in fact course correct people and not just do the job for them. I've definitely seen junior devs get used to hand holding from senior devs, and learn nothing
- mrgalaxy 6y ago
  Actually this is a great clarification yes. You want them to begin thinking about problems and understanding tools so they can eventually do tasks without asking for help.
- SilverRed 6y ago
  One of the things I was advised was to come to the senior devs with a solution already in mind. Then I have though about it already, and they can shoot it down/propose a new plan or agree. The end result is I had learned how to solve it on my own and a senior dev had checked it to make sure it was the right path.
majkinetor 6y ago
Meh... IME, that way you are rising retards. One totally needs to try and experiment on its own before seeking advice. I wouldn't ever like a job like that. Its like baby sitting. Since you assisted and wrote many systems, its better to write good docs for it so juniors can self service.
- brmgb 6y ago
  Having confidence in your ability to do things and trying them is good. Doing pointless work because you were too proud to ask isn't. Juniors more often than not tend to err on the second side. There is a lot of value in being humble and asking. You will probably grow faster if you ask too much than too little. People who keep asking the same things are the real annoyance. Also seniors who resent helping juniors shouldn't be seniors. They shouldn't be there at all actually.

Gunax 6y ago

'when should I ask for help' might be a better title. Each org I have seen is a bit different. Some projects just seem to be more geared towards gurus (aka, the software is wonky, no way anyone could know about that without asking).

orobinson 6y ago

“When you seek advice, first write down everything you’ve tried.” Remote working has made this super easy as often the way of reaching out to people is with a Slack message or equivalent. So many times over the past year I’ve answered my own question as I type out a lengthy Slack message explaining a problem to someone.

muttled 6y ago
In my experience, this often reveals how little has been tried.

tresil 6y ago

This is interesting. We’ve arrived at a very similar set of guidelines on our team. One slight difference is that sometimes people want to reach out to a senior person not so much because they’re “stuck” in the middle of something, but before they even start on some new feature or development story. They want help with design or help with even determining what approach to take. Similar to the author’s suggestion to ask them what they’ve already tried, we ask for them to do their best to propose a solution, and then we go from there. That way they’re still in the drivers seat, and we evaluate the pros and cons of their approach so they get meaningful feedback for improvement.

afarrell 6y ago

I created 3 slack emojis to signal this more clearly: 1. I’m thinking harder about this thing but not blocked. 2. I’m still not blocked, but could really use a pair right now. 3. Actually stuck. They basically act like andon cords for my quality of understanding of a task.

plank_time 6y ago

When I interrupt people, I make sure I have exhausted all avenues of finding the answer, and I tell them exactly what steps I tried. If they see that I’ve put in significant effort, then it usually assuages any issues with them being interrupted. In a similar way when people interrupt me, I like to see the same.

emodendroket 6y ago
If I can answer a question in two minutes and it's going to take you a full day to figure it out it would be silly for me to refuse to help you.
- Kranar 6y ago
  For how my business works, I'd rather have the person invest a day working on a solution instead of answer it for them in two minutes. My goal is to have the developer attain a position where they can eventually answer a question for themselves in two minutes and that means letting them make mistakes, try things that are wrong, and spend time learning. If anytime someone needs to invest a day to learn how to research a solution, try something out, gain experience, I simply give them the exact and specific answer in two minutes, then I deprive them of experience. I substitute my experience for their opportunity to grow. I can appreciate that it's nice to want to help people out by giving them the answer, and my advice does not mean that you leave people to hang or feed them to the wolves and suffer... it's that as an organization, in the long run time is better spent giving people a system they can use to learn and grow and that system will necessarily require developers to invest a lot of time learning seemingly trivial things and learning from mistakes for themselves.
  - kelnos 6y ago
    I think it depends. There's certainly a ton of value in getting someone to puzzle through a problem by themselves. But at some point you end up with diminishing returns. Often the person struggling will learn 90% of what they're going to learn in an hour, and the next 7 hours will only increase their knowledge and problem solving skills by that last 10%. After the first 90% it's often a better use of everyone's time to just go and ask for help.

king_panic 6y ago

I resent doing other people's work for them, I don't resent helping them when they can no longer help themselves. Interrupt me after you've tried as many ways as you can to solve the issue, and present them to me so either I can determine the remaining set you haven't tried or we can brainstorm. It shows initiative and thoughtfulness and creates a starting point for our solutioning.

schoolornot 6y ago
How do you reply when they haven't invested much time in solving the problem? You ask, "what have you tried?". They say XYZ. What are you going to tell them to go back, try some other things, and then come back? Sometimes I too need to brute force my way through problems. It sucks, it's how I got where I am. No one has to suffer like I did early in the career but an ounce of effort from some folks every now and then would be nice.
ben0x539 6y ago
The OP is pretty much a refutation of your answer, you don't think it has a point?
- pcthrowaway 6y ago
  Isn't this basically what the OP is saying? Interruptors should try things first, and write down the things they've tried and what happened. After that, they can interrupt without wasting too much time from the interruptee.
  - waheoo 6y ago
    This assumes the time interrupted is more expensive than the time spent by the interruptor trying other things, often needlessly. There is a balance here. Hard and fast rules don't cut it in my experience. I prefer new hires have a culture of problem solving, but not at the expense of being afraid to ask for help. That is more important than my uninterrupted time. This usually means some people need to be incouraged to reach out sooner, and others need to be encouraged to try a few things on their own first. The worst thing I could to is create a culture of fear around asking for help, and I'll err towards having more interruptions to make sure that isnt the case.

emodendroket 6y ago

It is far more likely you're waiting too long than not long enough if you're thinking about this at all, imo.

ccleve 6y ago

I have a different answer to this problem. If you get stuck, send me an email and work on something else for a while. That way I don't get interrupted and you get your answer. Asynchronous communication is great.

natmaka 6y ago
This! The very cost of an interruption for the person who is interrupted is often under-evaluated. It is very high form some types of activities and brains, and even higher if the interruption is raised (!) after a long work session, as the interrupted has to 'swap out his context' (what he was thinking), tackle the question, then 'swap in his previous context' before resuming. https://www.perpetual-beta.org/weblog/leave-me-alone.html https://www.perpetual-beta.org/weblog/leave-me-alone.html "The average lost time is 23 minutes per major interruption ((...)) For developers, it is far worse" https://www.brightdevelopers.com/the-cost-of-interruption-for-software-developers/ https://www.brightdevelopers.com/the-cost-of-interruption-fo...
another-dave 6y ago
I've started to just apply this to IM too — as in, if I'm busy with deep work I'll snooze notifications on Slack & may put a status message "available at 2pm".

Communitivity 6y ago

I advocate a twenty minute rule. It's not hard and fast, but shouldn't be more than an hour, and shouldn't be less than 20 minutes. This is the amount of time the person needing help should try to solve it themselves. After that they should write down what they've done (they should be doing this anyway in an engineering notebook or worklog file), and then ask for help. The delay is to make sure an attempt is made to solve it themselves. It's long enough to get them to try to understand the problem, and short enough to not put them far behind. I've also found that if they need to get help often then it's not their problem, but the problem of who is tasking them. Their tasking, or the context of that tasking, is probably not being communicated well, or might not be defined well-enough.

dmlittle 6y ago
I personally like advocating after 20 minutes of being stuck and unable to progress any further. If you're stuck but keep making incremental progress, reset the timer. It might seem silly but if you're able to make slow incremental progress you'll eventually figure it out and it helps grow your intuition of what to do to fix/unstuck yourself. I don't know of any other way to develop that intuition other than going through it yourself (if you have any tips I'd love to hear your thoughts!). Yes, it might be slow at first but the compounding effect on your growth cannot be overstated. It's also not a hard rule, if you're on some sort of time crunch and need help you should obviously feel free to ask for it.
- Communitivity 6y ago
  Thank you, I should have added that as I do the same thing. It's 20m (or whatever the interval is between 20m and an hour) or being stuck, not of making progress.
- muttled 6y ago
  I can personally attest to this. I've been in a couple positions where there was simply nobody to ask. If you were stuck, you were stuck. It was awful for obvious reasons but my ability to self-resolve skyrocketed.

francoisdevlin 6y ago

I was in architecture for years, and I would help anyone who came to me on one condition. They would need to go back to their desk, and write up a 3 paragraph description of their problem, what they tried, and where they were stuck. It has a lot of benefits. 1. It weeded out the people who wouldn't invest anything. 2. It let a good 25% of the engineers "rubber duck" their way out of a problem. 3. When the problem got past the first two filters, the problem was much better defined when we worked on it together.

notretarded 6y ago
Good idea

ravedave5 6y ago

I had one developer who was VERY smart but would ask for help at the smallest problem. Usually I'd be able to help him fix it in 5 minutes, or he'd rubber duck it himself explaining to me. So what I did is he'd IM me if asking if I could stop by, I'd say sure let me finish this code I'll be over in 15. Five minute later I'd get an IM saying n/m I fixed it. I'd ask him about it later in the day so he didn't feel ignored. I think it worked out pretty well for both of us.

Swizec 6y ago
My rule of thumb is: If it’s a library or framework question, research on your own until quite stuck If it’s a codebase question, ask immediately (in a relevant company public channel) and continue digging. If you get the answer first, answer your own question, improve docs.
- aesyondu 6y ago
  Interesting, I never thought of it that way. Do you think this applies specifically for junior developers, or do you think junior developers are exempt from this (allowed to ask about anything)?
m463 6y ago
Sounds like the company that would always delay starting work on an order until a certain amount of time went by, like a day or two. (I was something like custom furniture). turns out there was a HUGE amount of churn for a day after an order was created with changes, and this saved a huge amount of headaches.
fartcannon 6y ago
As someone who suffers from this problem, for me it's almost like the part of my mind that's supposed to organize thoughts is procrastinating. The stress of maybe/maybe not being able to solve a problem is removed when I finally ask for help. I cam then relax and it often solves itself. That, or the act of forcing myself to organize my thoughts so I can explain it makes the solution clear.

PeterWhittaker 6y ago

I have two rules for interruptions: 1. Please do, but 2. If I signal that I need time, respect that. #2 is the flip-side of interrupting: Don't persist if there are any signs you should not. I am more than willing to help people with their problems, and I love answering questions, teaching, providing advice, discussing thorny problems... ...but I won't countenance an "interrupt": Come to my office, knock on my door, say my name, whatever, but if my hand shoots up with the "Just a moment" index in the air, respect that. If I do that, it's because what I have in my head will take me far too long to regain once lost - and the interruption will blow it up. I need to checkpoint. Maybe even solve. I need anywhere from a few seconds to an hour (and, yeah, I may forget you were there, foibly human and all that). Pretty much everyone I've ever worked with has learned that I have all the time in the world for them, except when I don't, I will let them know when I don't, without being rude (well, perhaps debatable, it is the barest acknowledgement), and when I can I will give them all I can. Unless you persisted. On a good day, when I am feeling open and relaxed, hopefully we can talk about how to manage things differently, figure out a way that works for us. On a cross day, an impatient day, I will kill you with fire. Metaphorically. Being a foibly human. Who sometimes overvalues his time. We are both likely to regret this. Hopefully we will find occasion to laugh about it later. (Over the decades, the "just a moment" finger comes up less often, at least in part because I've learned those thoughts I was holding were neither so valuable nor so fragile as I once thought. Often, it barely starts to rise and I've already shifted gears, caching things away for later. I had to teach myself that because I really do prefer taking the interrupt and helping to breathing flame.)

lambda_obrien 6y ago
That's pretty much me, I told my wife if I put up the finger to wait and try again in 15 minutes, unless it's my son's daiper or whatever, then I'll happily take the loss of context. I also found that functional programming, types or type annotations, and writing very small functions glued together by longer functions helps to reduce cognitive load when solving problems. Then I can add comments to literally bracket the area I am searching for the problem or solution and slowly move them closer together as I rule out functions and stuff.
viklove 6y ago

deleted 6y ago

[deleted]

borplk 6y ago

If you instantly "escalate" your problem to your teammate without having made an effort it gives the impression that you don't respect their time or concentration. So make an effort first so that when you go to your colleague you can tell them a few things that you have already tried. You may find an answer before you need to go to them. And if you don't find the answer the list of things that you have already tried can help set the context and help your colleague to help you better. This is particularly important if the problem is easily google-able. If you keep going to your colleagues for help and they search a few keywords on google, go to the first result and show you the answer right there that's the sign that you are not making and effort to solve it yourself first.

TechWizOfFortun 6y ago

Having some sort of "office hours" seems to solve this problem. I'd allocate certain office hours that I was willing to assist other employees. This policy was implemented when I was unable to concentrate on my work as a result of being interrupted too frequently.

alex_young 6y ago

Turning this question on its head: What should I do when someone asks for help? Coach, don't fix. If you help someone find the answer to a problem, and give them the support they need to learn, you'll find that you both resolved the underlying issue, and that you gave them tools they need to become better at what they do. You'll also set an example for them when someone comes to them for help.

hinkley 6y ago
Sum up at the end, what they were looking for, and why they couldn’t find it, so that you get a different question next time.

danielyaa5 6y ago

As someone who has been on both sides of the problem I think something thats really important is making sure you write down notes after you received help and at the very least make sure you searched the code and documentation for relevant information. Its frustrating when you take time to write documentation or code comments and they are blatantly ignored.