Programmer interrupted: The cost of interruption and context switching (2022)
contextkeeper.io
contextkeeper.io
It's pretty ironic, because this is how a lot of people study in the library at college,show up and stay all night grinding in the flow state with your phone shut off. Yet when you graduate to the work place, you seldom have the opportunity to work like how you've been training to work for all your advanced schooling ever again.
With respect to the article and maintaining context while coding for different projects, I find having a tmux session for each individual project super helpful.
There's a ton written on tmux as you can imagine by this point. This page seems pretty comprehensive on the advanced features including tmux scripting:
You mentioned your editor on the remote server. Does everyone have their own account with their own settings on all remote servers? We're still at a point where everyone accesses servers via the one shared "root-ish" user.
I always run tmux locally. If you want to connect from a different computer, just ssh in and then "tmux attach".
For what you are describing the best practice is a nested tmux session with tmux running locally and on the remote server. So you would open tmux locally, then in one of the windows or panes you ssh into your machine, then open tmux on that machine. This will require you to press the tmux prefix (ctrl+b or however you've set it) twice to do the commands on the remote tmux instance. However you can get around this with some configuration (1).
1. https://www.freecodecamp.org/news/tmux-in-practice-local-and...
I think certain certain terminal emulaters like iterm2 have tmux specific features that could also be helpful, but I don't use that software so I am not as familiar.
Sure you do. The college day is broken up into many unrelated scheduled meetings, with high switching cost. Then you do the deep work after hours.
My post-graduation life is not so different. Maybe it suits my brain, but it's been OK. I like the work.
I find that this leads everyone to constantly do multiple concurrent tasks. After a long day I often have a headache from having to concentrate on both my coding task, an operations task, a meeting, and a new request at the same time.
Ultimately, as you would expect - productivity is awful. They then have lengthy discussions on how to improve productivity by every mechanism other than what’s known to work (faster builds, faster tests, increased focus time)
Often, the real problem is that people don’t actually have 1 hour of working time in between meetings. We sit at our desks and feel obligated to respond to e-mails and Slack messages. Our Slack responses turn into conversations that consume 5-20 minutes without a clear end. We need to spend 5-10 minutes reading backlog to catch up. We need to get a drink or use the restroom. That 1-hour chunk of free time on your calendar may only have 10-15 minutes of concentration time, which is the real problem.
I’ve had some success with blocking off calendar time to mark 1-2 hours of focus time. Having something on your calendar makes delayed responses in Slack socially acceptable.
Pomodoro does not need context switching.
Breaks without loading up a different context gives the brain time to bring back the body into a less tense state, so the next cycle can be more energetic/productive than a continuous one. In many cases it lets some ideas run their courses and save time by solving conflicting thought forces.
To be fair, I think staying up all night trying to be productive instead of getting a good night's sleep also makes it hard for most people during the day. As someone who consistently got 6-8 hours of sleep every night in college before a day with classes, I've always been mildly horrified by the fact that "staying up all night studying" is somehow considered a good thing.
Intermittent fasting seems to be a very effective strategy (for reasons unrelated to your point).
Better thing to do is have a routine first. A lot of people don't have any eating habits, it's more of an afterthought or a "whenever I'm hungry I'll eat" kinda thing. You can't base a diet off of that.
If you fix your diet by just eating at the same moments, roughly the same amount of time, only then do you have a baseline. Then make tweaks on that baseline. Evolution instead of revolution, only that will be sustainable.
First world problems; there is so much food that we can make lifestyle choices around it. You can pretend to be a caveman and eat "paleo" since meat is neatly wrapped in plastic at the store and you didn't have to hunt it down. (And if you study the Hadza tribe who are one of the last paleo-bros on the planet you'll find that meat is a small part of their diet). You can forgo certain meats and call your self pescatarian since you can find fish in the middle of a city. And you can intermittently fast since you know that you can quit anytime and stuff yourself full of food.
We as a modern society have to be the most smug of all. Think about every predator in the world. We constantly pay to exercise, to burn off EXTRA calories, where as every other animal on the planet conserves them or expends a vast amount to obtain more.
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.
I don't know why you assume that I don't understand that they're saying that their studying is uninterrupted when it's overnight. That doesn't change the fact that sleep deprivation is also something that makes any sort of studying less effective.
> 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.
In this case, it feels more like someone said that Ferrari is a fast car, and I mentioned that some people can't afford Ferrari's and might find a different car a better fit, and then you came in extremely unhappy with the fact that I dared to mention anything other than a Ferrari because that's the only car OP mentioned. It's extremely common for people to reply to comments making a tangential point, and doing so doesn't at all take away from other people's abilities to have parallel discussions in other subthreads about different points; that's kind of the whole point of this style of forum.
Your point is valid as a tangent, but it doesn’t read as a tangent to me - it reads as attempting to address the point you are responding to.
Just my two cents here.
Tangential, but might be interesting to some:
sometime before the pandemic, after (I think) 30 years of always eating some kind of breakfast, I accidentally missed breakfast once and that day I felt I had significantly less brain fog after lunch.
So I tried again to see if it was just a coincidence, but it had happened again and again.
And, I realized, as long as I don't start to mentally prepare for breakfast I don't start feeling hunger either.
I'm not suggesting this is a good idea for everyone, only that for people like me who has followed "best practice" for decades and doesn't feel too enthusiastic about it, testing out alternative approaches might be a good idea.
PS: the total amount of hunger I feel in a day seems to have gone down too.
My comment is only pointing out that for me it is the opposite: I work better without breakfast.
Do you actually work better, or have you decided that you work better?
As for if I work better or just have decided I work better, I only have 4 or 5 years of experience with this but despite the fact that I love breakfast and lunch I still skip them because the brain fog I seem to get between 1200 and 1400 on days when I eat breakfast just isn't worth it.
Whatever the reason for celebrating overnights, effectivity of it is not it.
Years later some of those kinds of situations were bonding moments, but none of them are considered a good thing.
- not everyone has the same sleep patterns, and while it can usually be coherced, for some that doesn't work or has too many downsides.
- some people have straight sleep issues and, sleeping in 6-8h blocks doesn't help. "then fix the issues" could be the basic advice, but again, that's usually easier said than done, or has worse side effects.
In that respect I agree with parent that it would be nice if "weirs" work patterns were more accepted
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 to not disrupt operations. The space too was carefully designed to maximize effectiveness.
So American office culture seems absolutely wild to me. Especially in software, where we are expected to fit our actual work into a sort of calendar Tetris. Oh, a grand poobah would like another status meeting, plus a lot of time spent coming up with estimates that are not going to change anybody's behavior in the slightest? Gosh, do you think that might have an effect on the completion date? And sure, why don't you put me next to the salespeople making calls all day. I'm not making any progress anyhow.
The only conclusion I can come to is that in a lot of places, productivity is much lower on the list of observed priorities than stated priorities.
Dude, how about a trigger warning next time?
Or better yet, put me next to the salespeople that instead of making calls all day are just goofing off.
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.
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.
Also, companies aren't independent entities with their own will. They are just groups of people.
Lets say it that way, such a mindset ought to be valuable to the extreme. Thats why we see a constant stream of meddle-managers, setting out to make compliance and "apply presure" startups. Its definatly at the core of value generation.
ChatGPT: Ask me on the hour, every hour for my status and remind me of the deadline..
And I theorized that one aspect of hotdesking is absolute control over employees by having them go through the experience of “clearing their desk” every day so they feel like they’re fired every day. This puts the grunts back in their place and keeps everyone docile because you know you’re just a cog and your job is not a permanent thing at all but rather something that you must work hard at earning again for the next day, lest today’s daily desk clearing be your last one.
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.
The cubicle was invented in the 60s as a way to liberate people from the tyranny of the open plan office (just look at film from before then — say, “The Apartment” —- and you’ll see the open plan was the norm.
It’s a shame that the cubicle itself became a tool and exemplar of anomie.
It feels like I can get away with only a few hours of what to me feels like productive work a week. Actually, I had a really good day last week, but then it takes days for the feature to pass review, rework for said review (often trivial remarks), and to end up in the main branch ready for deployment.
The first thing I noticed about white collar work was how gossipy and lazy everyone was. We didn't have time for that in blue collar work. I had no idea how these people were useful to work or society.
It seems so bizarre to me, even today, that most white collar jobs make more money. It's like they took the people who couldn't work physically, made them feel superior, and for some reason paid them unreasonable wages.
> It's like they took the people who couldn't work physically, made them feel superior, and for some reason paid them unreasonable wages.
Easy killer, you're projecting.
I could go back to being a bartender today, and could do 90% of the job (I'd have to refresh my memory how to mix a few drinks, but most of em are still there). I could probably go back to Private Investigator, or food truck work too.
But it took a whole lotta learning to get to the point where I can do my current white collar job. No one I bartended with could stay sober 4+ days a week or avoid DUIs; no way in hell I'd trust them with a production GCP cluster.
In one of the companies I worked for, it was comfortable in the beginning - there were offices, 2-3 programmers in each, not too crowded, but close enough to see when the coworkers were focusing on something and when it would be ok to do a quick "hey, do you know how to...". The company grew, moved to a bigger building, rooms became larger, now there were 4-5 programmers in each. It was still OK then. Calls and longer talks were done in separate rooms, and a quick chat with the guy next to you could be done like you'd do it in a cinema - quietly.
When I was leaving the company years later, it was after it moved to a place with one huge open space and a set of rooms that you needed to book days in advance to use. Some of them were permanently occupied by "important" people even though they had their own offices. That resulted in everybody and they're cat making calls and meetings and sometimes even plannings right in the middle of the open space or in the kitchen. Finally, a "hot desk" system was implemented, and you had to book your desk days in advance.
I asked the CTO who I've know for quite some time - WTF man? He said that he likes it, because he can see at a glance that everybody is working. I was reminded of storehouses with special elevated rooms that had a view on all that happens on the floor. Saying that I got disillusioned doesn't even begin to describe what I've felt then...
This kind of panopticon is how prisons are often organized.
I can be lying on a couch working hard. How does the CTO see that? The typing part is just the tip of the iceberg.
It is amazing that most knowledge worker management does not understand how knowledge workers work. Most of our hardest work does not involve hands on a keyboard.
I've been full remove for a decade. There's no way I could work in an office where "butts in chairs" was the way. I guess I would just have a notepad and a pencil and just sort of move my hand back and forth on it while I was in my head solving the real problems.
https://99percentinvisible.org/episode/the-panopticon-effect...
I think this is the mindset that a lot of people have, but always keep in mind, the meetings is part of your job, and writing code is also only one aspect of your job.
What I'm trying to say is that don't let the meetings frustrate you, instead just accept them and the distractions. Few people get to do what they really want to do all the time, and it does often seem that software developers show some prima donna behaviour in that they just want to stay in their flow and the other aspects of their job should be dismissed.
I mean I get it, writing code / flow state is enjoyable and makes you feel productive, but you get paid for the full package.
Not universally. Programmers are judged by overall success or failure of the project they are working on. And those ones who can take credit for a success or who can effectively deflect blame for failure are the ones who got promoted. Being in the meetings with the decision makers provides the forum for self-promotion and controlling the message. This does not always mean that they did most of the work. More code or less code is unfortunately secondary.
That's a rather junior mentality. When one is junior, yeah, usually the most one can do is moving Jira tickets to Done (which means merging code usually). But when one is senior, the pay increases and promotions come from other activities: mentoring, handling technical topics between teams (usually via meetings), etc.
Ive got some tasks that I can fit in those in between slots. As an IC I would do them at the start/end of the day, but now I do them during those blocks of time. For me, it's things like smaller code reviews, reviewing design docs or triaging issues.
I've been in jobs where that happens only for a few weeks in a year, after major vacations.
> (programmers) generally prefer to use time in units of half a day at least. You can't write or program well in units of an hour. That's barely enough time to get started.
> meetings are a disaster. A single meeting can blow a whole afternoon, by breaking it into two pieces each too small to do anything hard in.
> I find one meeting can sometimes affect a whole day.
> I know this may sound oversensitive, but ... don't your spirits rise at the thought of having an entire day free to work, with no appointments at all? Well, that means your spirits are correspondingly depressed when you don't. And ambitious projects are by definition close to the limits of your capacity. A small decrease in morale is enough to kill them off.
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 at the huge, noisy, crowded office. I would not be able to get any work done, in that environment.
I'm grateful to be in a position, where I work alone (mostly), as I can keep all those balls in the air, and the difference in productivity is amazing.
i bet 99% of time people are interrupting themselves. Like i just did to browse HN.
If you could control when the budget meeting happens, or if you could decline it, you'd have far fewer issues with it.
I don't know about you but I am here on a pomodoro break between two tasks.
Then there is a group of dicks who do it on purpose.
If you don't get up and walk around, at least 15 minutes of light to moderate exercise per hour seated, you will suffer bad health effects. Stuff that can end your life early and in painful ways.
I find walking around every hour or two for a while to collect my thoughts about what I'm working on is still something I can make productive. I bring a notebook with me to do some notes if there's more than I can fit in my head, which is pretty usual. It's a good way to get some planning in.
I interrupt myself when I'm in the flow absolutely never!
For the majority, the cost is not that well known and in general they are not the ones paying for it, you are.
In particular for your colleagues it may be beneficial to disturb you because when they disturb you, you may lose concentration but the may in fact avoid losing it by quickly get an answer to their pending problem.
This is one aspect where LLMs may be very useful: asking something to a tool like ChatGPT may not be faster than asking a colleague, but if it avoids ruining the colleague's concentration it will be a net positive for the company. This is even more true if/when those model will incorporate specific internal knowledge (code, documentation) of the company.
This is true, but the people getting asked are usually the ones doing (much) more delicate work, so it’s their concentration that should be protected.
I check in with the team once a week and make sure the task tracking system is updated. Everyone is happy and stuff gets done.
We're going to have to do some more hands-on work down the line where we're going to need physical presence working with hardware which is going to be an interesting shift, but I still think that we're going to mostly adhere to the usual workflow.
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 practical in order to stay late so I could get work done for a few uninterrupted hours. I found myself going in a day on the weekend to actually get the previous week's work finished. Unfortunately management doesn't like people coming in "late" because they can't lord over them from their offices during the day and constantly interrupt them with meetings.
It was downright insulting that a $5b building intended for professionals didn't have real offices with fucking doors. At the upper management level the fact the company worked as well if not better with WFH policies must be incensing. It makes plain the insipid claims about "collaboration" in that stupid building. Collaboration happens when engineers want to share ideas, not because they're imprisoned in a glorified fish tank for eight hours a day.
That‘s an interesting bit of information. Maybe this is one of reasons in the decline of quality at Apple - at least in temporal terms it could correlate.
This leaves a lot of little bugs sitting around that might only affect say 1% of the user base but every bug is usually a different 1%. So almost everyone ends up running into annoying bugs for their particular usage/workflow. A secondary effect are big mid-cycle releases like iOS 16.4 which end up bundling features likely meant for the 16.0 release in the fall but slipped. Unfortunately due to the crunch they get the same level of testing/bug fixing as the fall point releases.
The building doesn't lead to poor software quality, that's a failure of scheduling/planning on the part of management. The shitty building just puts the software development on Hard Mode.
I feel like this is an obvious truth that is somehow overlooked a lot, willfully or otherwise.
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, anything that works. Lists, trees, graphs, outlines.
It’s your L2 cache. L1 is fast but short and prone to distraction. If you log everything into L2, then returning to the task becomes much easier, because the whole context is right there.
The downside is you have to spend time drawing. The unintuitive upside is that by writing you may make it clear to yourself what maybe wasn’t clear.
IDE may be good at where you were, but it doesn’t know what you thought.
Stuff like this is why I love Hacker News. Rather than making up abstract, weird analogies between a thing, and another very abstract thing I find even more difficult to understand, we can make analogies to technical terms which most people here understand [citation needed], and which anyone who doesn't can easily look up.
Learn some people skills. Software exists for people.
"This will get you trapped as a junior" is just "All managers are terrible and we should never expect more". It's bad-manager apologism.
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.
My mental state isn’t easily capturable on paper since I use visual/spartial memory for programming. Witting it down requires enormous amounts of translation.
An example:
A receptionist does not necessarily need focus time, and is interrupt driven, so their work should not stretch to more than 5 minute intervals; if something takes more than 5 minutes it must be filed for someone else.
A manager manages their time in 30 minute increments, anything that can't reasonably be done inside a meeting is unfortunately unlikely to happen. This is stupid, but it's unfortunately true; you might sometimes experience other situations but I think that's not the common case.
A programmer (or, researcher, etc;etc) books time in half-day increments. If you must have a meeting with programmers, it's often better to book events in serial but only consume half a day.
I've been practising this methodology for 8 or so months in my org and it does seem to hold true in the general case, there are some minor exceptions but most people do seem to he happy.
EDIT: It was the "Makers Schedule" by PG; Serves me right not to read the comments[0] before commenting.
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.
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.
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)
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…
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
Writing is a daunting task for me, but that has more to do with my own talents and experience than anything. Not implying anything about yours, just something to consider.
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.
When you're interrupted, you forget a bunch of the maybes and you have to rebuild them. This is because your evidence is not strong enough yet to have a small graph, it needs to be a big graph (or set).
Main advice is to take small steps. Little pieces that are easily recoverable. Things like unit tests help to establish the facts, allowing you to push some things out of your own memory. Also take some notes to jig your memory.
Sometimes you can't take small steps, because it just happens that you didn't consider something and now there's a large surface to think about. For those times, make sure you're not interrupted.
It somewhat reminds me of this Hemingway quote "You read what you have written and, as you always stop when you know what is going to happen next, you go on from there. You write until you come to a place where you still have your juice and know what will happen next and you stop and try to live through until the next day when you hit it again." I think there's an art to stopping at the right time, even if it's within constraints that aren't in your control.
And where it's possible, I love unit tests for this. Starting off in the morning with a failing unit test from yesterday's close gets me right back into it.
Afterwards, he enquired why engineers were kept separate in their own rooms? And why does one have to be so formal in requesting a meeting even to discuss project issues? It takes lot of time to resolve issues. Why this inefficiency? And the reply he got was, engineers when they are working, they get into a zone. It is very difficult to get into a zone, but very easy to get out of it even with a slightest distraction or interruption. Hence Microsoft provides separate rooms for engineers and meetings are available only when the engineer is free.
If you're having a huge issue with this, I suggest trying to find ways to hold less context at one time.
Write stuff down & get it out of your head more often. Write down all of your ideas & break down your tasks into smaller tasks. Don't try & solve a giant problem all at once without writing down what you're going to do. You may also discover issues earlier.
It doesn't get rid of the issue 100% but it helps a lot. I say this as a dev who has to do a lot of context switching.
For many who experience this regularly, that basically means leaving/finding a new job.
With many employers, it's very difficult to escape being spread thin once you've proven your competence and they lean on you hard as a result.
Write it down to read it & not forget it.
Write it down because the process often helps me better think about the problem & reasons my initial assumptions were wrong. Can't tell you how many times my clever initial idea becomes terrible rather quickly.
Also if it's something that's going to exist over multiple days, writing it down & coming back to it at least a day later is a great way to re-approach the solution & idea.
A meeting to discuss why we're behind schedule.
A meeting to put together a task group to put together a recovery schedule.
A task group meeting to put together the recovery schedule.
A management meeting to review the recovery schedule.
n bounces between management and the TG to revise the recovery schedule.
A meeting with staff to discuss the recovery schedule
A meeting to assign duties towards the goals of the recovery schedule.
And I still can skip those meetings just by telling my manager that I have something quite urgent to do and that I will come back to them later (in case of the 1:1) or read the meeting minutes (in case of the team meeting).
On the other hand we have an "open office" layout here. But I am 99% working from home, so I am "skipping" that as well, mostly.
I have to be careful, though, as I'm aware most of my colleagues don't feel the same way about interruptions.
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 extremely well for me. I lack nothing and am at the absolute cutting edge in every topic I'm pursuing. Of course this is my opinion but it's sufficient to say that I'm happy.
It is sad to see how many people are made uncomfortable by interruption. It's the stuff of life, social life at least, and exactly what makes being human in a dense society so wonderful. I feel it represents a fundamental discomfort with being in situations out of one's control. But, that's the core of life. And for me it's where all the creative energy comes from.
edit: Reflecting on John Carmack and his big monitor. I habitually work in single window terminals with relatively low row counts and big fonts. I seem to be unable to get a benefit from seeing more stuff all at once.
edit2: And in terms of getting into flow state, for me it is always basically instantaneous. The flow is just sitting there under a few seconds of pause. Of course sitting at a computer or phone will cause wandering distraction at times, but if work is in play I can start driving at full speed in what would typically be seen as a horrifically uncomfortable position. Imagine a long distance train with two children jumping on you... If I can see my laptop and the kids at the same time, I'm flowing. I think this might be neurological somehow, due to training or genetics. It's unclear.
A key concept from the book "A Mind for Numbers" is the difference between "focus mode" and "diffuse mode" thinking.
Focus mode is essentially a concentrated flow state and diffuse mode is a relaxed state, open to distraction and creativity.
Both modes are necessary for effective problem solving but my issue is an abundance of distractions which keep most of us stuck in the diffuse state and no time in the focused state.
> And in terms of getting into flow state, for me it is always basically instantaneous. The flow is just sitting there under a few seconds of pause.
Rare, for most people it takes 20 minutes. If I get equally spaced out distracting emails I will spend no time in the flow state at all.
I haven't been in a programming 'flow state' for many years, maybe last in college. It just doesn't happen to me anymore. Programming for me has changed a lot in that time. Most of the typing work is done by an LLM or a contractor/jr. I suppose the opportunity for 'flow' is gone or much less. Additionally, well designed code is easier to reason about and requires less context in most cases.
I think many people are too rigid in their meta-thinking. No, not all programmers fall into flow, not all programmers hate distraction, not all programmers have the "standard" deep/shallow thinking dichotomy. Each of these is probably a spectrum, and are effected by changes based on too many factors to enumerate.
Do what works for you, and read these kind of articles with a skeptical eye. Especially since this article is from "contextkeeper.io" and "Rebuilding the Context" heading is just an ad lmao
Basically you're not a developer but pretend to speak for developers.
I think this may be a variation on the "same" thing. For me, I only look at code or the UI output, or the requirements, or a database query at any one time.
But... I really like if the code is always in the same place, and the output is always in the same place, and I can just look between them if I'm thinking about how and why the code is resulting in the thing it is. But I know where each of those things is at any time, and it might only be a glance away, or an alt-tab away.
(For me, it's 2 27" QHD monitors rather than one big or small monitor.)
Stand up, walk away. Don't engage in a seperate source of context.
Brain dumps short term memory long term memory.
I also do OK with interruptions, and have found a role where I'm not programming 100% of the time, and the subject matter itself -- doing experiments and hardware testing -- doesn't really lend itself to flow anyway. But being able to program means that I don't have to interrupt the programmers every time my requirements change, which can happen on an hourly basis.
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 :)
And compare it to programmers and writers. The non-programmer/non-writer world think programmers "just play on the computer" all day. So I think GP is spot on, non-programmers don't get how interrupting flow is catastrophic to what we do.
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.
Again, it is silly to think that programming is the only profession that requires concentrated thought.
For me there are different tasks and different days. Some days I want uninterrupted flow. But some days I feel more productive by chopping it up with a few meetings and some office trash talk. A laugh every now and then, teasing a co-worker for screaming at his code - it gives energy to me. Talking through a problem or pausing for a while in a meeting and then returning to it - that can be a great way to see new things.
Now don't get me wrong here, I am not saying meetings and distractions are good for everybody. But it's just that for me at least the picture is not as clear. Some days I feel I would have been more productive if I had had some meetings to distract me.
Am I really the only one to feel this way?
I usually split my work-week in office and remote work. When I am in office I plan for having meetings with stakeholders, architecture/mob coding with my coworkers, etc.
But when I am at home I can focus on the projects I need to execute on, fairly uninterrupted.
It is not perfect and isn't quite as black and white as it may seem, and it is difficult to communicate that this is how you're working, but just doing it in my org has been pretty good.
I probably have one of the more outreaching roles, some mix between an architect and devrel with a sprinkle of actual execution, so even if it is an outreach kind of role it actually works pretty well.
Would you use IRC? That's all slack really is.
The expectation that you always have to be online is also unreasonable. But if you're still required to put out a show for an unreasonable employer, you can always set it to "Busy" and disable notifications. This also signals to people that you won't reply immediately.
Of course some co-workers will want to "chat" when you answer them, but this is where you must set limits and say you'll only have time for chat outside your busy hours. This is normally perfectly acceptable IME.
My current company has _all_ of their communication on Slack, the only emails I get are meeting invitations and status emails from automated systems that haven't been integrated to Slack yet.
I can easily click to pause notifications on Slack if I don't want to get interrupted - or I can just close it and read the backlog when I have time to focus on it.
But yeah, sometimes find it almost violating in a way, especially when its that typical PM line "hey did you read my email?" (that was literally sent 10 seconds ago).
It just feels like someone coming over to my desk and pushing, monitors, scopes, everything off and smashing it on the floor, then walking off.
Now I have both unrealistic deadline AND a mess to clean up.
I don't know where I'm going with this comment. Just venting I guess :)
So now my work is interrupted every 20 minutes, at first the timer was annoying but after several months I got used to it completely and I don’t think it affects my productivity. And actually I wish I could do it from the begining so I wouldn’t have the health issues at all.
However my interruption is short and during it I was uaually just thinking about my work while stretching my body, so it is no compare to hard context switches like being dragged to a conversation.
I suspect the physical exercise is key to your effectiveness there. There’s a big difference between a pause for a stretch and a pause for a message about an entirely different workstream.
Not all interruptions are created equal.
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.
* Interruptions affect me just as the article describes. I have my suspicions about those who claim to be unaffected.
* Talent may indeed play a role, but what you probably aren’t seeing behind the apparent talent is the self-driven obsession. Behind those 5 minutes is a mountain of self-obtained experience. As I understand it, even Mozart was no different…
Expanding on that slightly, when considering if I was special compared to the average individual: I self-taught myself from the age of 8, so yeah, probably something different about me that enabled that. On the other hand, I self-taught myself from the age of 8, spending nearly every free moment with computers. How messed up would it be if I didn’t end up with a massive lead over those just starting out?
Of course it was effortless in 5 minutes: I’d already put in more effort by that point than many would in a lifetime…
I guess the moral is, try to consider what it might be that you aren’t seeing.
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.
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.
One way to "survive" is to logically separate the work into two different workflows. The "interrupt" workflow is where you are constantly doing trivial things, odd bits of admin, forms, chatting, and interacting in meetings. The trick is to deliberately cram as much of your interrupt-related work into the same half-day segment. The other workflow, the "deep work" workflow is where you do the design and complex coding work. You allocate such periods in 3 hour segments.
For example you could do the morning in the interrupt workflow, the first part of the afternoon in the deep work workflow, and then end the day with interruptions.
It really works - at least for me.
Whether it’s more or less effective than interrupted, “zoned” work is going to depend on the individual and the circumstances, but it is certainly a way to work.
Is it hard? Yes, very, but it’s just a matter of discipline and determination, in my opinion.
I kinda don't believe the people who say they 100% have this job, all the time - but you also don't know beforehand when you need your interrupt-free time. Some days are just cursed and you get nothing done, even if they only interrupted you 3 times, but it was the important 15min block. And I've had those jobs as well. If someone (different people) interrupts you every 15min, when the day is cluttered up with 3 meetings anyway... I think it scales exponentially.
Before the era of mandatory 2FA the first thing I did when I arrived at the office was turn off my phone and lock it away.
- Setting up boilerplate code
- Configuring my IDE
- Configuring special browsers (for web development) with no addons or tweaks done so it appears like an average person is using the browser
- Configuring the OS
- Separating work from play. Keeping separate machines strictly for programming
- Tests
- Reading best practice material
- Researching if other people have written the exact same thing as you and uploaded it to GitHub (or don't repeat what other's have coded already).
All that can be set-and-forget but I periodically have to do it all again because requirements change, or I get a new machine or I simply want to re-configure my development environment for minor (or major) gains in productivity.
I have solved this in multiple ways, getting into work before others (not that early but just a few hours before our first planned meetings). Second, reaching an agreement with the team to push standup and such to after lunch. This basically gives me the entire morning free to focus and sets me off to a great start.
That is for the days I am actually in office =D
For interruptions (meetings or discussion) while coding I'll write a sentence or two directly in the file I'm working in - not comments, actual text. I'll explain what I'm doing and what the next step is, then close the IDE. When I come back nothing compiles and I'm forced to delete the text I added, which gives me a chance to read it and refresh my brain of where I left off. It's been one of the best approaches I've adopted over the past few years.
But professional software development is much more than just programming, just as sales is much more than signing contracts. Sure, signing contracts is what every sale agent looks for, but their actual job is getting to sign a contract. And writing correct code is the goal of every software developer, but his true job is finding out what such code is supposed to do.
Writing one more CRUD information system is just a part of the whole software development trade.
In each desktop I have a Chrome Window open with required tabs (Jira, github other required tools).
One Emacs Frame
On iTerm2 window.
I use Rectangle to quickly arranged windows. (I wish a tool existed that can recreate the desktops and all the windows exactly , after a reboot)
Ofcourse, upon a reboot, need to set this all up again :-(
Atleast Chrome remembers the windows/tabs and which desktops they belong to... That helps a lot.
Now I just expect my IDEs, be it VS, VSCode, Eclipse to do a lot of heavy lifting for me.
I wonder, though, whether I was more disciplined and kept a lot more context in my head back in those days. I'm also a lot older so I really don't want to go back to the old days.
Now java developers can't possibly write an hello world in less than 60 classes and interfaces. Without an ide to keep track of the com.path.that.i.made.up.for.my.package.because.it.has.to.be.at.least.three.pages.long they'd never be able to code like that.
There's my "session" that tells me which files I've been editing and
> git diff
what I've changed so far. Don't need an IDE for that.
This is so true. It's why I naturally feel dumber when I switch from a desktop computer to a laptop computer, and very stupid when working on a smartphone. I need my multiple tabs, big windows of text, etc. to get things done intelligently.
Surely it takes time to collect your thoughts after conversation, but in my experience that is like 1-5 minutes. It is usually worth it.
I really think there should be more communication at work, not less.
For me I think flow state is more about how interested I am about the task than how much time I have. And frankly many tasks at work aren't that interesting so even if I have half of day uninterrupted time, I don't get into flow state.
The amount of challenge needs to be challenging enough for your skill level, not too easy (boring) or not too hard (can't flow because you get stuck).
And (at least for me) I need to have the knowledge that I can focus on the task and not be interrupted. If I have a meeting in 30 minutes, there's exactly zero chance I'll enter a flow state because I'm expecting the meeting to start. And if I accidentally enter flow, I either work past the meeting or my flow is interrupted by a calendar alarm.
Interruptions during flow state are really damaging (for me) because I'm juggling a huge amount of context and data in my head that's not yet exported to any external medium. If I get interrupted a large-ish segment of that data will disappear and I need to spend time gathering it after the interruption has passed.
Complexity values: White 1. Red 5. Blue 10. Grey 20.
When you want to ask a question of someone who looks deep in flow, just lay the appropriate chip on their desk. They can glance at it and balance the complexity versus their mental/work state and decide to either engage at once or defer it. Maybe mumble an ETA.
People will have to use the various chip values wisely if they want to be taken seriously.
I think having meetings on Friday might be better. You sprint Mon-Thu and sync up on Fridays.