Programmers should never trust anyone, not even themselves

Trust, “Trust but Verify,” and Programmer Mindset

• Many see “trust but verify” as effectively “don’t trust, but stay polite”; others rephrase it as “trust and verify” to emphasize assuming good intent while still checking work.
• Several argue that if you must verify, you don’t truly “trust” in the strict sense, but practically we all rely on partial, graded trust.
• Some prefer the motto “assume good intent and capability, but verify work,” especially in domains where errors are common and costly.
• Others note you can’t feasibly distrust everything: at some layer you accept hardware, compilers, or libraries, or you’d never ship.

Psychological Impact of Distrust

• Commenters distinguish between realistic skepticism about systems and paranoid suspicion about people’s motives. The former is seen as healthy; the latter as corrosive.
• The “paranoid programmer” attitude is praised for catching bugs, but several note it can morph into anxiety or burnout if carried into everyday life.
• Compartmentalizing is recommended: distrust abstractions and processes, but maintain basic interpersonal trust.

Abstractions, Reality, and Money

• The thread emphasizes that abstractions stack indefinitely: below one layer you just find more abstractions, not “raw reality.”
• Banking is debated: some stress that deposits are digital liabilities and loans create most money “from nothing”; others reply that banks still must “do something” with deposits and that money is as real as any symbolic system.
• There is disagreement over how constrained banks actually are and whether physical money would fundamentally change behavior.

Strings, Performance, and Leaky Abstractions

• Random access cost depends on representation: ASCII gives constant-time indexing; Unicode encodings generally make “character by position” linear-time.
• Multiple comments argue “character” is an incoherent abstraction; better to think in bytes, code points, or displayed glyphs.
• Performance tradeoffs: in many real workloads, linear search with good cache behavior can beat binary search; dynamic arrays often outperform linked lists due to locality.

Testing: Use, Misuse, and Coverage

• Consensus that failing tests show bugs, but passing tests do not prove correctness.
• Many criticize tests that over-specify implementation details, making refactoring painful, or that effectively test mocks instead of real behavior.
• Some argue unit tests are best as API contracts and post‑baseline safety nets; others use them heavily during development but later replace trivial tests with higher-level or property-based tests.
• There is skepticism of metrics like 100% coverage and “cargo cult” test-writing done mainly to satisfy management.

Formal Verification and Its Limits

• Several point out that while full automatic verification is impossible in general (halting problem), many real systems or components can be partially or fully verified.
• Formal verification practitioners report routinely finding bugs even in seemingly trivial, well‑tested code.
• Discussion notes that proof tools and compilers themselves can be buggy, but concepts like small trusted kernels and verified compilers (e.g., meeting the de Bruijn criterion) aim to bound that risk.
• Others question whether the extra effort is worth it everywhere, given Gödel‑style limits and cost; the emerging view is that it’s valuable for critical subsystems, not all software.

Design and Reliability Practices

• One detailed comment advocates a constraint-based approach: strong type and sanity checks, rate limits, watchdog timers, periodic restarts, dead‑man switches, simple modular programs, and avoiding chaotic APIs.
• Hardware and electronics experience is cited: in physical systems, not checking assumptions can be lethal, and similar rigor and graceful failure should increasingly apply to software as it controls more safety‑critical systems.

Documentation and Learning

• Some praise the article’s advice to read more documentation and to build a mental model of an entire library or framework.
• Others note that even with thorough reading, connecting pieces can be hard, and tools like large language models sometimes surface non‑obvious combinations from the docs.