My new job is much more on the maker's schedule than the manager's schedule. Work at W3C basically consisted of preparing for and participating in several meetings a day with people all over the planet. Now I'm mostly coding away in my cube, and the little reminder icon at the top of my screen is not enough to break me out of it. (I'm trained to be interrupted by the buzz of my mobile phone, but sync between the enterprise calendar and android unreliable. Sigh.) Having people physically grab me means I don't miss the meeting, but it doesn't give me a chance to properly context switch.
I don't use a laptop (mostly by choice) so access to the Web depends on either pre-filling a paper cache (printing stuff out) or using the pc/projector in the meeting room. The latter is often more disruptive to the meeting than it's worth.
Fortunately, somebody else had printed the web page that I had prepared for today's meeting. And the group leader uses a laptop, so we had two copies.
Part of my preparation for the meeting was to question whether we needed it at all, having recently read Tantek's thoughts on meetings. I thought the technical issues were pretty straightforward and we should just let the developer get on with it and deal with problems as they came up. But it turns out that some of my understanding of the requirements was wrong, and even in the parts that were right, brainstorming led to solutions that were better than the approach I expected development to take.
Meeting discipline is important. My approach to the risks was finely honed over a decade of remote work, but now that we can get together in the same room without getting on airplanes, I'm learning it all over again.