He did mention trying most of the standard techniques for that. From an individual perspective, I think that's a reasonably well-explored space.
If the problem statement is "interruptions cause me to be unproductive for some time after one occurs", there's a lot of value to working on cutting down "some time" as well as simply trying to avoid interruptions. Some interruptions are unavoidable, as well: bathroom, RSI-induced rest breaks, loud noises from outside.
I moved away from programming a couple years ago, and I've found that there are non-programming tasks that require the same amount of "load-up" that development does. Writing comes to mind. Programming is unique, though, because there are far more digital artifacts you have to navigate while you do it. That makes these sorts of techniques particularly interesting. How do we take advantage of the fact that there are so many markers in the code, instead of making their complexing the problem?
Sadly, this is becoming less and less of a viable option, if you wish to participate in the workforce. Open offices where your visibility is valued more than your performance, the expectation to respond immediately to chat and email, and the rise of the phone call all create the potential for interruptions.
