theory building

Bilingual

Things that made me think: Open Source trust relationships, knowledge without provenance, and theory building
2 months ago
- AI agents can fabricate credible GitHub profiles, undermining trust in open source contributions and disrupting reputation-based hiring.
- Provenance is essential for interrogating LLM outputs; citations alone are insufficient because the training set context matters.
- Software development is theory building, not code writing, but this conflicts with business priorities that treat the product as the saleable artifact.
- The tension between building theory and selling products varies with short-, medium-, and long-term commercial impact.
theory building without a mentor
2 months ago
- Peter Naur argued that programming is theory building and that recovering a program's theory solely from code and documentation is impossible, but the author disagrees and provides methods to do so.
- Theory modification is real and happens over time as team members change; you'll never recover the exact original theory, only create a new one.
- To rebuild a theory, start with a specific goal and focus on the relevant parts of the program, using techniques like searching error messages, backtraces, or known names.
- Reading source code is key: use an LSP to find all call sites, skim callers, and run mini experiments (e.g., exit(1), logging, debuggers) to verify understanding.
- When writing new code, copy small snippets (10–15 lines) from the existing codebase and match its style to reduce bugs and please maintainers.
- Testing is crucial: find existing tests, run them before changes, and create new tests early to verify your emerging theory.
- Iteration time matters; learn how to run individual tests and document your process via CONTRIBUTING.md or README files.
In defense of not understanding your codebase
2 months ago
- Software engineers have differing views on codebase understanding: small, low-turnover teams advocate complete understanding, while large, high-turnover teams accept partial understanding.
- Peter Naur's 'Programming as Theory Building' argues that code is a by-product of a programmer's 'theory of the program,' but his conclusion that code should be discarded when theory is lost is impractical for large systems.
- Large software systems cannot be rebuilt from scratch due to countless quirks; rewrites must occur incrementally by carving out small chunks.
- Abandoned codebases can be revived by engineers starting with one flow and gradually expanding understanding, even without original team members.
- In sufficiently large codebases, everyone operates with a partially incorrect theory; effectiveness requires making educated guesses and dealing with consequences.
- Maintaining a theory of the codebase is just one engineering value among many, often traded off for speed, legal compliance, or other priorities.
- LLMs hinder detailed theory building but enable quick partial theories and effective leverage, representing a complex tradeoff.
- Other factors that impede theory maintenance include team turnover, legal requirements, security patches, and dependencies.
In defense of not understanding your codebase
3 months ago
- The article argues that in large software systems, having only a partial understanding of the codebase is acceptable and often necessary.
- It critiques Peter Naur's 'Programming as Theory Building' by stating that rebuilding large systems from scratch is impractical due to complexity and that abandoned systems can be revived through gradual learning.
- The author suggests that engineers in large teams must work with imperfect mental models, making educated guesses and dealing with consequences.
- Trade-offs are discussed, noting that factors like team turnover, legal requirements, and dependencies can hinder maintaining a full theory of the code.
- The article concludes that while maintaining a complete theory is desirable, in professional settings, other values like speed or compliance may take precedence.

theory building

Things that made me think: Open Source trust relationships, knowledge without provenance, and theory building

theory building without a mentor

In defense of not understanding your codebase

In defense of not understanding your codebase