3 ms·

Learn to deal with interruptions. It's not reasonable to expect 4+ hours of uninterrupted time per day. We aren't monks copying sacred texts. Being productive

Learn to deal with interruptions. It's not reasonable to expect 4+ hours of uninterrupted time per day. We aren't monks copying sacred texts. Being productive despite interruptions is a job skill. It can be achieved. It's a more realistic path to success than blocking off 4+ hours per day, because most people are in a position where they need to attend the meetings they are told to attend.

sedgjh23 6y ago
context switching is the mind killer
- twblalock 6y ago
  > context switching is the mind killer Only if you let it be. Minimize the context. It turns out that good programming practices work well for this: break things down and encapsulate them. You haven't done that if you need to maintain a giant complex picture in your head that goes "poof" and disappears when people interrupt you, or when you need to go to the bathroom, or when you go to lunch. Break things down into smaller parts. Encapsulate. Write things down. Get used to picking up where you left off. It takes practice just like anything else, but it's worth it. Demands on your time only become more intense as you advance in your career, so it's very beneficial to develop those skills early on.
  - judofyr 6y ago
    I have no idea why you're getting downvoted into oblivion. These all sounds like excellent ideas. Can someone elaborate what's so controversial in this comment?
    - disgruntled101 6y ago
      it has triggered mediocre CRUD maintainers that do not have fundamental development skills and yet think very highly of themselves because they know how to write a new API endpoint
    - corty 6y ago
      The grandparent is a naive oversimplification. Most things that aren't just very trivial CRUD do have irreducible complexity, that cannot be encapsulated away. Also, making notes doesn't help there, notes that were written need to be read again and again and again, multiplying the effort involved.
    - probably_wrong 6y ago
      I did not downvote that comment, but I think it's bad advice for two reasons: 1. It tries to address the sympthoms without solving the problem. Building a workflow around the distractions assumes that my time is less important than everybody else's. 2. Programming is hard. The comment suggests that the solution to the overhead caused by context switching is... adding more overhead. How about letting people work in peace instead?
    - lostdog 6y ago
      Often all the context you load into your head is other people's code. Sometimes you don't have control over how complex the codebase becomes. Debugging also requires a lot of context. I didn't downvote the comment (yet), but I understand why many people did: It's incredibly dismissive and wrong! Yes, you should adopt methods for keeping the context so you don't lose it and continue from where you started. I've added plenty of tools to my mental toolbox, and now I work on more complex problems more quickly then before. However, even with good context-keeping skills, protecting a block of time will still 10x your productivity over being interrupted constantly. Developers don't demand focus time for their own comfort. It's because the focus time is necessary for good work.
    - gumby 6y ago
      To add to the other comments: the work of figuring out how to break things down often requires long periods of quiet thought. In addition, I often refactor as I write, as the process of implementation can uncover poor design decisions made up front. In short: my work is rarely "beads on a string" that can easily be popped off, and to the degree they are, the unit of time is typically hours, not a half hour.
- gumby 6y ago
  and I fear it.
markrages 6y ago
Monks copying texts would be a lot more interruptible than the kind of creative intellectual work that programmers do.
- judofyr 6y ago
  What makes programmers so special? Don't we have ton of grunt work as well? Don't most of us also work on rather trivial CRUD applications? And what work is actually interruptible? Is a sales rep. preparing for a meeting interruptible? Is a project manager planning the next quarter interruptible? I agree that context switching and interruption has a high cost, but isn't the cost pretty much the same regardless of your job?
  - Cthulhu_ 6y ago
    No I don't think so; a monk copying work is different from a developer creating original work. I'll admit that trivial CRUD applications are boring, but with that kind of application it's about understanding and shaping the domain. Naming things, if you will. (disclaimer: I'm working on a CRUD app as we speak, thousands of fields in dozens of modules).
    - bosie 6y ago
      so the question was what makes software developers different? also, what does original work mean? If you mean in the sense of PhD level research, I haven't worked in a lot of places where 'original work' was done. it is mostly glueing together other people's work (which is original to the person doing the glueing maybe).
      - nefitty 6y ago
        A developer has to hold a cogent mental model of the problem they’re working on. Someone copying text might be able to do it while thinking of other things. If a developer is interrupted, their mental model “pops” like a bubble, and they might have to mentally start from scratch once they’ve dealt with the interruption.
