Ask HN: Are faster compiles always better for productivity?

I once worked on this code where the builds were half an hour long, because there was this manual process of git pushing changes, compiling it as a plugin, then removing and readding the plugin from the server.

We put a lot of thought into the code because of that. Everything was planned out in a document. But when you run it, you discover things were left out - someone forgot to escape a ' or we forgot that something needed 4 parameters instead of 3.

First, it encourages some hacks - just put in some tech debt here and there and then fix it when it compiles correctly.

Secondly, the morale hit is tremendous. Even with a 1 min compile, it just makes you feel terrible when you get nothing done, then you go to work feeling terrible. The other guy who worked on the project ended up working until late at night, then sitting in the office never getting any work done, until he spiraled into depression and was eventually let go.

There's the "one more build" effect too. A build takes 5 min. It's 5.50 PM. You want to head home at 6 PM. The build doesn't work. You go home annoyed or you can work on it. If you work on it, you end up going home at 8 PM because of how these things go. So in the future, you just end up not doing any work late in the day.

Well one time I made things compile so much faster that it ended up killing my coworker's computer PSU for a few days while IT replaced it. So... not always?

No, because I am implementing the next part while it's compiling.

Faster compiles are better. I've never had to wait more than a second, ever, for Lazarus/Free Pascal to compile, or tell me where I messed up.

Interruptions destroy the flow state.

No, it makes for nasty workaround Feedback cycle matters