It might partly be a personality-type thing. I can&#x27;t imagine visually inspecting and verifying anything if I didn&#x27;t write it to begin with. I wouldn&#x27;t know where to begin thinking of possible ways to break it. On the other hand, it seems far more natural for the author to say, &quot;here are the race conditions I considered, these points where a context switch would be maximally inconvenient. And still lo the program works.&quot; This way the reader doesn&#x27;t have to recreate such situations from scratch. He or she just has to verify the provided situations, or notice a scenario that was missed. That seems like an easier ask from someone new to the project.<p>(Mu scenarios can&#x27;t insert context switches yet, but it&#x27;s planned.)<p>Perhaps it would help to think of the dichotomy as between the rules and the state space of inputs they handle, rather than between reading and running. Seemingly simple code can often hide surprising subtleties. Why is this line written just like so and not thus? How does everything turn out just right in this one situation? Tests help to record the right questions for the reader to ask.