Before studying computer science, I spent 12 years in the United States Navy working in environments where failure carried real consequences. In military medicine, discipline is not about rigidity — it is about building systems that reduce uncertainty and prevent avoidable mistakes.
That mindset directly shapes how I approach software engineering.
1. Checklists → Testing and Determinism
In operational medicine, checklists exist to eliminate ambiguity. They ensure consistency under stress and prevent critical steps from being skipped.
In software, I apply the same principle through deterministic state transitions, clear data ownership, and systematic testing. I aim to build systems where behavior is predictable and side effects are explicit. Code should not “sometimes work” — it should behave consistently across environments and scale conditions.
2. Clear Roles → Clear Abstractions
Military teams operate effectively because responsibility is defined. Everyone knows their role and the boundaries of their authority.
In software architecture, this translates to separation of concerns. Components should have well-defined responsibilities. State should have a single source of truth. Interfaces should be intentional. When boundaries are clear, systems remain maintainable as complexity grows.
3. After-Action Reviews → Refactoring Culture
Every mission ends with a debrief. What worked? What failed? What needs improvement? The goal is not blame — it is refinement.
In engineering, I treat debugging and refactoring the same way. When something breaks, I look beyond the surface-level bug and evaluate the structural cause. Growth comes from improving the system, not patching symptoms.
4. Accountability → Code Ownership
In the military, accountability is absolute. You own your actions and their outcomes.
In engineering, I apply that same ownership to architecture decisions and implementation details. If a design introduces complexity or instability, I take responsibility for refactoring it. Clean systems require engineers willing to own both their successes and their mistakes.
5. Planning for Stress → Designing for Scale
Operational environments are designed around worst-case scenarios, not ideal conditions.
Similarly, I try to design software with growth and stress in mind. Performance, state flow, and extensibility are architectural decisions made early — not after problems appear. Systems should degrade gracefully, not collapse under expansion.
The transition from military service to software engineering may seem unconventional, but at their core, both disciplines rely on structured thinking, disciplined execution, and continuous improvement.
Engineering discipline is not about writing more code — it is about building systems that remain reliable as complexity increases. That principle continues to guide how I design, implement, and refine the software I build.
