When I temporarily went into teaching (5 years... lol) after a career of programming, I still wanted to write software every day.  The only problem was that I only had small pieces of time -- usually 20-30 minutes here or there. It was a kind of enforced pomodoro.  Of course, I suffered exactly the same problem that you do, but even worse because it would be hours before I could pick up the code again.<p>My solution was to try to swap out that context to disk :-)  I&#x27;m back in software again and I&#x27;ve refined my techniques a bit.  It&#x27;s helpful for me because as I get older, I can hold less context in my brain than I used to be able to do anyway.  There are 2 main places I store context: tests and TODOs.<p>I&#x27;ll start with TODOs.  I actually use Emacs org mode for TODOs.  The best part about Org mode is that it is in a text editor.  That means that I interact with it the same way that I interact with any other tool.  It is also hierarchical, which means that I can embed TODOs within TODOs.  Finally, it is folding, which means that I can ignore large sections of the TODO list, or move sections around with just a few keystrokes.<p>Basically, as I&#x27;m programming, whenever I have the thought, &quot;Oh, I have to do this&quot;, it goes in the TODO (even if I&#x27;m just about to do it).  You have to be terse because you don&#x27;t want it to take more than 1 or 2 seconds to jot down.  But terse is OK.  I actually have 2 editors open -- one that I&#x27;m programming in and one with Org mode.  I switch between windows in tmux.  This is the fastest way for me, but if you use Emacs normally, then Org Capture might be faster.<p>Every time I finish something, I go back to org mode, mark it DONE and then reorder my TODO list.  It only takes about 10 seconds to reorder the TODO list and it&#x27;s useful time for me to think about what I&#x27;m doing.<p>The easier bit for keeping context is tests.  As I&#x27;m getting near the end of the pomodoro, I make sure that I have a failing test.  If everything is passing at the moment, I quickly write a failing test.<p>When I return from the pomodoro, the first thing I do is run the tests.  This shows the failing test.  At that point, I only concern myself with fixing that test.  If you are used to doing TDD, then it usually only takes 30 seconds or a minute to fix the failing test.  This is like a bit of a boot loader to get you back into the problem.  After the test is finished, I go to the TODO and reorder them.  Often it doesn&#x27;t have to be reordered, but the act of thinking about priorities restores the context for me.<p>Currently, I&#x27;m doing some experiments where I am recording myself doing a large kata where I do one pomodoro per day (the ultimate in context killing).  I don&#x27;t have any conclusions yet, but the techniques I describe above seem to be working well.<p>I&#x27;m using Asciinema to record myself and it elides portions where you are idle for a certain number of seconds (I have it set to 2 seconds).  In other words it removed bits where you are doing nothing for more than 2 seconds.  By comparing the actual time spend to the length of the recording, I can see how long I was idle.  At the moment, it seems to be averaging about 5 minutes for every 25 minute pomodoro.  That doesn&#x27;t seem to be excessive to me (since I am reading documentation and thinking occasionally).