3 ms·

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 o

by 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)
mtrower 4y ago
I feel in turn that this comment is the dismissive one, and in fact extremely so. The issue is not that programmers need to focus, is that they need to focus on deep, complex work. At least a few of those other tasks you mention (don’t have much experience with sales copy, and in rather terrible with both sales and copy) do require focus but have smaller reasonable increments of progress. Stop thinking about the workplace for a moment and think more broadly of tasks throughout the entire day. Some of those are more easily put down and returned to than others. Some examples of tasks which require focus but interrupt well: formatting meeting notes into minutes, simple accounting (paying bills, reconciling a ledger). The main point with these are that the individual units of work are small, and don’t generally require a lot of mental preloading to begin/resume working on. So if I am interrupted it can be irritating but I don’t really lose much. Programming generally involves a lot of mental state that needs to be preloaded, and the Subtask units are often not small. That’s all. Regarding the insinuation that this “myth” is the result of coddling at the professional level: if this were true, then non-professionals would not discover this independently for themselves…
- rtpg 4y ago
  As someone who's had to come up with product copy and have had to fix bugs, people trying to interrupt me writing a long e-mail gets me way more than people interrupting me while trying to fix a bug where I already "know" the issue and I'm just doing the cleanup/test writing. I am being too glib. But the sort of "focus broken, can't move forward" feeling is something I constantly have felt in many non-programming tasks. Granted this blocking is also due to the nebulous nature of those tasks vs, say, fixing a bug. Most bugs (not all!) at least have some sort of definitiveness to them. The coddling I talk about is stuff like other staff members being told to "not bother the coders", something I've seen first and second hand. That, along with many programmer's (myself included) habit of generating endless excuses for why something is not happening and it being more or less accepted as a given. But as someone who struggles with this stuff, I also know that a large percentage of it is due to my own behavior! And changing that has improved things. My post is combatative, but mainly because I really want people who read this stuff to introspect on their own behavior, and _improve_, instead of assuming that the task is impossible due to some intrinsicc nature of the work that is overestimated
908B64B197 4y ago
> 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. Sure everyone deals with interruptions. But the real question is how deeply focused do they need to be to operate? How many variables to they need to keep in their head so to speak, to do effective work? Is it the same for engineers vs other disciplines? > 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. Question is: are you willing to foot the bill? This extra reading/writing/documenting takes time. Is it worth it to get a more responsive engineer? It's really the same constrains as in operating system design; you can context switch endlessly by restoring state, but you'll pay with disk access time. > 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 That's assuming you can break down tasks that way. Deep engineering work often doesn't work that way.
z3ugma 4y ago
I fully agree with you. I’ve been a software developer, a customer support engineer, and a product manager. My focus is also distracted by meetings and urgent things. My work is also best done when I have some time to focus. Everyone else in the professional world learns to defend their time, turn off interruptions, say no to meetings or decline them and ask for a reschedule. I actually view this as an undervaluing of communication and teamwork skills in the way we educate and hire software engineers.

by rtpg 4y ago

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)

mtrower 4y ago

I feel in turn that this comment is the dismissive one, and in fact extremely so. The issue is not that programmers need to focus, is that they need to focus on deep, complex work. At least a few of those other tasks you mention (don’t have much experience with sales copy, and in rather terrible with both sales and copy) do require focus but have smaller reasonable increments of progress. Stop thinking about the workplace for a moment and think more broadly of tasks throughout the entire day. Some of those are more easily put down and returned to than others. Some examples of tasks which require focus but interrupt well: formatting meeting notes into minutes, simple accounting (paying bills, reconciling a ledger). The main point with these are that the individual units of work are small, and don’t generally require a lot of mental preloading to begin/resume working on. So if I am interrupted it can be irritating but I don’t really lose much. Programming generally involves a lot of mental state that needs to be preloaded, and the Subtask units are often not small. That’s all. Regarding the insinuation that this “myth” is the result of coddling at the professional level: if this were true, then non-professionals would not discover this independently for themselves…

rtpg 4y ago
As someone who's had to come up with product copy and have had to fix bugs, people trying to interrupt me writing a long e-mail gets me way more than people interrupting me while trying to fix a bug where I already "know" the issue and I'm just doing the cleanup/test writing. I am being too glib. But the sort of "focus broken, can't move forward" feeling is something I constantly have felt in many non-programming tasks. Granted this blocking is also due to the nebulous nature of those tasks vs, say, fixing a bug. Most bugs (not all!) at least have some sort of definitiveness to them. The coddling I talk about is stuff like other staff members being told to "not bother the coders", something I've seen first and second hand. That, along with many programmer's (myself included) habit of generating endless excuses for why something is not happening and it being more or less accepted as a given. But as someone who struggles with this stuff, I also know that a large percentage of it is due to my own behavior! And changing that has improved things. My post is combatative, but mainly because I really want people who read this stuff to introspect on their own behavior, and _improve_, instead of assuming that the task is impossible due to some intrinsicc nature of the work that is overestimated

908B64B197 4y ago

> 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. Sure everyone deals with interruptions. But the real question is how deeply focused do they need to be to operate? How many variables to they need to keep in their head so to speak, to do effective work? Is it the same for engineers vs other disciplines? > 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. Question is: are you willing to foot the bill? This extra reading/writing/documenting takes time. Is it worth it to get a more responsive engineer? It's really the same constrains as in operating system design; you can context switch endlessly by restoring state, but you'll pay with disk access time. > 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 That's assuming you can break down tasks that way. Deep engineering work often doesn't work that way.

z3ugma 4y ago

I fully agree with you. I’ve been a software developer, a customer support engineer, and a product manager. My focus is also distracted by meetings and urgent things. My work is also best done when I have some time to focus. Everyone else in the professional world learns to defend their time, turn off interruptions, say no to meetings or decline them and ask for a reschedule. I actually view this as an undervaluing of communication and teamwork skills in the way we educate and hire software engineers.