When Should I Interrupt Someone? | Hacker News Reader

When Should I Interrupt Someone?

zwischenzugs.com

181 pointszwischenzug91 comments

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.

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.

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)?

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.

I know a number of people, myself included, who task their loved ones with "helping" them code by as if asking a college. None of the loved ones in question have the least qualifications or interest in coding, yet they are all immensely helpful, and they get more time together, and feel valued.

Just explaining what the problem is out loud is very often all that is needed.

I do the same! I tell my wife she's a developer all the time due to the number of times shes helped me solve a problem outside her domain.

I've tried cutting out the middle man and just forcing myself to organize my thoughts but it's not nearly as effective without the social pressure.

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.

This can come down to a confidence problem. I have really helped solved this with junior members by going on vacation and leaving them the keys for a few days. When the ability to ask questions was taken away for a bit they tend to learn how much they can actually rely on themselves.

The same sort of behavior is on display with the one-essential-person who has gotten themselves at the center of everything in an opposite kind of way.

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.

TBH this is a double edge sword. It's easy to end up creating the illusion of value by helping many devs when they could have just tried N more things.

As a curious counterpoint, try taking the opposite approach for a bit and only get involved when it is absolutely apparent that no one else can do the job/guide people through decisions. Have junior folks write down what they are about to do in a design, or what they've tried before to help build documentation, design, and debug muscle. You may find that people are more able to run the show than you give them credit for.

I feel like many in this thread misunderstand me. Our company follows pretty standard practices. Before anything is worked on, everyone has to write in pretty excruciating detail what is being done, from juniors all the way to our marketing department. Everyone works on the documentation including the juniors.

98% of the questions I get are not about the basics, they are very high-level problem solving questions coming from people that just need clarification or 2nd pair of eyes on something. I mean even I need that quite often and I am very grateful for the help.

> Our company follows pretty standard practices. Before anything is worked on, everyone has to write in pretty excruciating detail what is being done, from juniors all the way to our marketing department.

That's not at all standard, at least not if you're talking about documentation that's actually available in a useful fashion.

Standardized, but not standard

> I want you to interrupt me as soon as you need help.

> 98% of the questions I get are not about the basic

How do you know your advice is being followed/ is valuable? I don't think that statistic is relevant. I don't think people are misinterpreting what you said. Its either 1. a tautology: because when they need help, they'll ask. 2. It can be misinterpreted: Ask for help whenever something challenging happens.

Life doesn't tend to churn out as a clearly distinguishable statistic. It's messy, and nuanced. So to counter your argument, I don't think that focusing on statistics is a meaningful pursuit in this regard. I think it would be more productive to acknowledge that humans are fallible, and require assistance when working alone. Humans are part of a system, and that system changes. Sometimes it is absolutely necessary to query those making the changes, because those changes have not yet been documented, or the available documentation is lacking.

In a senior role it's important to prioritize your time. If you are dedicating a lot of time to improve a junior's design while they ignore your guidance... you aren't their manager. This problem is compounded when you are a resource for 3+ dev teams, at any given time there will be projects which teams want to go their own way and it's not possible to right the ship without breaking eggs.

Contrary to popular belief, many junior developers are too shy about asking.

or too worried of looking like an imposter!

If you don’t hear the weird things your team is trying to do with the code, you don’t know where the holes are or about the giant performance regression they’re working on.

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

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.

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.

Amen to that.

Some people seeing this advice may be worried about people coming to them with too simple problems or without trying to work it out themselves first, or other similar issues. That happens, but not that much, from my experience. And when it does, it’s usually with new people. In such cases you will want to explain to them what they could be doing better with this process, and avoid discouraging them from seeking help altogether.

This.. is a fine answer if asked in the context of an interview.

When and how do _you_ decide when it's a good time to interrupt a dev on your team, though?

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.)

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.

> On a cross day, an impatient day, I will kill you with fire.

So... are you working on that? Calling yourself "foible" doesn't forgive you of your shortcomings.

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.

“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.

In my experience, this often reveals how little has been tried.

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.

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.

>Interrupt me after you've tried as many ways as you can to solve the issue

Depends on what you value more. If you are optimizing for personal productivity, sure this makes sense. But if you are optimizing for team wide productivity, it doesn't make sense for someone to spend 3 hours trying everything they can think of before asking if you could have given them the answer in 5 minutes.

Something like spending 30 minutes trying and then asking even though you could go on makes more sense team wide.

I honestly prefer teaching people to fish over providing them shortcuts. Giving them the answer doesn't often help in my experience. Helping them frame the question better does. There are some cases where the person is lacking fundamental knowledge about the domain or technology, of course.

Ultimately, team productivity isn't about enabling people in the codependent sense. It's better to build them up than to merely support them.