pkulak 6y ago
No thanks. I'd rather spend my resources anywhere else. I'm an engineer, not a manager. I would never tolerate a management load of meetings, just like a manager shouldn't be asked to write code all day. Now, I don't know what the job description was of the person who wrote the article, or yours. Maybe your saying that distractions in management need to be expected and dealt with? You could be right, I don't really know. :)
- anticristi 6y ago
  I'm not sure I like it, but I developed a skill for "listening in with one ear". A bit like a pilot flying a plane very focused, but hearing ATC when their callsign is spoken. When my role is only "advisory" it kind of works, albeit it does slow down the meeting overall and can be seen as rude.
  - juancb 6y ago
    Interesting analogy. The nice thing about ATC (when VFR) is that the phraseology is well defined and outside of emergencies the number of requests and instructions are limited and usually expected. When flying IFR then you've planned ahead, filed that plan, and either received exactly what you want or gotten an updated plan. If things change along the way you get small digestible updates. And you are of course going to brief your approach before executing it. Meetings are much more dynamic.
peteretep 6y ago
> It's not reasonable to expect 4+ hours of uninterrupted time per day I can deal with interruptions, but I’m also able to setup work blocks? People wouldn’t dream of interrupting me during a four hour meeting, and they don’t need to know my work blocks are that, rather than meetings.
blabitty 6y ago
No, what's not reasonable is being expected to do creative, novel work in little 30-60 minute slices of time between status meetings or slide deck presentations.
Forge36 6y ago
You can do both. I let people know "ask me before you schedule over a meeting". They'll do it anyway, but this allows me to decline a meeting with an excuse if I don't need to be there. If it's important: they're not likely to explain their justification for me (in doing so providing me with more context on their problem). If by luck 4/5 days stay unbooked you have 16 focus hours of work. I use 2 hour blocks 5 days a week

sedgjh23 6y ago

context switching is the mind killer

twblalock 6y ago
> context switching is the mind killer Only if you let it be. Minimize the context. It turns out that good programming practices work well for this: break things down and encapsulate them. You haven't done that if you need to maintain a giant complex picture in your head that goes "poof" and disappears when people interrupt you, or when you need to go to the bathroom, or when you go to lunch. Break things down into smaller parts. Encapsulate. Write things down. Get used to picking up where you left off. It takes practice just like anything else, but it's worth it. Demands on your time only become more intense as you advance in your career, so it's very beneficial to develop those skills early on.
- judofyr 6y ago
  I have no idea why you're getting downvoted into oblivion. These all sounds like excellent ideas. Can someone elaborate what's so controversial in this comment?
  - disgruntled101 6y ago
    it has triggered mediocre CRUD maintainers that do not have fundamental development skills and yet think very highly of themselves because they know how to write a new API endpoint
  - corty 6y ago
    The grandparent is a naive oversimplification. Most things that aren't just very trivial CRUD do have irreducible complexity, that cannot be encapsulated away. Also, making notes doesn't help there, notes that were written need to be read again and again and again, multiplying the effort involved.
  - probably_wrong 6y ago
    I did not downvote that comment, but I think it's bad advice for two reasons: 1. It tries to address the sympthoms without solving the problem. Building a workflow around the distractions assumes that my time is less important than everybody else's. 2. Programming is hard. The comment suggests that the solution to the overhead caused by context switching is... adding more overhead. How about letting people work in peace instead?
  - lostdog 6y ago
    Often all the context you load into your head is other people's code. Sometimes you don't have control over how complex the codebase becomes. Debugging also requires a lot of context. I didn't downvote the comment (yet), but I understand why many people did: It's incredibly dismissive and wrong! Yes, you should adopt methods for keeping the context so you don't lose it and continue from where you started. I've added plenty of tools to my mental toolbox, and now I work on more complex problems more quickly then before. However, even with good context-keeping skills, protecting a block of time will still 10x your productivity over being interrupted constantly. Developers don't demand focus time for their own comfort. It's because the focus time is necessary for good work.
  - gumby 6y ago
    To add to the other comments: the work of figuring out how to break things down often requires long periods of quiet thought. In addition, I often refactor as I write, as the process of implementation can uncover poor design decisions made up front. In short: my work is rarely "beads on a string" that can easily be popped off, and to the degree they are, the unit of time is typically hours, not a half hour.
