I envy your 50ish seconds. Especially since it sounds like you could cut that down quite a bit with a beefier build rig. I do kernel development, and for me t

I envy your 50ish seconds. Especially since it sounds like you could cut that down quite a bit with a beefier build rig. I do kernel development, and for me the turn around for a one-line change is 4-minutes to 2+ hours. About 60 seconds for the build (32-core Threadripper, solid state storage), about 30 seconds to tar up the kernel and scp it to a test box, and about 2 1/2 more minutes to install the kernel and reboot (most of which is in the super slow uEFI bios). That's the 4 minutes for a trivial change. Somewhere in the middle is ~40-ish minutes for our central CI service to run all the unit tests when a branch is pushed to. But the 2+ hours is what I encounter most often. That is for testing non-trivial changes on production traffic. It takes over an hour to gently ramp a box down from full load to no traffic (so I can install a kernel an reboot), and another 1+ hours to ramp it up with customer traffic. Since we're testing in production, it means I often want to watch the machine closely, so that I can gracefully ramp it down if things start going pear shaped. I agree that leaves way too much time for distraction. I try to multi-task and have multiple projects in flight at the same time in order to make more effective use of the waiting time.