2 ms·
The truly astoundingly productive engineers I've worked with have been masters of context-switching and gaining expertise in multiple domains. I believe the lat
by majormajor 5y ago
The truly astoundingly productive engineers I've worked with have been masters of context-switching and gaining expertise in multiple domains. I believe the latter comes from the first: if you can switch domains quickly, you can more rapidly put in more hours of useful experience in multiple domains.
So I largely agree with the OP here: you can either use this as an excuse - "I'm just not that good at context switching, so it's out of my control, if only my manger understood!" - or you can take it as a growth opportunity and decide to try to get better at it. For me, that's looked like a lot more note-taking (I can use this to "reload" my previous context later) and a lot of practice at discipline at just getting back to work even if it means I have to duplicate some steps from before.
The note-taking, it's turned out, has also helped massively, since it makes it easier to bring other people up to speed on what I learned and all the nuances of it.
But obviously this is a work in progress, since I'm here on HN instead of immediately jumping back in to the previous context I had before getting lunch. ;)
- ftkftk 5y agoAdditionally note taking helps (me at least, YMMV) with effectively flushing your buffer and allowing you to switch into the previous problem very quickly. There is almost an anxiety of holding on to/not forgetting some kind of information from a meeting or conversation that immediately vanishes as soon as I commit the thoughts to a medium other than my brain (paper or electronic).
- username90 5y agoI've found the reverse, it is easy to context switch between tasks you have practiced a lot with. But you still need to practice a lot at doing them, making someone now and then do a task they aren't good at and evaluating them at that task will absolutely ruin their productivity. In this case we are talking about meetings for software engineers who haven't been managers.