diff --git a/astro.config.mjs b/astro.config.mjs index e657588..8d0a53a 100644 --- a/astro.config.mjs +++ b/astro.config.mjs @@ -43,7 +43,7 @@ export default defineConfig({ label: 'About', items: [ { label: 'Me', slug: 'index' }, - { label: 'Building Theories', slug: 'about/building-theories' }, + { label: 'Theories and Proofs', slug: 'about/theories-and-proofs' }, { label: 'Projects', slug: 'about/projects' }, { label: 'Stoicism', slug: 'about/stoicism' }, { label: 'Leadership', slug: 'about/leadership' }, diff --git a/src/content/docs/about/building-theories.md b/src/content/docs/about/building-theories.md deleted file mode 100644 index 1824418..0000000 --- a/src/content/docs/about/building-theories.md +++ /dev/null @@ -1,76 +0,0 @@ ---- -title: Building Theories -description: Building Theories is the core of my approach to software development, architecture, and organizational design. ---- - -I've been struggling to articulate my approach to software development, architecture, and organizational design and what I am good at. -I have a strong intuition that there is a common thread, but it has been elusive to put into words. -Recently I read Peter Naur's "Programming as Theory Building" and it crystallized my thinking. - -I build theories. I verify them against reality by implementing code, designing architecture, and organizing teams. -I protect them from erosion by maintaining boundaries, managing change, and ensuring shared understanding. - -### Architecture as a Concept of Proof - -Architecture is the *conceptual proof* that a theory is internally consistent. - -It demonstrates that: - -- The system can exist under stated constraints -- Responsibilities are separable without contradiction -- Critical invariants can be preserved over time -- Failure and recovery are intelligible within the theory - -Architectural structures are not chosen for elegance. -They are chosen because they make the theory *provable* under real constraints. - -An architecture that cannot explain its own failure modes is an unproven hypothesis. - -### Code as a Proof of Theory - - -Code is an executable proof that the theory survives contact with reality. - -It forces precision where informal reasoning is ambiguous: - -- Assumptions must become explicit -- Edge cases must be named -- Invariants must be enforced or violated - -If the theory is wrong, code does not fail politely. -It fails operationally. - -Bugs are not primarily coding errors. -They are places where the theory was incomplete, incorrect, or unstated. - -### Tests, Linters, and Metrics as Feedback Loops - -Tests, linters, and code metrics are not quality signals in isolation. -They are **feedback mechanisms** about the quality of the proof. - -They indicate: - -- Where the theory is under-specified -- Where invariants are weak or leaking -- Where local reasoning no longer composes - -An increase in defensive code, excessive tests, or metric gaming -often signals theory degradation, not improved rigor. - -The goal is not compliance with tools.
-The goal is early detection of theory decay. - -### Summary - - -I build theories.
-I verify them against reality.
-I protect them from erosion.
- -Everything else is implementation detail. - -### References - -- [Peter Naur, Programming as Theory Building](https://pages.cs.wisc.edu/~remzi/Naur.pdf) -- [Programming as Theory Building OCR](https://gist.github.com/chrisjrn/4d2cebdd7dbea7fa41ae6c94e046f752) -- [Programming as Theory Building and LLM](https://cekrem.github.io/posts/programming-as-theory-building-naur/) diff --git a/src/content/docs/about/theories-and-proofs.md b/src/content/docs/about/theories-and-proofs.md new file mode 100644 index 0000000..1eb0af4 --- /dev/null +++ b/src/content/docs/about/theories-and-proofs.md @@ -0,0 +1,108 @@ +--- +title: Creating Theories and Building Proofs +description: Creating Theories and Building Proofs is the core of my approach to software development, architecture, and organizational design. +--- + +I've struggled to articulate my approach to software development, architecture, +and organizational design, and what I am actually good at. + +I had a strong intuition that a single underlying activity connects these domains, +but it was difficult to express without collapsing into role labels or tool-centric language. +Reading Peter Naur's *Programming as Theory Building* crystallized this intuition. + +I create theories and verify them against reality by building proofs: +through code, architecture, and organizational structures. +I protect these theories from erosion by maintaining boundaries, +managing change explicitly, and ensuring shared understanding. + +### Theories as Mental Models for Reality + +A theory is a mental model that makes reality intelligible and navigable. + +It defines the *shape of the problem space* before any solution is attempted. +Without such a model, actions may still occur, but they are reactive, +local, and difficult to reason about beyond immediate effects. + +A theory establishes: + +- What belongs to the system and what belongs to the environment +- Which elements are internal, which are external, and why +- What is under control, what is influenced indirectly, and what is not controllable +- Which interactions matter and which can be ignored without consequence + +By doing so, it makes trade-offs explicit. +It clarifies what must be protected, what may be sacrificed, +and what must never be assumed away. + +Boundaries are a direct consequence of the theory. +They separate domains where different assumptions hold +and prevent accidental reasoning across incompatible models. + +A weak or implicit theory blurs these distinctions. +As a result, responsibility leaks, invariants erode, +and the system becomes harder to explain than to operate. + +A strong theory does not guarantee correctness, +but it makes incorrectness visible. + +### Architecture as a Concept of Proof + +Architecture is the *conceptual proof* that a theory is internally consistent. + +It demonstrates that: + +- The system can exist under stated constraints +- Responsibilities are separable without contradiction +- Critical invariants can be preserved over time +- Failure and recovery are intelligible within the theory + +Architectural structures are not chosen for elegance. +They are chosen because they make the theory *provable* under real constraints. + +An architecture that cannot explain its own failure modes +is an unproven hypothesis. + +### Code as a Proof of Theory + +Code is an executable proof that the theory survives contact with reality. + +It forces precision where informal reasoning is ambiguous: + +- Assumptions must become explicit +- Edge cases must be named +- Invariants must be enforced or violated + +If the theory is wrong, code does not fail politely. +It fails operationally. + +Bugs are not primarily coding errors. +They are places where the theory was incomplete, incorrect, or unstated. + +### Tests, Linters, and Metrics as Feedback Loops + +Tests, linters, and code metrics are not quality signals in isolation. +They are **feedback mechanisms** about the quality of the proof. + +They indicate: + +- Where the theory is under-specified +- Where invariants are weak or leaking +- Where local reasoning no longer composes + +An increase in defensive code, excessive tests, or metric gaming +often signals theory degradation, not improved rigor. + +The goal is not compliance with tools.
+The goal is early detection of theory decay. + +### Summary + +I create theories.
+I build proofs to verify them against reality.
+I protect them from erosion using boundaries, tests, and feedback mechanisms.
+ +### References + +- [Peter Naur, Programming as Theory Building](https://pages.cs.wisc.edu/~remzi/Naur.pdf) +- [Programming as Theory Building OCR](https://gist.github.com/chrisjrn/4d2cebdd7dbea7fa41ae6c94e046f752) +- [Programming as Theory Building and LLM](https://cekrem.github.io/posts/programming-as-theory-building-naur/) diff --git a/src/content/docs/index.md b/src/content/docs/index.md index 699e80f..87b5c9f 100644 --- a/src/content/docs/index.md +++ b/src/content/docs/index.md @@ -40,7 +40,7 @@ I choose which problems to tackle and which to release, aiming for tranquility a ## What I Do -I [build theories](/about/building-theories) and I specialize in solving complex problems—technical, organizational, and strategic. +I [create theories and build proofs](/about/theories-and-proofs) for complex problems—technical, organizational, and strategic. ### Core Principles