So I think it is necessary to differentiate between "deep work" jobs (See Cal Newport's blog/books...) and "interrupt driven" jobs. Engineering design generally is a "deep work" job. Long periods of uninterrupted concentration are key to productivity.

Other jobs, like receptionist and office managers, for instance, are interrupt-driven. Receptionists add value by responding quickly and handling a continuous stream requests.

Now let's talk about engineering managers. Being an engineering manager is IMHO, an interrupt-driven job. The job of an engineering manager is to tell you where to find answers to your questions, or on a good day, actually answer the question. The friction comes when an engineering manager does not understand that the interrupt-driven nature of his/her job is not reciprocal. A good manager will handle interrupts quickly, but only very judiciously use the power to interrupt.

Another source of confusion is dev/ops. Anything operational will tend to be interrupt driven. An engineering manager that has been running a high-functioning dev/ops team that is a team of crack fire-fighters might be a very disruptive force in a design engineering team if that manager expects a constant volley of chat messages among the team.

It's perhaps more accurate to say there are 'deep work' tasks, and there are 'interrupt driven' tasks, and any job is a combination of both, in various ratios. Often you can't even tell ahead of time whether a given job is going to be mostly one or the other.

Maybe what we need is a system where instant messages are allowed, but it imposes a cost of some kind to the person initiating it, so that it won't be used frivolously. Like the proof-of-work antispam captchas, except it should take ~30 seconds and be just once per conversation (defined as ending when 5 minutes go by without message; first replies are free).

We could also add a social cost by displaying how often each user has used this feature in the past 24 hours, next to their username.

This is a great point. It's really important to recognize the nature of different tasks and to build different habits around them.

As a startup founder, by far my two biggest tasks are customer acquisition and development. The former is interrupt-driven while the latter is emphatically deep work.

Right now, I try to address this by blocking off 4 hours a day for deep work and the rest of the time is available for sales and general operations. It's working okay but the big problem is that I have an added stress of worrying what important customer messages I might be missing during my deep work time.

How about just a phone call (or two, to break through “do not disturb”), or tapping on their shoulder to get their attention? That's what we do when we really need someone right now rather than when they come back up for air in the next hour or two.

That, plus simply being mindful of the meaning of “deep work” and people working in roles that need that kind of concentration.

I don't need an app for this.

If you set Slack to do-not-disturb, people sending a direct message to you will be warned that you won't be notified and might not see it -- but will be given an option to "punch through" the do-not-disturb setting for important, interruption-worthy messages. That seems to largely achieve what you describe.

> It's perhaps more accurate to say there are 'deep work' tasks, and there are 'interrupt driven' tasks, and any job is a combination of both, in various ratios. Often you can't even tell ahead of time whether a given job is going to be mostly one or the other.

A reasonable model.

> Maybe what we need is...

I think Cal Newport belongs to the "intermittent hermit" school of thought...

I think you've hit on something. I like my days to be deep work driven as that's where I feel productivity and satisfaction. But, as my role has expanded I actually need to be interrupt driven. When you're stuck in a cross over period, trying to do deep work while holding the team back due to delays in responses, it gets frustrating.

Thank you for helping me understand this dynamic.

This doesn't seem to be the answer for a scrum team. Often you have questions for other engineers, on your team. A product owner is also not interrupt driven and is hopefully digesting stories or talking to stakeholders.

If engineering/qa/architecture is the question, xp may help.

Everyone, please stop starting your statements with "so."

If your bosses aren't planning to lay everyone off in a month, there has got to be something slightly-lower priority to be working on. Unless you're on the critical path, spending half a day blocked on your primary task and focusing on a secondary priority is no big deal (or, at least, shouldn't be). If you are on the critical path, scoop up that phone and start dialing.

Since you're new there, you might not have the assignments and/or enough responsibility to know what else needs to be done. But that should happen soon, and there is no reason not to proactively talk to your boss about secondary goals to focus on when you're blocked waiting on communication.

I think it's just good management to convey the bigger picture to everyone. Between the steady stream of tickets assigned to me and other existing responsibility I haven't had to ask my boss "what do I work on now?" in... like... 3 or 4 years.

Sorry, meant to imply I was blocked on that specific task, which is often the highest priority one, rather than on all tasks. Unfortunately, the highest priority ones are often the most difficult and trickiest, requiring occasional questions when I run into things other have had experience in. Is the loss in time spent on high priority items worth fewer quick distractions to the rest of the team?

Oh, OK. I get where you're coming from now.

Is the loss in time spent on high priority items worth fewer quick distractions to the rest of the team?

It all depends on the tasks and your particular work environment. It's going to vary from place to place, so I don't have anything specific to tell you other than this kind of prioritization is the kind of conversation you should be comfortable having with your lead. Or at a status meeting or standup, if your process makes that the better place to ask.

I work at an agency where there is a steady stream of tickets. We are very concious of the cost of task switching. In the case where you are blocked on a task and it is left unfinished in favor of a new task of lower priority, when you finally get an answer on the first task you often have to dro the second task abruptly. So you have two unfinished tasks and all the mind balls you were juggling are dropped on the floor.

However we are also an almost entirely engineering team so there is no resource for getting unblocked that isn't bugging another developer who then drops his mind balls.

It is just the reality of it though, we have tickets and tasks to complete and we can work toward being more efficient, making sure we aren't going to get blocked befor getting started on a ticket and such. It's all a balancing act and it's important to be aware of it, but I no longer get my knickers in a knot over it.

Doesn't Slack have a similar system to IRC, where you can specifically send a notification to someone by prefixing with their handle?

I've worked remotely for many years and this was never a problem. Need some company? Just read and follow a few channels. Want to get work done? Ignore client and code. If someone needs me, a notification + sound will pop up. Works fine with IRC, really.

That sounds a bit strange because there's always something else you could be doing while waiting for that answer? Either working on another issue, or trying to improve something without being asked to, or even just learning something that could (or not) be helpful sometime in the future. Worst case scenario: read some HN :-)

But really: doesn't working remotely mean that, when blocked, you can just leave the computer and do some life stuff, then come back a few hours later and continue from there?

Sure, I can always do something else instead, but that context switching is costly for me as well, when a minute-long conversation, though briefly distracting for a colleague, would have been able to keep me working at the task at hand.

How is context switching costly for you, but only briefly distracting for your colleague?

To me it's the difference between a few line exchange that is briefly distracting vs switching to working on a completely different task, getting up to speed on it just in time to have to switch back and refamiliarize myself with where I left off. Order of minutes vs hours.

In my experience the questions tend to cluster towards a small group of individuals; so from their perspective, you're the 5th interruption in line for the day and they've barely been able to start their own work.

That's one reason why I like the idea of taking forced breaks; they give you a scheduled time to handle brief interruptions, and if you're fairly regular people can tune in to your schedule(e.g. if you're always "working" the first 50 mins of an hour and "resting" the last 10 mins, it's easy to know whether you'd be able to quickly answer a question). Of course, the forced breaks are another form of an interruption from flow; it's still a trade-off.

Sorry for the late reply, but "briefly distracting" tells me it's clear you don't understand "the zone".

>>But really: doesn't working remotely mean that, when blocked, you can just leave the computer and do some life stuff, then come back a few hours later and continue from there?

Technically yes. In practice though, this only blurs the boundaries between work and leisure, as you find yourself working in evenings and weekends to make up for those down-times during the week when your team members were unreachable.

Excuse me, but if not getting in touch with your colleagues blocks you for the whole day then you probably have the bigger problems than just not getting your questions answered on time:

1. Maybe documentation is scarce, be it code comments or business requirements specs, user stories, epics, etc.

2. Maybe your tasks are ill defined, and you accepted your assignments without asking enough questions upfront...

3. Maybe you don't get enough workload (if you had many tasks to choose from it would be harder to get blocked on all of them)

4. maybe you lack some technical knowledge or other competencies needed to make the decisions yourself instead of asking others.

That is rubbish. Many reasonably complex projects require a reasonable amount of communication. This list sounds like you have only worked on 1 man toy projects.

Communication, yes. But synchronous, blocking communication?

You have an organizational problem there.

Again, I disagree.

Any reasonably complex codebase I have worked in has at least parts that only a few people understood. Even if n=3, you could still very easily be blocked when trying to find someone in the know...

Right, so an organizational and architectural problem. It's even got a specific term: Bus factor.

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

You have a problem. Disagreeing with me won't fix it. It's a common problem, but also a fixable one.

You're right that these are problems, but how long does it take to solve them?

1) Do you know of a way to document a significantly-sized application in such a way that it is not massively more efficient to ask a colleague for help than to go source-diving? Say we are talking about a rails app that has been maintained for 5 years and with a reasonably complete test suite.

2) Does a fresh-from-uni or perhaps 2-years-out-of-uni junior developer teach themselves how to ask just enough questions up-front that they don't need to ask more to unblock themselves?

4) How does one gain this technical knowledge if you are on a project and need to apply it but don't yet have it yourself?

