What kinds of things destroy determinism, and how do you avoid them?

Anything with an unbounded or unpredictable worst-case time is the enemy. Dynamic memory allocation: malloc/free timing varies with heap state and fragmentation can fail unpredictably, so hard real-time uses static or pool allocation instead. Unbounded or data-dependent loops: if a loop's iteration count depends on input with no fixed cap, it has no WCET, you bound everything. Priority inversion: unbounded blocking on a shared resource, fixed with priority-inheriting mutexes and short critical sections. Long interrupt-disabled windows or large critical sections: they delay high-priority work, so you keep them short and bounded. Hardware timing variability: caches, branch prediction, and deep pipelines make the same code take different times depending on machine state, which is why hard real-time often favors simpler, more predictable cores or disables/locks caches on critical paths. Garbage collection: unpredictable GC pauses make most managed languages unsuitable for hard deadlines. And hidden offenders on the critical path: logging, flash writes, network stack processing, DVFS frequency changes, and contention all add jitter. The avoidance strategy is consistent: keep the hard-real-time path free of unbounded operations, prefer static allocation, bound every loop and critical section, use priority inheritance, account for interference in schedulability analysis, and leave CPU margin so jitter doesn't push you over a deadline. The throughline is "make the worst case knowable and bounded," which is exactly what determinism means.