3 ms·

I don't remember where I read it, in a book or on HN or even if someone told it to me. But I learned that when requesting time or disruption: certain positions

by dijit 4y ago

I don't remember where I read it, in a book or on HN or even if someone told it to me. But I learned that when requesting time or disruption: certain positions need specialised handling. An example: A receptionist does not necessarily need focus time, and is interrupt driven, so their work should not stretch to more than 5 minute intervals; if something takes more than 5 minutes it must be filed for someone else. A manager manages their time in 30 minute increments, anything that can't reasonably be done inside a meeting is unfortunately unlikely to happen. This is stupid, but it's unfortunately true; you might sometimes experience other situations but I think that's not the common case. A programmer (or, researcher, etc;etc) books time in half-day increments. If you must have a meeting with programmers, it's often better to book events in serial but only consume half a day. I've been practising this methodology for 8 or so months in my org and it does seem to hold true in the general case, there are some minor exceptions but most people do seem to he happy. EDIT: It was the "Makers Schedule" by PG; Serves me right not to read the comments[0] before commenting. [0]: https://news.ycombinator.com/item?id=35462780 https://news.ycombinator.com/item?id=35462780

rtpg 4y ago
I feel that this is extremely dismissive of the reality that other people do in fact have similar focus requirements, but simply have learned to take notes or otherwise deal with interruptions. There are more demand driven roles but probably every person you interface with on a day to day basis professionally has hard work to do. Sales copy? Focus. Figuring out some accounting discrepancy? Focus. Trying to actually plan out the next quarters projects in a decent way? Focus. Trying to find a good place for a year end party? Focus! The reality is that everyone has similar interruption issues, but understands the existence of needs beyond themselves when working on a team. Programmers are maybe special in the level of coddling gotten on this topic. Along with a dose of having people more likely to have general executive control issues. This mythologizing gets in the way of trying to tactically improve things. Real things programmers can do, such as take notes on paper, documenting ideas, writing exit/entry notes, and many other things people do to be able to come back into a project after interruptions. It’s very liberating to find workflows where you can actually get stuff done even in small increments, because you are not relying on this idea of doing a hard reset of your mind every time you switch tasks EDIT: to be clear, it’s good to let people work uninterrupted. Sometimes interruptions are needed because of working in a company where other people also have needs. This is true of many people working at a company, and so we should operate understanding interruptions exist and we are the same as other people.
- wellanyway 4y ago
  You aren't seriously comparing looking for a restaurant with fixing bugs in a enterprise scale codebase, are you?
- sanitycheck 4y ago
  Maybe the difference between programming and most other office activities, for me at least, is that I'm very often working near the limits of my competence for long periods of time. Over the years my competence grows but my problems expand to match it. I don't think that's at all comparable with writing sales copy or finding a venue. Figuring out an accounting discrepancy might be harder for a junior auditor than a senior one, because competence grows but the problems remain a similar size. (Or I'm talking out of my ass, I only have second-hand knowledge of audit and I'm led to believe that the attitude of big firms is that if something is very hard to find, it's not worth finding because nobody else will find it later!) Planning the next quarters projects tends to be a collaborative activity rather than one requiring deep individual flow state, I think.
  - rtpg 4y ago
    > I'm very often working near the limits of my competence for long periods of time. Over the years my competence grows but my problems expand to match it. I think that's an interesting way of putting it. I've seen coworkers in non-tech positions go through this. There is a scope expansion (though of a bit of a different flavor) going on often. Many people go to their 1-on-1s and talk about wanting to be challenged more, and looking for new problems to tackle. But I do think that a lot of stuff, including "collaborative" things, do end up with similar mental blockage. How many times does your manager tell you "I wanted to get back to this message, but I had so much come up all day", even though the final response was maybe only a paragraph or two long? Especially in more chaotic environments people are facing unique flavors of problems pretty often in my opinion. At one point the systems being juggled are probably very complex, and perhaps the ceiling of problem is highest for programmers. But I think it's important to not underestimate the difficulties and intractability of things other people are working on (since the intractability is ultimately what generates this whole issue with focus)
- 4y ago

by dijit 4y ago

rtpg 4y ago

I feel that this is extremely dismissive of the reality that other people do in fact have similar focus requirements, but simply have learned to take notes or otherwise deal with interruptions. There are more demand driven roles but probably every person you interface with on a day to day basis professionally has hard work to do. Sales copy? Focus. Figuring out some accounting discrepancy? Focus. Trying to actually plan out the next quarters projects in a decent way? Focus. Trying to find a good place for a year end party? Focus! The reality is that everyone has similar interruption issues, but understands the existence of needs beyond themselves when working on a team. Programmers are maybe special in the level of coddling gotten on this topic. Along with a dose of having people more likely to have general executive control issues. This mythologizing gets in the way of trying to tactically improve things. Real things programmers can do, such as take notes on paper, documenting ideas, writing exit/entry notes, and many other things people do to be able to come back into a project after interruptions. It’s very liberating to find workflows where you can actually get stuff done even in small increments, because you are not relying on this idea of doing a hard reset of your mind every time you switch tasks EDIT: to be clear, it’s good to let people work uninterrupted. Sometimes interruptions are needed because of working in a company where other people also have needs. This is true of many people working at a company, and so we should operate understanding interruptions exist and we are the same as other people.

wellanyway 4y ago
You aren't seriously comparing looking for a restaurant with fixing bugs in a enterprise scale codebase, are you?
sanitycheck 4y ago
Maybe the difference between programming and most other office activities, for me at least, is that I'm very often working near the limits of my competence for long periods of time. Over the years my competence grows but my problems expand to match it. I don't think that's at all comparable with writing sales copy or finding a venue. Figuring out an accounting discrepancy might be harder for a junior auditor than a senior one, because competence grows but the problems remain a similar size. (Or I'm talking out of my ass, I only have second-hand knowledge of audit and I'm led to believe that the attitude of big firms is that if something is very hard to find, it's not worth finding because nobody else will find it later!) Planning the next quarters projects tends to be a collaborative activity rather than one requiring deep individual flow state, I think.
- rtpg 4y ago
  > I'm very often working near the limits of my competence for long periods of time. Over the years my competence grows but my problems expand to match it. I think that's an interesting way of putting it. I've seen coworkers in non-tech positions go through this. There is a scope expansion (though of a bit of a different flavor) going on often. Many people go to their 1-on-1s and talk about wanting to be challenged more, and looking for new problems to tackle. But I do think that a lot of stuff, including "collaborative" things, do end up with similar mental blockage. How many times does your manager tell you "I wanted to get back to this message, but I had so much come up all day", even though the final response was maybe only a paragraph or two long? Especially in more chaotic environments people are facing unique flavors of problems pretty often in my opinion. At one point the systems being juggled are probably very complex, and perhaps the ceiling of problem is highest for programmers. But I think it's important to not underestimate the difficulties and intractability of things other people are working on (since the intractability is ultimately what generates this whole issue with focus)
4y ago