Hacker News new | ask | show | jobs
by usrusr 2948 days ago
I've come to similar ideas from the opposite side (being a crazy sports enthusiast my body needs rest more often than not during office hours, so physical activity would be more a side effect than the goal):

When waiting for the computer forces us to idle, most of us try to fill the void with attempted multitasking. Be it half-assing something productive or trying to grab some instant gratification from our favorite distractions, it doesn't matter, it throws us or our the flow. This is why faster compilers raise productivity by much more than the directly saved man-minutes.

Now what if we could actively speed up the build? (or whatever else we are waiting for?)

Imagine a system that throttled down a bit during "unattended" builds (developer staring at hacker news would count as "unattended"), and only opened up fully when the user does "the compile thing", similar to your idea of carrying a medicine ball for deployments. It could be something hardly physical as repeatedly (impatiently!) tapping a button, but it would feel much better with a more physical activity.

What I envision is a big, satisfying crank. The Compiler Crank. With a subtle sound (or haptic) effect that stops when the build is done, bonus points for force feedback via modulating the resistance according to occupied cores.

It's not intended as a fitness device, just something to keep you occupied with something that does not cause the dreaded context switch, and does not promise occasional gratification (never ever try filling those gaps with Solitaire!).

Whatever productivity it would waste during hn-induced "unattended" builds, I think it could make up tenfold by maintaining high engagement whenever engagement is sufficiently high to actually use the device.

1 comments

This is awesome lol. We have a cloud CI system that builds deployables. Maybe the build priority on your branches is proportional to the RPM of your crank.