4 ms·

Science says you're wrong and not only wrong but this mistaken belief some of these people hold that they can multitask or be interrupted without significant lo

Science says you're wrong and not only wrong but this mistaken belief some of these people hold that they can multitask or be interrupted without significant loss of productivity is actually an admission that they are the worst of multitaskers. [1] The mind is single-core. There's no black lotus you can huff or secret technique to master to make it more than one core. And the inertia returning to its task is significant. [1] https://www.npr.org/sections/health-shots/2013/01/24/170160105/if-you-think-youre-good-at-multitasking-you-probably-arent?t=1573504082179 https://www.npr.org/sections/health-shots/2013/01/24/1701601...

tj-teej 7y ago
Sure, but most engineers are working for a business and most businesses don't have perfect processes. I think we can say (1) engineering productivity is severely impeded by interruptions and (2) it doesn't hurt to work on skills to help yourself get less impacted by disruptions. You're right there's no secret technique, but documenting your work and thoughts, keeping TODO lists, breaking down large work items into small chunks can all help distractions not ruin your day. But, these are effectively "hacks" and the only way to ensure highest possible productivity is to have processes which prevent engineers from being interrupted
war1025 7y ago
It all depends on what you are optimizing for. You can do a lot of work in parallel if you have the correct coroutine architecture. That involves encapsulating information in a way that you can put it down and pick it back up efficiently. An upside of developing this skill is that if you become adept at storing the relevant information, you will be better at handing that information off to another person. Further, absolute productivity at a single task is rarely the most important thing. If it is, then you've reduced yourself to a cog or a worker bee. Taking responsibility for the direction of your work means accepting that you need to be part of the decision-making process, which will lower your absolute productivity, but (done well) will increase your overall effectiveness.
shados 7y ago
but if they don't get interrupted, what's the cost of it vs the cost of them actually being interrupted? Did someone else spend a day trying to solve a problem they could have solved in minutes by interrupting the lone genius?
- yoz-y 7y ago
  This. If you have one person holding everything in their had blocking other engineers who can’t get around then you are just wasting resources.
McWobbleston 7y ago
I think you've missed their point. Those engineers are aware of the cost of context switching, and because they plan accordingly they're able to get more done than those who don't
- mikeg8 7y ago
  Awareness and planning cannot compensate for the fact that lost productivity is lost productivity.
  - throwawayjava 7y ago
    I tend to agree with you, but I'm compelled by the argument that organizing your productive time in a way that minimizes the impact of context switches will make your programs much better anyways. There might be a good reason why code developed under extreme focus also tends to be inscrutable to others.
    - splittingTimes 7y ago
      > There might be a good reason why code developed under extreme focus also tends to be inscrutable to others. Wow. I have never thought about it this way. That's quite a profound insight. Thanks.
      - techopoly 7y ago
        On the other hand, extreme focus can and should be used to make a complex algorithm simple. It all depends on the programmer's competency to begin with. If he/she doesn't care or know how to make code readable, it never will be readable despite their level of concentration. The corollary is true as well. I, as well as many others I imagine, have had to fix and maintain dumpster fires of spaghetti code developed under the standard distraction-filled modern business day. Distraction doesn't beget good code; instead, a good programmer learns how to be as productive as they can despite the dysfunction of a typical modern business.
kqr 7y ago
I'm writing this under the influence of Deming, but could you be confusing individual productivity with productivity for the whole department, company, country, world? Any engineer is only as productive as the system she works in, and a system that eschews communication for long periods of solitary work is not, generally, a productive system. I vaguely remember reading about an old study from one of those telephone companies in the '60s or so about engineering productivity, and they found that the single thing that set the "best" engineers apart from their peers was in how much more they communicated. I haven't been able to find this study, but if someone knows what I'm talking about, please shoot me a link or something.
- tonyarkles 7y ago
  Was it Hamming's talk? https://www.cs.virginia.edu/~robins/YouAndYourResearch.html https://www.cs.virginia.edu/~robins/YouAndYourResearch.html
  - kqr 7y ago
    Might have been! Haven't taken the time to read it yet but it looks very interesting. Thank you irregardless!
