A software epiphany
A personal blog post on “programming as theory building” argues that the real work of software development is constructing and maintaining rich mental models of a system, which explain why legacy code is hard to change, solo developers can sometimes outperform teams, and rewrites often feel easier than onboarding to an existing codebase. Readers largely agree with the core idea, relating it to concepts like mental models, conceptual integrity, documentation quality, domain knowledge, and even how AI-generated code can become a “black box” without an accompanying theory. However, many are put off by an animated notification widget on the site that tracks live visitors, prompting strong criticism of the user experience, workarounds like reader mode and ad-block filters, and ultimately leading the author to remove the feature and explain the original intent behind it.
Site UX and Notification Popup
- Most comments fixate on a bottom-of-page “live visitor” notification stream.
- Many describe it as distracting, “seasick”-inducing, even an epilepsy risk; some refuse to read the article on principle.
- Suggested workarounds: browser reader mode, uBlock/NoScript rules, physically covering the bottom of the screen.
- Some argue users shouldn’t have to “fix” a blog’s UX; others say the article is good enough to justify small workarounds.
- The author later appears in the thread, explains the intent (make the site feel “alive” and highlight privacy implications), and reports the feature has been removed after the backlash.
“Theory” vs “Model” / Terminology Debate
- Several commenters find “theory” confusing and suggest “model,” “mental model,” “abstraction,” or “understanding” as clearer terms.
- Others defend “theory” in the Ryle/academic sense: an internal, partially inexpressible structure enabling skilled action.
- There is some semantic back-and-forth on whether a theory must be communicable and how it differs from intention or domain knowledge.
Software as Theory / Knowledge Medium
- Many resonate with the idea that the crucial asset is the shared mental theory behind the code, not the code alone.
- This is used to explain:
- Why legacy systems are hard to change.
- Why solo developers with full-system understanding can outperform larger teams.
- Why rewrites feel easier than onboarding to unfamiliar code.
- Some push back, arguing the actual “product” is the business outcome/output, with theory as an important but secondary asset.
Legacy Code, Documentation, and Collective Understanding
- Several describe real-world experiences of reconstructing theory from poorly documented legacy systems.
- Some insist good documentation and version history can capture much of the missing theory; others say theory can never be fully externalized.
- Emphasis that understanding is often collective, spread across teams, not a single mind.
AI-Assisted Coding
- One thread links the theory concept to discomfort with AI code generation: AI output feels like a “black box” lacking an internal theory.
- Others suggest an interaction pattern where AI helps build code and explanations iteratively, so the human still forms a workable theory.