I see so much of this arguing against being interrupted, or context switching. I suffer from it, most of us do, but I think everyone's trying to solve the wrong problem.
The problem isn't that we get interrupted and our concentration suffers, it's that we keep trying not to be interrupted. Good developers are people who knit things together. The myth of the savant coder who just cranks out beautiful amazing stuff has to die. What makes a great developer are soft skills, and gluing together other code, not cranking on something for hours alone. Just like every other industry, you have to deal with other human beings, email, and the rest of life. We don't NEED to be cranking out code for hours on end, we need to integrate and interact with other people.
The problem isn't that we get interrupted and
our concentration suffers, it's that we keep
trying not to be interrupted.
For a programmer, frequent interruptions are a major problem. Interruptions break a person out of the mindset required in order to solve problems. This is why managing interactions within an organization is one of the primary foci of project management.
What makes a great developer are soft skills,
and gluing together other code, not cranking
on something for hours alone.
Soft skills are certainly beneficial in a team. But what "makes a great developer" are not soft skills. What makes a great developer is providing solutions within the constraints and expectations of the organization (time, functionality, cost, etc.) for the problem at hand.
I think there is a time and a place for both modes (and it also depends on personality). What's wrong with private exploration / development after a period of research on the problem?
It depends, of course, and I assume you're not drawing a black and white line, but I agree.
For many years in my professional career, I was getting annoyed at interruptions and complaining. I've done intentionally anti-social things to prevent getting interrupted. (They rarely, if ever, actually worked.)
But I also watch programmers (including myself) code like crazy and resist interruptions solving problems they don't actually have, and if they'd stop to check in, they'd find out the cost of the context switch is trivial compared to the cost of losing hours, days, or even weeks to coding the wrong thing.
As programmers, we'd do well to learn how to be the ones doing the interrupting rather than wait till it comes at us and then complain about it. Seek out more consensus on what we're coding before we start typing away, plan for changes in requirements before building things that can't easily change, report our status to managers often and before they come asking, establish conventions and willingly work with others, etc.
The problem isn't that we get interrupted and our concentration suffers, it's that we keep trying not to be interrupted. Good developers are people who knit things together. The myth of the savant coder who just cranks out beautiful amazing stuff has to die. What makes a great developer are soft skills, and gluing together other code, not cranking on something for hours alone. Just like every other industry, you have to deal with other human beings, email, and the rest of life. We don't NEED to be cranking out code for hours on end, we need to integrate and interact with other people.