Live data from Hacker News

Programmer interrupted: The cost of interruption and context switching (2022)

contextkeeper.io

121–130 of 271 posts

Re: Programmer interrupted: The cost of interruption and context switching (2022)

#121
post #9

If I know I am going to have my day broken into sub 1hr chunks thanks to meetings and such, I pretty much write off the day entirely. It takes time to get into the flow state, some studies cite over 20 minutes, and once you are in it you want to stay in it for like four hours. No emails to follow up with, no slack, no zooms, no one tapping your shoulder, no conversations about the weekend distracting you on the perip…

This is exactly the way trydeepwork.com works. You should give it a shot :)

Since you built it, could we get accomplishments and analytics stored completely in localstorage so we don't need to register/login? :)

Re: Programmer interrupted: The cost of interruption and context switching (2022)

#122
post #97

Earlier quoted context omitted.

> no slack, no zooms, no one tapping your shoulder, no conversations about the weekend distracting you on the periphery My teen jobs were in stores, restaurants, and manufacturing. In those contexts, everybody understands that when you're working, you're actually working. Even managers understand that even small discussions need to be fit neatly into the flow of the work, and actual meetings require careful planning…

> And sure, why don't you put me next to the salespeople making calls all day. I’ve worked next to people with zero volume control and who like to take calls on speakerphone. I decided there and then that cubicles has material benefits over open offices.

I'm old enough that I remember a time when developers had offices... sometimes private, sometimes 2 to a large office, but usually shared with other developers who generally also understood the benefit of not being interrupted so it worked out fine.

Young me's head would explode if I got a glimpse into a future where cubicles are now looked at as the good old days.

And the progression keeps going with a lot of companies that have open office "hot desking" where not only are you working in a chaotic open environment, but you don't even have your own little space there from day to day.

All of this makes it seem increasingly bizarre to me that a lot of the industry was forced to make remote work viable through the pandemic and many companies saw productivity go up and now a lot of them are trying to claw back on remote as quickly as possible.

Re: Programmer interrupted: The cost of interruption and context switching (2022)

#123
post #83

Earlier quoted context omitted.

What was that stateless ssh alternative? Using that you don’t even have to reopen the connection, it just works again right away.

mosh?

Eternal Terminal works better.

Re: Programmer interrupted: The cost of interruption and context switching (2022)

#124
post #97
post #9

If I know I am going to have my day broken into sub 1hr chunks thanks to meetings and such, I pretty much write off the day entirely. It takes time to get into the flow state, some studies cite over 20 minutes, and once you are in it you want to stay in it for like four hours. No emails to follow up with, no slack, no zooms, no one tapping your shoulder, no conversations about the weekend distracting you on the perip…

> no slack, no zooms, no one tapping your shoulder, no conversations about the weekend distracting you on the periphery My teen jobs were in stores, restaurants, and manufacturing. In those contexts, everybody understands that when you're working, you're actually working. Even managers understand that even small discussions need to be fit neatly into the flow of the work, and actual meetings require careful planning…

Wait, are you me? I’ve had the exact same experiences! Especially being sat next to sales people. Even when they are not on the phone, they tend to be very loud, outgoing, exuberant, extroverted, etc. and are constantly chatting.

Re: Programmer interrupted: The cost of interruption and context switching (2022)

#125
post #77

Earlier quoted context omitted.

To all above: but machines reboot, also, not? Even our coorp Linuxes now succumb to ugly IT update reboot cycles, Cloud VMs even more ephemeral, and lets not even start with dev containers... One can script tmux sessions to some degree, but still loosing a lot of state (editor open ther, shell history here..).

Rebooting my dev boxes for security updates or kernel upgrades once every few months/year isn't a big deal, and I generally know when it's going down. The laptop is an ssh terminal/browser/doc reader only!

Me too, that's why I don't care how old it is anymore.

Re: Programmer interrupted: The cost of interruption and context switching (2022)

