January 22, 2013 at 22:18Never distract a programmer
In many companies, programmers are prohibited from working with headphones or distracting them on small issues. Perhaps the reason lies in the poor awareness of managers and other employees how harmful it is to do so.
Chris Parnin of the Georgia Institute of Technology decided to fill this shortcoming and published an extremely rich article with links to various studies on this topic.
To begin with, a few facts that apply to all intellectual workers. A task that was interrupted during execution takes twice as much time and contains twice as many errors as the same task that was performed without interruption ( Czerwinski: 04 ). Office employees are distracted by 57% of the tasks ( Mark: 05) Surveys suggest that an employee needs an average of 15 minutes to return to normal after being distracted ( vanSolingen: 98 ).
Chris Parnin conducted his own extensive research specifically among programmers (pdf). We analyzed about 10,000 working sessions in Eclipse and Visual Studio from 414 developers. Here's what happened:
• It takes a programmer 10 to 15 minutes to start writing code after resuming work.
• The programmer usually succeeds in only one 2-hour working session without distractions during the working day.
• In most cases, after resuming work, the programmer scrolls the project in certain areas to restore the context.
• Programmers insert special compilation errors as “reminders”.
• The source code diff serves as the last chance to recover events, but can be cumbersome for this task.
Chris Parnin and his colleagues studied the worst-case areas for distracting a programmer. Studies with measurements of the diameter of the pupils have shown that interruption of work during the period of maximum memory load is most harmful. In this case, the programmer needs at least 7 minutes to switch from the state of maximum memory activity to the state of minimum activity. By extrapolating these results to the working sessions of programmers, Parnin found that it was worst to distract the programmer during the following tasks:
Chris Parnin in his blog describes some of the features of the human memory and publishes preliminary results of functional magnetic resonance imaging of programmers during work.
Chris Parnin of the Georgia Institute of Technology decided to fill this shortcoming and published an extremely rich article with links to various studies on this topic.
To begin with, a few facts that apply to all intellectual workers. A task that was interrupted during execution takes twice as much time and contains twice as many errors as the same task that was performed without interruption ( Czerwinski: 04 ). Office employees are distracted by 57% of the tasks ( Mark: 05) Surveys suggest that an employee needs an average of 15 minutes to return to normal after being distracted ( vanSolingen: 98 ).
Chris Parnin conducted his own extensive research specifically among programmers (pdf). We analyzed about 10,000 working sessions in Eclipse and Visual Studio from 414 developers. Here's what happened:
• It takes a programmer 10 to 15 minutes to start writing code after resuming work.
• The programmer usually succeeds in only one 2-hour working session without distractions during the working day.
• In most cases, after resuming work, the programmer scrolls the project in certain areas to restore the context.
• Programmers insert special compilation errors as “reminders”.
• The source code diff serves as the last chance to recover events, but can be cumbersome for this task.
Chris Parnin and his colleagues studied the worst-case areas for distracting a programmer. Studies with measurements of the diameter of the pupils have shown that interruption of work during the period of maximum memory load is most harmful. In this case, the programmer needs at least 7 minutes to switch from the state of maximum memory activity to the state of minimum activity. By extrapolating these results to the working sessions of programmers, Parnin found that it was worst to distract the programmer during the following tasks:
- During code changes, especially during simultaneous code changes in several places.
- Activity on navigation and search.
- Understanding the flow of data and the execution order of instructions in the code.
- The IDE window is out of focus.
Chris Parnin in his blog describes some of the features of the human memory and publishes preliminary results of functional magnetic resonance imaging of programmers during work.