You perhaps have never worked in a system where compile times are measured in minutes. There is a point where the feedback loop is so long it’s very hard to keep in your head what exactly you were trying to accomplish with the last change. Getting that OODA loop small enough means flow can happen. Flow allows you to do in a very short time what would otherwise have taken you hours.

Do not underestimate the time and cognitive savings of realtime feedback.

Exactly this.

Many feature request in our system takes 2 hours to implement where it would be 5 to 10 minutes in C#/Visual Studio (with a tight debug/compile loop).

Without real time errors you can't get in a "flow"?

That's hard to believe.

I didn't mean to imply that you can't get into flow with even day long feedback loops. But the flow is definitely more likely to break while you're waiting for the feedback loop. I'm not sure you can really be in flow state between iterations if you're using punch cards circa 1970. But you might be able to reach flow state while writing said code between iterations, you'll just make sure to test more than one thing per iteration if possible. There's also a different state of mind that may look like flow for people who have to wait weeks to see if their code works. I know someone who grew up in a boarding school, and only had access to computers on the weekend, so he'd work on the code all week, only to get a chance to test it at the end of the week. He claims that's one of the reason he's such a good coder today, and I've heard similar anecdotes elsewhere.

But all kinds of things can knock you out of flow and so you might need to develop other strategies to compensate for something like a long compile time. I personally will write code, and every so often fire off a ./compile && flash_embedded_device && connect_to_device command then go back to write more code while I wait the minute plus it takes for me to get to run a test. This helps, but flow would be much easier to maintain if I didn't have to wait more than 5 seconds for the same test.

Not GP, but when you're waiting for three-plus minutes on "did my change have the desired effect," it's incredibly easy to get distracted by "just checking on this one thing" for a minute and completely losing flow. When writing code, sure, but writing code isn't 100% of my job; I also have to build it.

In our system it is incredible hard to get into flow. All of our work is basically intermittent due to the nature of the system.

You are fortunate that you haven't had to deal with it yet, but it's very real, you don't have to believe us.

Our development life cycle is quite slow/cumbersome with crappy in-house compilers that are on life support... yeah it makes a big difference not having to deploy between each iteration and get local feedback while I'm coding.

I cannot elaborate more than that but it is a bit more hairy than I described. My own tools alleviate some of the problems (sadly not all of them). Doing the best I can with what's available to me (basically building workarounds for shortcomings of our systems where I can see holes).