The problem with slow tools (2021)

I ran a survey and some one-on-one interviews of 30 or so engineers at my workplace to get some real data about the impact of slow tools. IIRC, the results were something like this:<p>* Most engineers can maintain focus on a task for up to 10 seconds waiting for a slow tool. However a couple of engineers (myself included) will get derailed at only about 3-5 seconds.<p>* A tool that runs for more than a minute will cause just about every engineer to switch task while it is completing. (This means they stop working on their highest-impact work and likely spend time on lower-impact things).<p>* A tool that runs for more than 15 minutes will make any engineer have to start deliberate multi-tasking where they are trying to work on two major work items at once.<p>Also, I wouldn&#x27;t have read the article or posted this comment if it weren&#x27;t for the slow CI pipelines at my workplace.

&quot;Well, let&#x27;s say you can shave 10 seconds off of the boot time. Multiply that by five million users and thats 50 million seconds, every single day. Over a year, that&#x27;s probably dozens of lifetimes. So if you make it boot ten seconds faster, you&#x27;ve saved a dozen lives. That&#x27;s really worth it, don&#x27;t you think?&quot;<p><a href="https:&#x2F;&#x2F;www.folklore.org&#x2F;StoryView.py?story=Saving_Lives.txt" rel="nofollow noreferrer">https:&#x2F;&#x2F;www.folklore.org&#x2F;StoryView.py?story=Saving_Lives.txt</a><p>I think of this quote whenever I am waiting for my iPhone to boot. Though I suppose Apple would argue that you don&#x27;t need to reboot your iPhone every day the way you might have with older computers. There were never a billion Mac users though.

Of course every delay is a potential interruption to focus which costs way, way more than the delay itself, so much so it&#x27;s not worth calculating the actual delay&#x27;s &#x27;lost time&#x27;.<p>In fact even a momentary delay (my macbook now seems to often stutter for 2-3 seconds switching spaces) is an opportunity for your focus to drift (why is this damn thing so slow, I should get a new machine, actually, I should lookup the latest thinkpad, maybe I can tune memory use in the meantime, how <i>do</i> you tune macos memory, can you even?, etc ...).

&gt; Well, if you do the math, 15 minutes a day times 230 working days a year equals just shy of 60 hours - or 1.5 work weeks - wasted per year. Multiply that by the size of the engineering organization, and this starts to look pretty expensive.<p>I hate this type of reasoning. 15 minutes a day is 3% of the day. Multiply that by 230 working days a year and it&#x27;s 3% of the year. Multiply that by the size of the engineering organization, it&#x27;s 3%. Your maximum savings here is 3%, no matter how many numbers you multiply it by.

Kids these days! In my day, compiling took so long we could go get lunch, walking uphill in the snow both ways.

Good article. It focuses on build times as the bottelneck, but actually for me most of the time that bottleneck is 2FA.<p>By the time I&#x27;ve managed to sign in to my email to double check an instruction, I&#x27;ve already forgotten what I was looking for...

Reads like the dude just learned how to multiply and extrapolate and got carried away.<p>If you spent 2 minutes peeing, and pee 8 times a day, that&#x27;s 5840 minutes spent peeing a year! Wow! I bet he&#x27;d love that one.

The problem with multiplying all the way to the organization size is that it&#x27;s always going to end up being a big number.<p>Imagine all the oxygen we would save if we all stopped saying &quot;bless you&quot; every time someone sneezes, multiplied by the population of the world, multiplied by an average time per year someone sneezes multipled by an average lifetime multipled by an average amount of people in the room who can hear the sneeze.

I&#x27;m not going to say that slow tools is not an issue, however I think slow management processes has a far greater cost to an organization, and the amount of people in management or business analysts doing psedou-work. Which the author also indicate end of the post, how many of us don&#x27;t have a few 30-60 minutes meetings a week that effectively have no value to anyone.

Slow tool is annoying, but it&#x27;s not critical.<p>Bad code, shitty micromanagement, garbage meetings is the main issues.

Compiling and deploying effectively destroys my train of thought every time.<p>The only thing that has helped is to reduce build times from minutes to seconds.<p>By disabling link-time optimization in pre-production and by throwing out Docker because it doesn&#x27;t play nice with build tool caches.

The assertion here is that these lost bits of time are purely negative.<p>I come back with fresh eyes and spot things, get coffee, tidy the desk, make a call, stretch the leg, use the restroom, &amp;c.<p>But I don&#x27;t pass myself off as an ur-coder, so possibly I don&#x27;t count.

These articles about extrapolating the value of a minute of wasted time into a years worth of value, always forget to divide them by the average productive hours a day. I assume you’re not optimising for zero breaks.

Applications that try to do too much in one application often start to experience serious performance problems as time goes on. Almost all applications written with node.js have this problem.

April 1st