Interruptions - Can They Make You a Better Coder?

I was recently talking with an engineer at a software development conference and he was saying how he is interrupted by "walk up" requests every 15 to 30 minutes or so in his current project. I'm going to relate here what I mentioned to him and it may be something with which many will vigorously disagree. Is it at all possible that frequent interruptions can - in some ways - hone development skills and result in better software?

For one thing, 15-30 minutes (let's call it a micro-task) can be a good amount of time to write one or two good unit tests. Because one would want to ensure that one's train of thought can be easily picked up when returning to coding, such a situation may strongly encourage test-first development. Coming back to create code that satisfies a test written before a disturbance is much easier than the other way around, for sure.

For another thing, frequent interruptions may force one to think of how to progress efforts even while away for things like meetings, etc. The result? Frequent test runs, frequent code pushes, frequent CI... basically, one may be away from one's desk, but the integration continues. More integration = quicker issue detection = lower costs of remediation.

Finally, from a pure design standpoint - knowing that one may only get 30 minutes to code in between other obligations would surely cause many people to think in terms of smaller, more discrete units of functionality. Simpler, smaller components are the acme of most design philosophies, so anything that encourages this kind of thinking has to be seen as at least somewhat positive.

It's a contrarian point of view, admittedly. I could certainly be accused of seeing the glass as 10% full rather than 90% empty. Thoughts welcome, as always!