Well put, thank you.

Re 2: Often tasks are even meant to be exploratory, where those questions can't be asked upon receiving the task, but only once enough investigation has been done and implementation questions are run into. Rather than a quick back and forth that keeps me progressing, I have to context-switch to something else, and spend time re-familiarizing myself with what I had done the day(s) before again.

    Do you know of a way to document a significantly-sized application in such a 
    way that it is not massively more efficient to ask a colleague for help than 
    to go source-diving? Say we are talking about a rails app that has been 
    maintained for 5 years and with a reasonably complete test suite.

Yes. You can draw architectural diagrams. You can create a wiki where people document problems and solutions. You can have broader design reviews where people talk about the ways in which they solved various problems and what considerations they took into account when coming up with those solutions. I agree with the other posters in this thread: if you're truly blocked (i.e. literally unable to work) because someone can't respond to your question, there is something deeply wrong with your codebase, or in the way in which your team communicates. Personally, I would expect anyone who's been on the team for more than few months to be largely self-sufficient when it comes to actually coding. Of course, there will be questions when there are multiple possible approaches to solve a given problem, and I would expect someone to raise a flag and ask about the relevant considerations. But in the absence of a reply, you should be able to pick an approach and push forward with it.

    Does a fresh-from-uni or perhaps 2-years-out-of-uni junior developer teach 
    themselves how to ask just enough questions up-front that they don't need to 
    ask more to unblock themselves?

