I don’t know what work you do, but if my test takes longer than 30 minutes I’ll start working on something else, and when I come back to fix whatever failed in the test (when I get to it a few hours later), I’ll have to reconstruct the entire problem space in my head again.

If your build time or test runtime takes 30 minutes I'd argue your problem won't be solved by faster hardware.

This requires a context switch which is expensive in it's own way. Read the article, it covers this pattern pretty well.

Even with the high end machine it still takes 27 minutes. If I have a 27 minute build I am absolutely going to context switch. If it’s more than about 3 minutes I am probably going to context switch.

An interesting experiment would be to find the switch-time threshold for a wide range of developers.

Typically I don’t rely on a full build for getting things accomplished, and not CI if I can help it. Local, incremental, and minimal path to feedback is what I aim for.

It may be non-linear. I guess I am not patient. If it takes up to ~40 seconds I just wait and don't context-switch; if it takes more than ~3 minutes I switch to another work-related task; but if it's in between -- I tend to check the e-mail, or the news, or something like it, and then 15 minutes later "Oh shit! My build\test is done, and I completely forgot I was doing it!"