If you read the details of that paper, they are really not relevant to what I mean.
Let me be more specific.
So when I talk about the asynchronous nature twitter/texting/facebook what I mean is that there are people now (usually young people) who are comfortable with carrying out multiple conversations with different people/groups of people that occur at different rates of time. I am not suggesting that someone who is frequently using twitter/texting/facebook while at work would be more productive than someone who doesn't, but that this experience helps them be able to manage multiple workflows better.
From my own experience, when I talk about multi-tasking as far as it relates to a developer anyway, let me give you an example of something that I can do all the time: I get assigned a bug, I look at the bug board to see what other similar or related bugs there might be, and I assign them to me. Usually this means that some or all of the steps to reproduce the bug are the same, so that if I have to step into the debugger to identify the problem I can set breakpoints in places that should help me figure out more than one bug at a time. In the middle of this, a co-worker sends me an instant message asking for something. I don't immediately know the answer, but I know the general area of the code to look for the answer, so I dig around for a few minutes and then either reply with what was asked or a "I don't know but xyz worked with that code and might be able to help you better." Then I go back to my debugging. I find the bug, or I find a clue that will lead me to the bug, and I write some code, deploy it on the test server, and start a test, which I know will take 20 minutes or so. In the meantime I might reply to some e-mail, do some code review to see what might be refactored to be more readable and/or maintainable, or work on another set of bugs. Then when the earlier test completes I go back to check on it. I might not immediately go back to it after 20 minutes depending on where I am with my other tasks, I would probably find a good natural stopping point first, but the point is at the end of the day I am able to finish all these tasks much faster than if I did them one at a time sequentially.
I don't think what I just described takes particular mental prowess and most of the younger people at my work (and a few of the older ones too) do the same as well. But there are enough older workers who just get hopelessly lost if you ask them to do more than one thing at a time, whereas if I ask a younger co-worker to do the same thing they have no problems, that I have noticed it.
Let me be more specific.
So when I talk about the asynchronous nature twitter/texting/facebook what I mean is that there are people now (usually young people) who are comfortable with carrying out multiple conversations with different people/groups of people that occur at different rates of time. I am not suggesting that someone who is frequently using twitter/texting/facebook while at work would be more productive than someone who doesn't, but that this experience helps them be able to manage multiple workflows better.
From my own experience, when I talk about multi-tasking as far as it relates to a developer anyway, let me give you an example of something that I can do all the time: I get assigned a bug, I look at the bug board to see what other similar or related bugs there might be, and I assign them to me. Usually this means that some or all of the steps to reproduce the bug are the same, so that if I have to step into the debugger to identify the problem I can set breakpoints in places that should help me figure out more than one bug at a time. In the middle of this, a co-worker sends me an instant message asking for something. I don't immediately know the answer, but I know the general area of the code to look for the answer, so I dig around for a few minutes and then either reply with what was asked or a "I don't know but xyz worked with that code and might be able to help you better." Then I go back to my debugging. I find the bug, or I find a clue that will lead me to the bug, and I write some code, deploy it on the test server, and start a test, which I know will take 20 minutes or so. In the meantime I might reply to some e-mail, do some code review to see what might be refactored to be more readable and/or maintainable, or work on another set of bugs. Then when the earlier test completes I go back to check on it. I might not immediately go back to it after 20 minutes depending on where I am with my other tasks, I would probably find a good natural stopping point first, but the point is at the end of the day I am able to finish all these tasks much faster than if I did them one at a time sequentially.
I don't think what I just described takes particular mental prowess and most of the younger people at my work (and a few of the older ones too) do the same as well. But there are enough older workers who just get hopelessly lost if you ask them to do more than one thing at a time, whereas if I ask a younger co-worker to do the same thing they have no problems, that I have noticed it.