Honestly, at some point, you have to learn your team's codebase. You say that it's massively more efficient for you to ask questions of colleagues than it is to go source diving. That, to me, indicates that you don't actually know your codebase very well. Again, this is a sign of a problem on the team. Either the source is so tangled that no one can hope to understand all of it, or people are becoming siloed - specializing in particular areas of the codebase in ways that leaves them unable to fix problems in other areas. It's all right to be better at one part of the code than another. For example, I'm better at some of the middle-tier/business-logic code than I am at UI work. But, in a pinch, I can jump in and help with UI if it's necessary.

    How does one gain this technical knowledge if you are on a project and need 
    to apply it but don't yet have it yourself?

I'll be honest. It's rough. You have to learn, and you have to realize that outside of university there aren't going to be TAs and professors to point you in the right direction. You will make mistakes. But that's the only way forward. Keep trying. Keep writing code. If you do something and it doesn't work, have a meeting in which you go over what you did, why it didn't work, and what you could have done better.

1, 4. Yes, documentation is absolutely scarce - given that culture, such back and forth is often required. Some configurations or details of a complex (and often legacy) system are opaque, and used infrequently enough that teamwide training on it isn't appropriate.

2. Yes, often my tasks are exploratory rather than implementation of a particular feature. Often the goal is to explore and then discuss my findings. When I can't just go up to someone's desk in person and ask them when they are free to discuss, Slack is a good resource to set up a meeting.

3. I definitely am not blocked on all, but the context switching hurts my productivity as well - to me, a quick response would have large benefits for me and a minimal distraction for my colleague.

Questions should be on slack.... answers should be on the wiki...

Then check the wiki before you ask a question. Query driven documentation.

I just write together what I need to know and combine into a single email or phone call.

Do you ever find that this approach leads to a subset of your questions being answered? I've found that asking n questions in a row frequently leads to only the nth question being answered (which I presume is often due to content being pushed "below the fold" on mobile devices).

Yes of course, because people are often busy or too lazy to think the answer through.

But that doesn't matter, I can work with the subset.

Sometimes the questions resolve themselves, sometimes I just write another email, it really depends.

You can't pick up the phone?