re: Are interruptions really worse for programmers than for other knowledge workers? VIEW POST

FULL DISCUSSION
 

Thanks for posting this, I think it's an important conversation to have.

On the one hand, I would echo what Daniel said: context-switching is a skill that can be developed. Anyone who is caregiver has had to learn this. No one likes it. It is exhausting. But we can get better at reducing its costs through practice. And I strongly agree with when the speaker in the video says that (some) interruptions are opportunities for empathy and collaboration. They can even be great time-savers, preventing you from going down some rabbit hole because you didn't quite understand some requirement, meaning an entire feature you had cooked up in your head is actually unnecessary or doesn't need to be prioritized.

The influence of Flow, or at least how it has been promoted and applied within the tech industry, has been a step in the wrong direction in my view. It's fed into a very self-indulgent and unrealistic view of what programming is. This view puts the legitimate interests of developers in autonomy over how projects are implemented in conflict with the rest of the team and in conflict with the interests of users. In addition, it accepts the current messed-up state of affairs as inevitable.

Which brings me to a second point. This basic problem of having to keep too much in your head has rarely been prioritized in the development of the tools we use. As we age, as programmers this becomes more and more important, yet decades-old innovations in this area such as Hindley-Milner type system algorithms and enforced pure functions over immutable state are still not mainstream. Why are we still suffering with imperative languages - in domains which are not memory- and processor- constrained? It's an astonishing contradiction of the tech industry that it appears to change so quickly from the outside yet is moved forward internally by languages and tools that are essentially 50 years old or older. It's hard not to see this as an effect of the industry focused on developing on a younger (and cheaper) workforce, where the priority is less "lessening the need to keep a lot in your head" and more "lowering barriers to proficiency".

My third point is, I don't totally agree with the solution of "just break down the work into smaller chunks". Yes, when we have the freedom and time to do that, and to push back on deadlines on the basis of such an analysis. The key thing is having that autonomy, and establishing that is a question of political strategy in a particular case. I don't think there are easy solutions in general, though I really appreciate the lessons from experience that are outlined in that RubyConf video.

Thanks again for posting!

code of conduct - report abuse