#126
post #104

Not that I like to be interrupted, but if it’s inevitable, here is my method. I’m using it when interruptions are planned, when a task is complex by itself, at refactorings and on bad/lazy days. Log all your key thoughts, realizations, decisions and taken steps on paper. It shouldn’t be long or long-term clear, only clear to today’s you. Gibberish to a bystander. Text, bullets, arrows, acronyms, verbs, marks, anythin…

> Log all your key thoughts, realizations, decisions and taken steps on paper... Text, bullets, arrows, acronyms, verbs, marks, anything that works. Lists, trees, graphs, outlines ... It’s your L2 cache.

This works out nice for using GPT4. If you prepare project information beforehand you can use it in your prompts. I am working on a way to structure my notes to be AI compatible. We can benefit from having to keep prompt materials for GPT, a good reason to have detailed notes in the first place and it's exactly the diff between general knowledge and project knowledge.

Re: Programmer interrupted: The cost of interruption and context switching (2022)

#127
post #100

Earlier quoted context omitted.

I think you're still missing the point. It isn't that you need to stay up all night, but rather the flow state. In college you typically have classes during the day so you aren't going to get it then. That doesn't make it a great thing but it also isn't exactly relevant to this conversation.

I understand the point they're making, but I'm not sure you understand mine though. If someone talking about weight loss suggested that people should just never eat breakfast to reduce the amount of eating they do in a given day, it would be relevant to offer a critique this may end up being counterproductive overall to the goal due to it just pushing the issue into another part of the day; this is basically the same…

Yeah, but the point you missed was about the uninterruptedness of studying for an exam — a student might be able to dedicate a whole week to learning for an exam and then study each day with minor interruptions.

That those studying session can sometimes be too long to be healthy is certainly true, but was not the point argued here.

When someone argues that a Ferrari is a fast car and you criticize that not all red cars are fast, you are arguing against a statement nobody made while still saying something true.

Re: Programmer interrupted: The cost of interruption and context switching (2022)

#128

The problem is not that some managers think that it’s OK for software engineers to be interrupted frequently. The problem is that some managers think that frequently interrupting software engineers is a feature of startup culture. I once worked for a startup where I was interrupted frequently. My boss often worked remotely, while I was in the office every day. If I tried to carve out periods to write code where I ign…

[dead]

Re: Programmer interrupted: The cost of interruption and context switching (2022)

#129
You're going to be interrupted, so you better learn to do it efficiently.

Learn not to have some flow state that takes a half hour to get into.

That flow state is bullshit. You get so absorbed into the work that you do stupid things a mile a minute. Sometimes it takes an interruption to get you to see it. Let's see, where was I. Ah I was doing that, for such and such reason, and ... wait what? That's stupid. Let's scrap 75% of it and do it in this better way ...

If it takes a long time to get into flow states, it could indicate that you have some problem in the project. To be able to do anything, you have to boostrap various bits of information into your head, and keep juggling it. Then have it all vaporize upon interruption. Maybe there are better ways. Some tooling or documentation strategy, or automation of this or that. Try to have it so that someone with anterograde amnesia could use your environment to get stuff done.

Re: Programmer interrupted: The cost of interruption and context switching (2022)

#130

Earlier quoted context omitted.

> And sure, why don't you put me next to the salespeople making calls all day. I’ve worked next to people with zero volume control and who like to take calls on speakerphone. I decided there and then that cubicles has material benefits over open offices.

I'm old enough that I remember a time when developers had offices... sometimes private, sometimes 2 to a large office, but usually shared with other developers who generally also understood the benefit of not being interrupted so it worked out fine. Young me's head would explode if I got a glimpse into a future where cubicles are now looked at as the good old days. And the progression keeps going with a lot of compan…

It's not about productivity, it's about power and control.

Also, companies aren't independent entities with their own will. They are just groups of people.

Post reply on HN