Reflective practice is a dialectic process and depends on backtalk from the code and editor in order to advance the solution (reflection in action) or to rephrase the approach (reflection on action).
In programming, we have observed backtalk from four sources: running the code, reasoning about the code, feedback from static analysis, and representing the code differently (e.g. in a diagram). To support the cycle of reflective practice, a system can e.g. tolerate broken and pseudo code, simultanously allow different (e.g. visual) representations and perform automated reasoning.
The most direct mode of backtalk was making a change and executing the program to see the result. Programmers furthermore relied on mental execution to find bugs, e.g. reasoning about front-end code that was broken beyond execution. Static analysis was another source of backtalk, e.g. using the JSLint static analysis tool regularly without executing the code. A final source of backtalk comes from the representation, e.g. using state charts and transition matrices to reason about complex network interactions. We observed backtalk from a variety of sources, and rather than siding either with dynamic (backtalk from execution) or compiled languages (backtalk from static analysis), programming systems should provide backtalk suitable to the specific situation.