I still remember when I worked in game development back in 2004 or so, that I made extensive use of Visual Studio's "Edit and continue build" feature at work, and how it really helped with the feedback loop. It was a little buggy but worked very well considering it was only a "debug" feature.
A few years later I worked on an even bigger game with an even bigger loading time, and "Edit and continue build" no longer worked at all due to the platform architecture of the game. It really, really hurt my productivity (and motivation). I wish this project all success, it could help many people!
(Does Unity have something like this yet? I remember last time I worked with it I loved being able to change the properties of objects at runtime, but still missed being able to change the actual code...)
The last time I used Unity (about 1~2 years ago), hot reloading was basically useless and I tried to avoid it as much as possible (some people actually disable to disable this feature to avoid any "accidental" runtime recompilation.) It messes with serialization too much that it only works with very, very simple cases.
In my experience, it only reliable works for singleton objects which have changes in their method bodies. Any change in the memory layout creates random null reference exceptions on each frame update.
It also depends on how you've designed your MonoBehaviours. If you have anything dependent on resources retrieved in your Awake event, those references will not be restored and the Awake event will not re-occur. So you either have to check and reacquire the references in your Update event (which is costly), or design everything around serialized fields that are set in the editor, with no objects acquired during Awake (which is intractable for anything but the most basic projects).
Unity is designed to get the basic demo feature of whatever you're doing done as quickly as possible. But building a production-scale product is actually harder than just writing from scratch, as there are a lot of stupid design decisions in Unity that get in the way.
For me, the most memorable chapter in the excellent book Coders at Work was the Dan Ingalls one, in which he made the case for interactive development.
It's not always reliable however, if you add/remove variables in your UCLASSES or USTRUCTS, or the values in your UENUM, it can fail or have unpredictable results, or at least it did as recently as 4.18/4.19.
Otherwise if you're just adding/removing code from classes it works extremely well and saves a lot of time restarting the editor.
I suppose I'm the only person who wondered if "DirectX11" meant that MS had finally ported their flagship game APIs to the venerable Unix graphics system.
I still remember when I worked in game development back in 2004 or so, that I made extensive use of Visual Studio's "Edit and continue build" feature at work, and how it really helped with the feedback loop. It was a little buggy but worked very well considering it was only a "debug" feature.
A few years later I worked on an even bigger game with an even bigger loading time, and "Edit and continue build" no longer worked at all due to the platform architecture of the game. It really, really hurt my productivity (and motivation). I wish this project all success, it could help many people!
(Does Unity have something like this yet? I remember last time I worked with it I loved being able to change the properties of objects at runtime, but still missed being able to change the actual code...)