Preferences seem to matter here, some people just seem to do better with longer cycles of feedback on more items than shorter cycles on fewer items. And some pe

Preferences seem to matter here, some people just seem to do better with longer cycles of feedback on more items than shorter cycles on fewer items. And some people really may need that "my code is compiling, it'll take a while and there's nothing I can do" break to mock-sword fight or whatever, almost like a pomodoro break between periods of intense focus. But there is some data on what could be, and you can of course measure your own latency on things. More narrowly defined, in the Java world JRebel is a product that can eliminate many kinds of forced redeploys after code changes -- or more simply, stopping and restarting your program and waiting for everything to come back up and reconfigure any necessary state to get back to what you were doing. I saved so much time thanks to it. Their own marketing materials suggest just this waiting on redeploys thing can quickly add to 20% of salaried time. (https://www.jrebel.com/sites/rebel/files/pdfs/rw-mythbusters-jrebel.pdf https://www.jrebel.com/sites/rebel/files/pdfs/rw-mythbusters...) Using it almost gets within javelin distance of what CL has always had, and gives you the flexibility to develop and debug in a more interactive style without having to go TDD or rewrite in ABCL. I haven't been keeping up (so would love to be informed things are otherwise) but I thought it was a shame that the JS front-end world seemed to finally be creeping up on where ClojureScript was in 2014 or so for interactive low-latency development, but then suddenly took several steps backwards with TypeScript -- with respect to interactivity at least, I don't doubt people's claims of steps forward on other metrics.