Writings
Papers for finished thinking. Notes for captured thinking. Use the section links or open the full archives.
Papers
- Seniority Is Pattern Recognition Under PressureFeaturedThe real value of senior engineering leadership is recognizing instability before everyone else is forced to.
- The Illusion of VelocityLatestWhen movement replaces progress—why busy delivery cultures quietly erode the conditions for sustainable speed.
- Architecture Is Organizational DesignSoftware architecture stops being only about services and schemas—it becomes how the company is allowed to coordinate, scale, and change.
- The Industry’s Addiction to ReinventionWhy engineering teams confuse friction with failure—and how novelty bias quietly undermines systems that already hold years of institutional memory.
- The MVP TrapThe hidden cost of treating MVP architecture like a permanent foundation.
- How to Actually Start a SystemMost systems are not designed incorrectly. They are started incorrectly. The first decisions determine everything that follows.
- The Anatomy of FailureSystems do not fail because of isolated mistakes. They fail because of misalignment, unclear boundaries, and decisions that compound over time.
- Building Systems That Cannot Be WrongIn regulated financial systems, correctness is not an optimization. It is the baseline. The architecture must reflect that.
- What Your Go Code Looks Like When the System Is UnclearThe shape of your Go code reflects whether the system behind it is understood. Not because the language enforces it, but because it leaves little room to hide.
- AI Does Not Replace Engineering JudgmentAI accelerates writing code, but it does not replace engineering judgment. The difference between human-in-the-loop and human-driven development determines whether systems scale or fail.
- Alignment Isn't Enough. The Model Has to Be Right.A shared mental model only helps if the model is correct. Teams can align around the same assumptions and still build the wrong system.
- When Tools Become the ProblemA good tool applied to the wrong problem makes the system worse. Not every decision is a process.
- AI in PracticeAI can generate code quickly. Building a real system with it exposes what actually matters.
- Where Judgment Comes FromEngineering judgment is not learned from frameworks or documentation. It is formed through experience where decisions carry real consequences.
- AI-Assisted DevelopmentAI accelerates development when it operates within clear constraints. Without structure, it produces output that appears correct but lacks cohesion.
- Simplicity Requires UnderstandingSimple systems are not shallow. They are the result of deeper understanding applied with restraint.
- Engineering JudgmentMost software problems are not caused by missing tools or frameworks. They are caused by poor judgment applied at key decision points.
- Architecture FirstThe idea of building quickly and figuring things out later is often mistaken for pragmatism. In practice, it delays clarity and spreads inconsistency.
Notes
- Systems Tell You When They Are FailingLatestFailures that feel sudden are usually preceded by signals that were ignored.
- Interfaces Are Where Systems BreakMost failures do not occur inside a component. They occur at the boundary between them.
- Determinism Is Not OptionalIf the same input does not produce the same result, the system cannot be trusted.
- Drift Is the Real Failure ModeSystems rarely fail because of a single mistake. They fail because small deviations are allowed to accumulate.
- Reconciliation Is Part of the SystemIf you cannot explain what happened, you do not control the system.
- Not Every Problem Is a ProcessTreating simple decisions as workflows introduces state, complexity, and failure modes that do not need to exist.
- Constraints Make AI UsefulAI becomes more useful as constraints become clearer. Without boundaries, output quality degrades quickly.
- Architecture Is a Decision DisciplineArchitecture is not documentation. It is the discipline of making and protecting consequential decisions.
- Simplicity Requires UnderstandingSimple systems are not shallow. They are the result of deeper understanding applied with restraint.
- Shared Libraries Create Hidden CouplingShared libraries often introduce dependencies that are harder to see than they are to manage.
- Overengineering Is a SignalOverengineering is rarely a sign of sophistication. It is usually a sign that the system is not well understood.