The OP is pretty much a refutation of your answer, you don't think it has a point?

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.

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.

I'm reading the OP as "use these considerations to determine when to stop trying and instead interrupt me", and the comment I replied to as "you should never interrupt me unless there is no other option". The former seems to want to optimize for overall productivity between all participants, the latter seems to want to minimize interruptions.

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

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?"

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.

I thought it would be about -

...sorry, should have let you finish. You were saying the same thing.

Username is relevant. I can see why that might have interested you.

That's what I hoped it would be about...

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).

Even the blog title seems to be about interruption.

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.

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.

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.

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.

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.

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.

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.

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.

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.

I don't believe that letting someone struggle for a day is a better learning experience than just telling them what they need to know. Sometimes it might be, but I feel it is more likely just unnecessary struggle - resulting in the same or a worse, bodged, end result.

And, I am 100% sure that providing education is better than letting them struggle. If you don't want to tell them the answer (and I haven't fully understood why not), then pointing them in the right direction to discover the answer is certainly going to be more helpful.

Yes, this is true -- and another thing that's true is that you might still miss something subtle in your reverse engineering efforts.

I have been in the position of having spent hours to figure it out myself. And I believe I’ve learned more in the process.

I hope and expect that you did learn more in hours than what you could have learned in two minutes.

If you had spent those same hours after two minutes of support, you might have learned even more.

No! Because I wouldn't have done all the failing things.

Example: I am a Unix user and I want to delete a directory. But I don't know how to do that. So I say "ls /bin" and think that maybe the "d" in "dd" has something to do with delete directory (and "df" is delete file?), and so I do "man dd". So I get some idea what "dd" can do. (Deleting directories is not one of them, though, it seems) I also find "unlink" which seems promising, but that one can't delete directories, only files.

If I had asked you, and you would have told me "rmdir", then I would never have learned about "dd" and "unlink".

It's just an example; I wasn't sure I could come up with something more realistic from actual development.

Learning is only a frustrating struggle if you do it the way most students are taught to do it at school, mostly through rote memorization and very boring repetition. But there are other effective ways of learning that are not frustrating and that allow people to explore and be creative.

What I try to teach developers is how to learn things without getting frustrated. Usually people get frustrated because they don't have to right process in place for learning things, they try bolting solutions onto existing code and try fitting a square peg into a round hole. They get massive compiler errors or stack traces that are hard to isolate from the specific problem they're having and it feels like in order to solve one problem they need to solve a dozen other tangentially related problems.

That's overwhelming and frustrating, but it need not be that way.

I teach people how when they come across a challenge, how to learn to come to a solution from first principles; how to create a minimal project isolated from the rest of what they're working on and experiment. I try to emphasize the importance of having various different mental models of how a computer works and how to apply those models to have a better understanding of what's happening beneath the hood.

> I haven't fully understood why not

Because working in my industry isn't a matter of knowing answers to questions. It's about the process of knowledge discovery and that process comes with experience and practice. I really don't need anyone to be a glorified typist... if you need to take an entire day to really understand how to solve a problem, even if it's a trivial problem I could solve in a minute, then take the day. That's an investment I'm willing to make now while you're a junior and I am in a position to fully understand the problem you're facing, compared to 10 years from now when I won't be able to fully understand the problem and then we're really screwed.

I've been at this for 8 years now and I think you're dreaming if you believe you'll ever get to the point where you're never just beating your head against the wall with something frustrating and non-obvious, no matter how great your learning or deduction skills are. Either that or you're much better at it than I am.

FWIW I've been doing this for 20 years now and I completely agree with you. Knowing when to get a fresh perspective on a problem is a part of learning healthy problem solving skills, and it's not often that banging your head against a problem for a full day with no progress is better for your skills development than asking for help after, say, an hour or two.

And it's not like you're going to someone more senior and saying "I'm stuck; do my work for me". Ideally you're just getting a strong hint as to the right approach to take, and can make progress with that.

> But there are other effective ways of learning that are not frustrating and that allow people to explore and be creative.

Like... asking for help and having a chat with a mentor who has relevant experience.

(Most) people don't do that easily and are likely to have already spent time and effort formulating the question.

Asking them to go away and spend more time on their own is interrupting an effective way of learning.

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.

A day is too long. If someone is stuck for more than 2 hours and I can get them unstuck, I'm happy to do it.

I chose what I thought were extreme values to make my point, but I guess not everyone sees it my way.

Yes, if it’s one time. But if it’s constantly asking questions over and over again then of course this won’t work.

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.

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

"The average lost time is 23 minutes per major interruption ((...)) For developers, it is far worse" https://www.brightdevelopers.com/the-cost-of-interruption-fo...

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".

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.

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.

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

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.

'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).

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.

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.

Reply on news.ycombinator.com