gumby 6y ago
and I fear it.

markrages 6y ago

Monks copying texts would be a lot more interruptible than the kind of creative intellectual work that programmers do.

judofyr 6y ago
What makes programmers so special? Don't we have ton of grunt work as well? Don't most of us also work on rather trivial CRUD applications? And what work is actually interruptible? Is a sales rep. preparing for a meeting interruptible? Is a project manager planning the next quarter interruptible? I agree that context switching and interruption has a high cost, but isn't the cost pretty much the same regardless of your job?
- Cthulhu_ 6y ago
  No I don't think so; a monk copying work is different from a developer creating original work. I'll admit that trivial CRUD applications are boring, but with that kind of application it's about understanding and shaping the domain. Naming things, if you will. (disclaimer: I'm working on a CRUD app as we speak, thousands of fields in dozens of modules).
  - bosie 6y ago
    so the question was what makes software developers different? also, what does original work mean? If you mean in the sense of PhD level research, I haven't worked in a lot of places where 'original work' was done. it is mostly glueing together other people's work (which is original to the person doing the glueing maybe).
    - nefitty 6y ago
      A developer has to hold a cogent mental model of the problem they’re working on. Someone copying text might be able to do it while thinking of other things. If a developer is interrupted, their mental model “pops” like a bubble, and they might have to mentally start from scratch once they’ve dealt with the interruption.

pkulak 6y ago

No thanks. I'd rather spend my resources anywhere else. I'm an engineer, not a manager. I would never tolerate a management load of meetings, just like a manager shouldn't be asked to write code all day. Now, I don't know what the job description was of the person who wrote the article, or yours. Maybe your saying that distractions in management need to be expected and dealt with? You could be right, I don't really know. :)

anticristi 6y ago
I'm not sure I like it, but I developed a skill for "listening in with one ear". A bit like a pilot flying a plane very focused, but hearing ATC when their callsign is spoken. When my role is only "advisory" it kind of works, albeit it does slow down the meeting overall and can be seen as rude.
- juancb 6y ago
  Interesting analogy. The nice thing about ATC (when VFR) is that the phraseology is well defined and outside of emergencies the number of requests and instructions are limited and usually expected. When flying IFR then you've planned ahead, filed that plan, and either received exactly what you want or gotten an updated plan. If things change along the way you get small digestible updates. And you are of course going to brief your approach before executing it. Meetings are much more dynamic.

peteretep 6y ago

> It's not reasonable to expect 4+ hours of uninterrupted time per day I can deal with interruptions, but I’m also able to setup work blocks? People wouldn’t dream of interrupting me during a four hour meeting, and they don’t need to know my work blocks are that, rather than meetings.

blabitty 6y ago

No, what's not reasonable is being expected to do creative, novel work in little 30-60 minute slices of time between status meetings or slide deck presentations.

Forge36 6y ago

You can do both. I let people know "ask me before you schedule over a meeting". They'll do it anyway, but this allows me to decline a meeting with an excuse if I don't need to be there. If it's important: they're not likely to explain their justification for me (in doing so providing me with more context on their problem). If by luck 4/5 days stay unbooked you have 16 focus hours of work. I use 2 hour blocks 5 days a week