meesles 7y ago
Just to attempt to explain why the responses to this comment seem all over the place: 'Productivity' is subjective to the business and position. In your 2-person startup, productivity might be shipping CRUD functionality in triplicate and setting up the bones for a larger application. In an enterprise, productivity can simply be not _reducing_ productivity while doing something. A develop and a manager being productive also look very different. I don't think your point and GP's point are mutually exclusive.

tj-teej 7y ago

Sure, but most engineers are working for a business and most businesses don't have perfect processes. I think we can say (1) engineering productivity is severely impeded by interruptions and (2) it doesn't hurt to work on skills to help yourself get less impacted by disruptions. You're right there's no secret technique, but documenting your work and thoughts, keeping TODO lists, breaking down large work items into small chunks can all help distractions not ruin your day. But, these are effectively "hacks" and the only way to ensure highest possible productivity is to have processes which prevent engineers from being interrupted

war1025 7y ago

It all depends on what you are optimizing for. You can do a lot of work in parallel if you have the correct coroutine architecture. That involves encapsulating information in a way that you can put it down and pick it back up efficiently. An upside of developing this skill is that if you become adept at storing the relevant information, you will be better at handing that information off to another person. Further, absolute productivity at a single task is rarely the most important thing. If it is, then you've reduced yourself to a cog or a worker bee. Taking responsibility for the direction of your work means accepting that you need to be part of the decision-making process, which will lower your absolute productivity, but (done well) will increase your overall effectiveness.

shados 7y ago

but if they don't get interrupted, what's the cost of it vs the cost of them actually being interrupted? Did someone else spend a day trying to solve a problem they could have solved in minutes by interrupting the lone genius?

yoz-y 7y ago
This. If you have one person holding everything in their had blocking other engineers who can’t get around then you are just wasting resources.

McWobbleston 7y ago

I think you've missed their point. Those engineers are aware of the cost of context switching, and because they plan accordingly they're able to get more done than those who don't

mikeg8 7y ago
Awareness and planning cannot compensate for the fact that lost productivity is lost productivity.
- throwawayjava 7y ago
  I tend to agree with you, but I'm compelled by the argument that organizing your productive time in a way that minimizes the impact of context switches will make your programs much better anyways. There might be a good reason why code developed under extreme focus also tends to be inscrutable to others.
  - splittingTimes 7y ago
    > There might be a good reason why code developed under extreme focus also tends to be inscrutable to others. Wow. I have never thought about it this way. That's quite a profound insight. Thanks.
    - techopoly 7y ago
      On the other hand, extreme focus can and should be used to make a complex algorithm simple. It all depends on the programmer's competency to begin with. If he/she doesn't care or know how to make code readable, it never will be readable despite their level of concentration. The corollary is true as well. I, as well as many others I imagine, have had to fix and maintain dumpster fires of spaghetti code developed under the standard distraction-filled modern business day. Distraction doesn't beget good code; instead, a good programmer learns how to be as productive as they can despite the dysfunction of a typical modern business.

kqr 7y ago

I'm writing this under the influence of Deming, but could you be confusing individual productivity with productivity for the whole department, company, country, world? Any engineer is only as productive as the system she works in, and a system that eschews communication for long periods of solitary work is not, generally, a productive system. I vaguely remember reading about an old study from one of those telephone companies in the '60s or so about engineering productivity, and they found that the single thing that set the "best" engineers apart from their peers was in how much more they communicated. I haven't been able to find this study, but if someone knows what I'm talking about, please shoot me a link or something.

tonyarkles 7y ago
Was it Hamming's talk? https://www.cs.virginia.edu/~robins/YouAndYourResearch.html https://www.cs.virginia.edu/~robins/YouAndYourResearch.html
- kqr 7y ago
  Might have been! Haven't taken the time to read it yet but it looks very interesting. Thank you irregardless!

meesles 7y ago

Just to attempt to explain why the responses to this comment seem all over the place: 'Productivity' is subjective to the business and position. In your 2-person startup, productivity might be shipping CRUD functionality in triplicate and setting up the bones for a larger application. In an enterprise, productivity can simply be not _reducing_ productivity while doing something. A develop and a manager being productive also look very different. I don't think your point and GP's point are mutually exclusive.