A small collection about dependable tools, experiments, and evidence.
01Tools4 min read
Small tools that age well
The most durable tools tend to have visible inputs, boring outputs, and a narrow job.
A script becomes easier to trust when its assumptions are explicit. Prefer a readable configuration file over hidden state, an absolute path over a mysterious working directory, and a dry-run mode over optimistic execution.
Accept one clear input format.
Fail before changing state when validation is incomplete.
Write outputs atomically and preserve a recoverable copy.
Print evidence that another person can verify.
02Experiments5 min read
A compact reproducibility checklist
A figure is not yet a result until its provenance can be reconstructed.
Record the source revision, environment, random seed, parameters, and the exact command that produced an artifact. Keep validation separate from interpretation: a program may run correctly while the scientific claim remains unresolved.
This separation makes failures more informative. It also makes it possible to improve one layer without quietly changing another.
03Debugging6 min read
Debugging by boundaries
When a system crosses several layers, test each boundary independently.
Start with the smallest meaningful facts: name resolution, route selection, TCP or UDP reachability, cryptographic handshake, protocol response, and finally application behavior. A success at one layer should never be promoted into proof of the next.
route → transport → TLS → protocol → application
The discipline is simple: say exactly what the test establishes, and just as clearly what it does not.