empirical-verification

Empirical Verification

Every assumption must be tethered to reality.

The process

When you believe something about how code behaves, devise a hypothesis and test it. Write a small script. Add a log statement. Run the debugger. If the empirics match your expectation, proceed. If they do not, you have found a bug, a misconception, or a premature assumption -- investigate.

Search before invent

Search online to see if others have observed the same behavior. Read the documentation to understand what is actually supposed to happen. Explain to yourself what the system is doing and why. Only once you understand the behavior should you attempt to change it.

Root cause fixes

Fix problems at the root cause. Surface-level patches create debt. If a function fails under certain inputs, do not add a guard clause at the call site. Fix the function. If a system misbehaves under load, do not retry until it works. Find the bottleneck.

Quick fixes become permanent fixtures. The shortcut you take today becomes the constraint you work around tomorrow.

Verify before ship

The pattern is simple: do not guess when you can verify. A distinguished engineer does not assume they remember how an API works -- they check. Especially true for security code, payments, and external services.

Quality measurement

The quality of your work is measured by how well you interact with the real world. Not by how clever your abstractions are. Not by how quickly you produce code. By whether the code actually does what it is supposed to do when it runs.

Pattern: form-test-report

Hypothesis:  X happens when Y
Experiment:  small repro (script, curl, log line)
Observed:    actual output
Conclusion:  hypothesis confirmed | refuted | partial; here's the new theory

Apply this loop to every uncertain claim before writing a fix.