Live data from Hacker News

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

contextkeeper.io

201–210 of 271 posts

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

#201

Earlier quoted context omitted.

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…

The cause of all this is the grafted on management caste, that does not code. For them the whole endavour suspicously looks like not doing a thing, for to do a thing, there needs to be communication, information flowing up and down the hierarchy. Not some dude sitting there like a zen monk, reading, ocassionally typing. Slackers! Best load there calendars, to get them going..

I'd say the cause of this is the developers can't explain themselves, cannot defend why they need isolation, why they should not be interrupted, and more often than not can't explain what they do, what their jobs are and why they are required, in an understandable manner to the management caste. They act as they do because the developers are an opaque pool who talk nonsense when asked questions. Of course they/we get treated poorly.

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

#202

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…

We share an old (1960's) building with our research department. Almost everyone has an office, except for contractors and administrative assistants who are in cubes.

This building is scheduled for demolition and we're being moved to an open-area workspace in a new building.

At least it's above trendy retail so we can get overpriced coffee and sushi on our lunch breaks.

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

#203
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…

Here's my method, tell anyone who interrupts you to "FUCK OFF" because your busy.

Once you’ve done that, you’ve already lost. Interruption encountered.

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

#204

Sadly, the cost of context switching is well-known, and has been proven, over and over again, for decades. But managers don't care (and many co-workers also). A quick shufti at most modern open-plan offices, shows the contempt that managers have for developer context. They know better, and have made the conscious decision to go open, anyway. I remember visiting the Facebook/Instagram building, in NYC, and was aghast…

This killed me my last few years at Apple in the spaceship. Everything in the fucking building is a distraction and most of it is constantly in your line of sight at all times. Even if I managed to angle my monitor right, put on headphones, and pull my hoodie up to reduce distractions some side conversation or impromptu stand up would inevitably distract me and pull me out of my flow. I tried to come in as late as pr…

> Collaboration happens when engineers want to share ideas, not because they're imprisoned in a glorified fish tank for eight hours a day.

I feel like this is an obvious truth that is somehow overlooked a lot, willfully or otherwise.

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

#205
post #161

Earlier quoted context omitted.

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 p…

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 work…

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

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

#206
post #161

Earlier quoted context omitted.

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 p…

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 s…

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

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

#207
I'm not a programmer but always tried to be one. Now in middle age I know I could have been one there's nothing amazing about it you just practice with guidance. Like playing a musical instrument very few people can play instantly unless they practice. Sure there are Mozarts but 99.999% of musicians are not.

I went to school a few years ago and we had programming. I was able to do it but my younger classmates were better. A few were savants I think done in 5 minutes what it took the others an hour.

For me I had to use white noise and earbuds. Even someone walking by on the other side of the row of desks would make me lose focus. I got tests done not all perfect, some half, some not at all.

It gives me hope to know it's not just me.

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

#208

I actively like being distracted when I'm programming. I tend to approach a problem from lots of different directions, each time fizzling out, hitting a block or having some sort of mental reset, until something unconsciously clicks and an overall structure, understanding or solution emerges. Continually leaving and returning to the problem is a part of that process, so I tend to find someone walking up with a questi…

Indeed, this seems unusual in programmer land. As evidence we have a thread like the current one reaching the front page several times a day. But your way is also my way. I am active in a very wide array of topics, and happy to flit between them. Sometimes I dive deep, but it's usually in a critical moment of synthesis when ideas developed over months or years come to clarity and I put them to action. This is working…

That’s quite the claim regarding flow. Invaluable to you if so, but my question would be, how are you defining it? You mention having an eye on your kids, but flow should completely tune out everything other than the precise problem at hand.

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

#209

ContextKeeper sounds interesting. Can anyone here recommend a similar extension for VSCode? Ideally would offer a way to stash and unstash code and tab metadata (cursor position, undo state, etc) with one IDE keystroke.

ContextKeeper's founder here. VSCode plugin is on the roadmap and hopefully it will be available before the end of 2023.

Both plugins, for VSCode and Visual Studio, will be using the same JSON format for storing "contexts". In other words it will be possible to share "contexts" between teammates, no matter which IDE they are using personally. There are multiple scenarios where it could be useful and improve sharing technical knowledge, such as, faster bug fixing and better understanding of large system architecture, within an organization.

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

#210

Non programmers won't get it. I am trying to explain it to my wife (using the cartoon on the article) but she says I am always busy. Which is probably true, but somehow she manages to interrupt my thoughts right when I was holding the whole heap in one hand, reaching for the duct tape with the other and pushing the keyboard with the nose. Never when I just started vscode :)

"Non programmers won't get it" Complete ignorance for what other jobs do. Writing code is not so different from writing long reports. When I am writing a long report, I need to focus as well and do not want to be interrupted. Programming is not the only job that requires deep thought and concentration.

You’re right, but… do you write long reports, all day, every day?
Post reply on HN