As a frequent internal tool writer, I’d say it’s a fact of life but an undesirable one. I’m always trying to avoid pausing for credentials in the middle of a run, either by doing them right at the beginning or by using some sort of durable credentials system like ssh keys.
There’s always two people at every company who refuse to set up auth automation though, so you end up handling it. They are very stubborn. Even when it trips them up in front of observers while executing an urgent task, I’ve only occasionally convinced them to agree to set up trust instead of typing a password every single time.
Which is to say, I have to support password prompts even though they drive me up the wall.
My first brush with CI, I ended up putting an option to play a sound at the end of local builds because I’d already noticed evidence of Hofstadter’s Law applying to build automation.
The thing is when you expect a task to take five minutes, you don’t watch it, you find something else you expect to take five minutes and do that instead. When that ends up taking ten minutes, or when you remember what you were doing before you started, you finally come back around ten minutes later to find that either the task completed four minutes ago, or it failed after ten seconds and you’ve wasted ten now.
The audio was the best out of band notification I had at my disposal 20 years ago.
My first thought when reading this was actually terminal multiplexing however, like screen or tmux. But I’m also always doing the terminal dance because I work on 4 FOSS projects and I keep 1+ terminal open per project so I can jump in and do bug fixes or pull PRs I’ve landed.
> human-perceptible range allows me to use my intuitive sense of time and speed
I didn’t intend to specialize in performance early in my career but it happened anyway. I tuned boring homework assignments to make them more interesting for myself. But I moved far away for my first gig out of school and when I showed up the UI painted so slow it looked like one of those videos of an artist drawing something by hand but sped up. I hid my panic at having my name associated with this stinking pile and as soon as I’d done a couple of challenging bug fixes to prove I wasn’t an idiot I got to work.
My first dozen changes needed no benchmarks, In part because I had the slowest machine in the office. I could literally count seconds in my head and tell that I’d taken >1/4 of a second off of an operation because I made it a syllable or two farther in the old version. Later on I used the stopwatch function on a handheld device, to catch 100ms differences. I was there for nearly two months before I needed to put console output of (end - start) into the code for the first time.
By the time I started running out of stuff I knew how to fix, the corpus of data had started showing a serious scalability problem in the data filtering operations, so we were back into classical architectural misdeeds. We had a 2n logn² intersection test that did two scans on different criteria and compared the results using a quadratic time comparison. This code was copy pasta’d in dozens and dozens of places around the project, with slight variations in variable names and parameter marshaling. I replaced all the copies with one function they did filter(filter(x)) over a long holiday weekend since I had nobody local. -500 lines of code and much much lower slope of call time on multi year data sets.
I’ve only seen two projects brag about making a <2% performance improvement and that was crate and the guy working on pointer compression for v8.
I have mostly always known better and either report aggregate numbers, like 15% across six changes, or in milliseconds, like TTFB down from 600ms to 590ms. The tricky bit with the former is that you want to cluster changes to the same call tree or cross cutting concern so that the testing surface area of each additional change is only a small increment over the costs already incurred by the first change. Essentially amortizing the potential for uncaught regressions and delays on the release process across a handful of small changes over the same interactions.
Because if you make small changes scattered across the entire codebase, the testing cost and the risk of escape balloon, which is why people try to stop you from doing incremental improvements at all.
On the project where I figured this out, I delivered 30% improvements every milestone for 2 years before I started scraping the bottom of the barrel, moving from subsystem to subsystem and fixing everything I knew how to fix. Sometimes that was three changes, sometimes it was ten. The second time around was taking lessons learned back into areas I’d covered prior to learning them, but mostly looking for regressions that had arrived in new features and bug fixes.
Some optimizations like hoisting still improve code readability even if the benchmark are inconclusive. And of course how a piece of code behaves in vivo and under test can vary quite a bit in both directions. Particularly with space/time tradeoffs, where you reduce or increase cache pressure with code running concurrently to your code.
A lot of my meditations on optimization date back to a profiler telling me that a redundant function call was responsible for 5% of the run time of a task. After removing it, run time decreased by 20%. Then I had to think about all the ways in which profilers can lie. It’s still a black art after all this time.
The tools tell you whether it might be worthwhile to look at a problem, but keeping your work is a completely different matter entirely. Unfortunately some people get Sunk Cost Fallacy, or worry about losing face, so once committed to a course will see it merged into the codebase whether it does anything or not. And they will push harder if they win the lottery and one test run says theirs is much faster. Nevermind that the next ten runs show the opposite.
> how a piece of code behaves in vivid and under test can vary quite a bit
I've never seen "in vivid" used this way. Are you thinking of "in vivo" which is from Latin meaning "in life" or "in living" distinguished against Latin "in vitro" meaning "in glass" referring to the glass petri dishes or beakers used to do science experiments in a laboratory?
That’s because Apple autocorrect is a long con to prove that humans are too stupid to be left in charge. We can’t even english good. I assure you I did not type “in vivid”.
The business owner has the illusion of independence until he/she pisses off enough of their staff all at the same time that they walk out and there's nobody to open the store.
Something that was true in 2003 can be not true in 2026 with absolutely no contradiction. It’s a problem I’ve had multiple times with people getting bristly assuming that a push to replace a broken but “working” subsystem with something new and better necessitates a confession of guilt by the people who wrote the original system.
As problem domains scale up by orders of magnitude, as they have since Linus ranted on 2003, the correct solution changes. Sometimes several times. It was the right solution, but it might not be the right solution now, and both are correct.
There’s always two people at every company who refuse to set up auth automation though, so you end up handling it. They are very stubborn. Even when it trips them up in front of observers while executing an urgent task, I’ve only occasionally convinced them to agree to set up trust instead of typing a password every single time.
Which is to say, I have to support password prompts even though they drive me up the wall.
reply