150 seconds is a long time to wait to see if you've finally fixed a stubborn bug.

How can people develop without hot reloading?

@msdsk what makes you think it's FE web dev?

@lungdart yeah, that's literally the thing, how can people develop anything that isn't FE web? Whenever I need to work with stuff that needs to compile for longer than an hour I age a year for every twenty seconds of compilation time.

@msdsk oh sweet summer child...

I recall connecting an oscilloscope to a microcontroller to debug transient timing issues.

You'd have to put logic in for flipping a pin high and low during function calls, and pray that the code changes (and probe loading) didn't have an effect on the thing you were measuring.

If you need a change, you'd have to not only recompile, but pull an EEPROM from the socket and put it in the programmer to reflash it, then replace it in circuit and start over.

Or even worse, patching issues on physical circuits with a 3 week turn around from the pcb house in thailand...

Try debugging a machine learning training script that runs for 8h and then crashes. That right there is a long time. I learned the value of checkpointing the hard way :D

TDD that shit for faster feedback - just manual testing is archaic

@MammaNeedHummus I would love for you to share how I build a test for a recursive multithreaded importer handling 250k 3d meshes that only mostly follow a spec that may load properly on their own, but fail spectacularly when loaded after another mesh.

TDD only really works when you control every aspect of a well defined process you control.

@cuddlyogre I'd bet mola that there will be whole sections (units) of your code that you can write tests for.

Is the codebase very tightly coupled?
Am happy to try an help with this if you're interested

@MammaNeedHummus You are correct, there are lots of opportunities for testing. Not one of which would have caught the bug I was getting.