4 ms·
The key concept here is 'context switching' and how fast you can do it. Multitasking is considered bad because people switch contexts and lose bits of informati
by rheide 14y ago
The key concept here is 'context switching' and how fast you can do it. Multitasking is considered bad because people switch contexts and lose bits of information in the process. Some people can retain their context longer, or have a workflow in which they can easily rebuild their context based on hints (notes, to-do lists, mental mind-map).
In my case, whenever I'm working on some complicated bit of code and someone interrupts me to ask a question, or to go to their desk, I have no problem doing it because I am already immersed in the task and don't need to offload it anywhere. If I realize that the talk is going to take longer than I though, or if it is about something completely different from what I'm working on, then I might scribble myself a quick note to get my mind back in the state that I need to be in.
Or another example: assisting two different people with two different programming problems via chat, while myself working on a third one, but all in the same codebase. There's not a lot of context switching required because we're all sharing the same code and are all in the same mindset. My productivity in terms of my own code does decrease using this method, but it's still more productive than taking the time to go and sit with each individual person to go through their problems one by one.
tl;dr: multitasking is impractical in some situations, but there are situations where you can benefit from it. I think it's a useful skill to be able to create those kind of situations for yourself (and your team).