What happens to the "velocity" of a team that gets interrupted? It's not hard to figure out.
Minimizing interruptions maximizes the work by a non-blocked programmer. Of course, a blocked programmer sometimes doesn't unblock herself/himself. So there are no silver bullet solutions. Leaving people to flail for months, is no good. But neither is bugging them every five minutes.
But if you are the sort of person who emails someone then walks over to their desk to tell them that you emailed them, then you need to read this even more than most people.
I found this over here, it's by Jason Heeris, and is licensed with a CC-type license.
Minimizing interruptions maximizes the work by a non-blocked programmer. Of course, a blocked programmer sometimes doesn't unblock herself/himself. So there are no silver bullet solutions. Leaving people to flail for months, is no good. But neither is bugging them every five minutes.
But if you are the sort of person who emails someone then walks over to their desk to tell them that you emailed them, then you need to read this even more than most people.
I found this over here, it's by Jason Heeris, and is licensed with a CC-type license.
Doesn't this apply beyond cubicle interruptions to any time in a programming language where the developer has to switch (mental transaction cost) from thinking about "what" should be done to "how" it should be done (drop down to algorithm level)?
ReplyDeleteI see too many Delphi "solutions" that consist of "Well just ." When a language unnecessarily forces you to drop into algorithm formulation it's going to incur a task switching cost and take one out of high-level thought just like in this cartoon here. Hence these aren't really acceptable solutions.
http://en.wikipedia.org/wiki/Task_switching_%28psychology%29
This comment has been removed by a blog administrator.
ReplyDelete