My company uses an internal build tool (like a set of bash scrips around docker) to orchestrate the various parts of the stack locally. There's no workaround for it; there's no other way to run the stack.<p>Starting this tool usually takes about 20 minutes on my M2 Mini. This isn't long enough to do any serious work but over the course of the day (and running this script a handful of times) adds up to 1-2 hours. Yes, it's completely ridiculous, I know.<p>What's an activity I could do with this time?
Once a day, just do nothing. Really nothing. Look at the blank wall for 15 minutes and let your mind wander.<p>I don't do that every day, but if I find the time and discipline to do it I never regret it afterwards.
Are there any isolated parts of the system that you can work on outside of the fully-built system? Maybe there's some refactoring that needs to be done, where you can do some of the work in isolation and then stage it for the next build?<p>Also, since nobody's mentioning it, are you in a position to research/ prototype an alternative approach that doesn't take so long to build?
The basic strategy I use is to do multiple / unrelated tasks or projects at once. Do some work on task A - check out a branch for it, make a change, push it to get build.... switch to a different branch for B, do some work on that, push it for a build... then go look at what happened with the build for task A while B is building, etc, etc.<p>It may require a few VMs, etc, but basically it's worth having a good way of switching between several things on the boil at once. It's not just slow builds, it's also waiting for feedback from people, etc. that will get you in this situation.
I prefer to read programming books (which tend to also be part of, or contribute to, my annual "work goals"). Reading is perfect for my 20-30 minute "dead zones" since it's pretty effortless, and I can start and stop quickly without paging too much into/outof my brain. Meanwhile, doing any meaningful programming in that time would be almost impossible; it takes that long to get from 0 to 60 in the first place, and then I'd immediately have to stop anyway, so there's no point.<p>Of course, there's also HN. :devil_emoji:
Could improve that crappy feedback loop :)<p>If the language runtimes are compiled you can't do this, but if not, in theory you shouldn't need such a stupidly long core development feedback loop.<p>I'm a huge fan of <a href="https://tilt.dev/" rel="nofollow">https://tilt.dev/</a> and the possibilities it unlocks for that pre-commit development.
Compile a list of very low hanging fruit - tasks which might take a few minutes each. For example things like code linting, formatting or generating docs.<p>20mins is plenty of time to execute "housekeeping" tasks related to building software.<p>Alternatively do something physical - pull-ups, squats, push-ups, etc.
I keep a list of tasks that I need to accomplish each day. Some of these are very simple and easy to knock out. I use the time in between activities to knock off one or two each time.