Also in my 50s. I can relate :-). The first thing I do with messaging clients is turn off the notifications. On the web client in slack there is an indicator in the browser tab when messages have been sent and when there are messages directly for you (I haven't actually tried the desktop client...)
Next, I have a set routine where I check the visual notification. Generally speaking, when I am running my tests, I'll glance at the notifier. I TDD most of the time, so usually that means glancing at the notifier every 2-5 minutes. If I need to put my head down, I start a pomodoro timer (25 minutes) and I'll check the notifier when that goes off.
I don't always check the message when my notification goes. I keep it as a choice. If I need to keep my head down, then I just mentally make a note that I should check the notification when I get the chance. I don't know if it makes sense, but I use the same part of my mental process that I use for making notes of anything -- oh, I should fix that test, I should refactor that function, etc, etc. It's the stuff in the back of my mind that I've chosen to do later. If I get overloaded (as I tend to do now that I'm older) I put it in my TODO list (check slack). Then I can forget about it.
Basically that gives me a response time 2-3 minutes on average if I'm just cranking out code TDD style or on average about 15 minutes if I'm doing something more deep. Since I work remotely, having that "presence" is really important. Not disappearing for hours on end makes people feel more comfortable that you are actually there.
However, the last thing I do is if I really need time to myself, I'll send a quick message on slack saying, "I need to wrestle with X. I'll be away from slack for about 1-2 hours. Is there anything anybody needs before I do that?"
I guess one last thing. At one point in my career, I quit my programming job, moved to Japan and taught English for 5 years. Then I went back to programming. During the 5 years I taught English, I still did my own side projects, however at that time I didn't have any free time to really devote to programming. It had to be 10 minutes here and 10 minutes there. I worked hard at developing a technique where I could get in and out of the zone very quickly.
The 2 main pieces of advice I can give is, if you have tests, to always leave yourself a failing test when you switch contexts. If you have good test coverage, this is relatively easily done by simply sketching in some functionality and leaving the tests broken. When you come back, you can see all the broken tests and it will show you what your sketch was doing. Normally it takes me about 2-3 minutes to get back into the flow.
Second, make TODO lists. I use org mode in emacs (and actually moved from vim to emacs with evil mode simply to have a better org mode client!) However, you can use anything, really (markdown is fine too). Just get into the habit of dumping your though process into an editing buffer (I need to do X and then Y and then Z). I tend to try to break up my programming where I'll do 5-10 minutes of coding followed by 1-2 minutes of reflection -- so I force myself to stop and take stock of what I'm doing. This is where I tend to write my TODOs. If I'm doing pomodoros, then usually I'll write TODOs during the 5 minute "rest" period. Not only does it help me get into the flow faster, but I've found that the enforced reflection period helps me jump out of local maxima and save time (i.e. if you get going in one direction and miss a better opportunity). Since I'm 9 timezones away from my colleagues if I'm working while they are sleeping, I can often hand over my work to my colleague and they can finish it off while I sleep. It takes some practice communicating, but if you have a willing partner it's pretty fun tag team like that.
Next, I have a set routine where I check the visual notification. Generally speaking, when I am running my tests, I'll glance at the notifier. I TDD most of the time, so usually that means glancing at the notifier every 2-5 minutes. If I need to put my head down, I start a pomodoro timer (25 minutes) and I'll check the notifier when that goes off.
I don't always check the message when my notification goes. I keep it as a choice. If I need to keep my head down, then I just mentally make a note that I should check the notification when I get the chance. I don't know if it makes sense, but I use the same part of my mental process that I use for making notes of anything -- oh, I should fix that test, I should refactor that function, etc, etc. It's the stuff in the back of my mind that I've chosen to do later. If I get overloaded (as I tend to do now that I'm older) I put it in my TODO list (check slack). Then I can forget about it.
Basically that gives me a response time 2-3 minutes on average if I'm just cranking out code TDD style or on average about 15 minutes if I'm doing something more deep. Since I work remotely, having that "presence" is really important. Not disappearing for hours on end makes people feel more comfortable that you are actually there.
However, the last thing I do is if I really need time to myself, I'll send a quick message on slack saying, "I need to wrestle with X. I'll be away from slack for about 1-2 hours. Is there anything anybody needs before I do that?"
I guess one last thing. At one point in my career, I quit my programming job, moved to Japan and taught English for 5 years. Then I went back to programming. During the 5 years I taught English, I still did my own side projects, however at that time I didn't have any free time to really devote to programming. It had to be 10 minutes here and 10 minutes there. I worked hard at developing a technique where I could get in and out of the zone very quickly.
The 2 main pieces of advice I can give is, if you have tests, to always leave yourself a failing test when you switch contexts. If you have good test coverage, this is relatively easily done by simply sketching in some functionality and leaving the tests broken. When you come back, you can see all the broken tests and it will show you what your sketch was doing. Normally it takes me about 2-3 minutes to get back into the flow.
Second, make TODO lists. I use org mode in emacs (and actually moved from vim to emacs with evil mode simply to have a better org mode client!) However, you can use anything, really (markdown is fine too). Just get into the habit of dumping your though process into an editing buffer (I need to do X and then Y and then Z). I tend to try to break up my programming where I'll do 5-10 minutes of coding followed by 1-2 minutes of reflection -- so I force myself to stop and take stock of what I'm doing. This is where I tend to write my TODOs. If I'm doing pomodoros, then usually I'll write TODOs during the 5 minute "rest" period. Not only does it help me get into the flow faster, but I've found that the enforced reflection period helps me jump out of local maxima and save time (i.e. if you get going in one direction and miss a better opportunity). Since I'm 9 timezones away from my colleagues if I'm working while they are sleeping, I can often hand over my work to my colleague and they can finish it off while I sleep. It takes some practice communicating, but if you have a willing partner it's pretty fun tag team like that.