As programmers, we always talk about "context switching" and "time to get into the flow", but somehow I've never once thought about it in terms of meetings.
Meetings are inevitable. They are the key vehicle in which we transfer out thoughts to one another and try to "get on the same page". Quite often, it works.
However, I've never really given myself time to let it sit in my head, and let it sink in for a while before engaging in other things, like walking away, like going to another meeting.
This is a travesty, as you've just spent an hour (or more) getting into the flow of this context, in which you discussed the subject at length with other people, to share ideas and get excited at possibilities, and then you don't give yourself time to digest them.
Everything is an experience, therefore a meeting is also an experience. Give yourself some time to absorb what you have just experienced, whether you like it or not (I hate meetings as an event, but enjoy what they provide me in terms of new knowledge, whether it be of the project or something else).
If you don't let yourself digest the previous meeting, and engage in another activity too quickly, I would argue that it is the same as context switching, where you lose track of both activities and have to take time to dive back into each project.
I found that after some meetings, I often get quite excited to try out some things, or sketch out some ideas regarding the meeting I just had, before engaging in what I was previously working on again. I realized that I never give myself time for that (because calendar slots are packed up back to back), and as a result slide slowly into a downward spiral of trying to catch up with more and more things.
Therefore, I would recommend (to myself, and perhaps the readers too) half an hour to digest - write notes, do some sketches pertaining to the meeting you just had, so as to put everything down on paper and "exit" that context properly.
If the exciting subject involves code, or you anticipate writing some after a scheduled meeting, I would recommend giving leaving up to 2 hours to try it out. I had a very observant tutor once tell me "if you've been thinking about it for a while, just do it, get it out of your system". This is exactly that, coding up a quick prototype is a form of context switching, or a "note taking" process that takes the form of code instead of text.
be aware that your setup is important too so that you don't spend 10 minutes starting up your code editor.
Switching into the right context for every meeting is also something I would recommend myself do, although I might not want to take 30 minutes for that. I currently recommend 30 minutes in total, 15 to switch out of whatever work you were doing, 15 to prepare for the upcoming meeting.
if you are a programmer, you would hate to have your work time, your flow, get cut off by another context, requiring you to exit your programming context and dive into another one (for your meeting).
If the process of getting out of and into the flow takes half an hour, then you would have lost one hour for every meeting (half hour to get out, half an hour to get back in) you schedule. This only applies to your coding work. You have not even engaged in the context of the meeting (which will most likely be a separate project).
If you tally it up, every meeting, taking into account entering and exit times, will take 2 extra hours of your day. So if you have four meetings a day, you have just spent the equivalent of a full workday switching contexts. That's a horribly inefficient way to work.
4 meetings == 8 hours of context switching