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