Debugging traditionally separates two activities that should be one. You modify code in the editor, then switch to the debugger to run it and observe behavior. Edit and observe occupy different tools, different modes, different mental frames. Exploratory programming — trying variations to understand behavior — requires constant switching between the space of code changes and the time of execution traces.

SpaceTime Programming fuses them. The trace mechanism captures not only execution state but also the corresponding code changes, creating a unified representation where navigating code variations and navigating execution history are the same operation. You can move along the time axis (stepping through execution) or the space axis (switching between code versions) and see how both dimensions interact.

The implementation as a Python library demonstrates the concept through two use cases: an interactive debugger and a game development tool. Performance overhead runs 35-150% on test suites — nontrivial but bounded, and the overhead exists because every code change and every execution step is being recorded into a persistent trace structure.

The deeper insight is about what "understanding a program" means. Traditional tools give you snapshots: the code as written (static), the execution as it happened (dynamic). But comprehension requires the relationship between variations in code and variations in behavior — the derivative of execution with respect to code changes. That derivative is what the fused space-time trace provides. The 35-150% overhead is the cost of computing the object that actually contains understanding, rather than its projections.