About_Me

My Engineering Journey

In my tour of academia, software engineering was taught to me as a sequence of ceremonies and artifacts. It adapts a general engineering lifecycle: elicit → design → implement → maintain, and then wraps these fundamental elements with a lifecycle‑management philosophy: Agile, Iterative, Waterfall. Each philosophy is then expressed through its own family of implementations: Scrum, Spiral, V‑Model.

But in practice, by my estimation, that’s mostly how project managers conceptualize the workflow. At the engineering level, practicing the phases of the fundamental elements makes it clear that they iterate internally—a lesson I learned firsthand through trial by fire.

Early on, at the beginning of my career, my mentors were the ones most people start with: Codecademy, Alistair Cockburn, Robert C. Martin, Richards & Ford, and a handful of algorithm book authors. When I entered workplaces without a lifecycle‑management implementation, I followed the dogma I had graduated with and made my best attempt to implement it. But because the work was green-field—or green-field layered onto brown-field—and because I was managing the entire process myself, the formal models fell apart immediately. Ceremony for the sake of itself collapses. Planning without a stable domain becomes fiction. Velocity means nothing when discovery reshapes everything.

Drowning in disorder, I began searching for new mentors and found them in: Eric Evans, McLaughlin, Pollice & West, Freeman & Robson, and as many online resources as my still‑lingering university library access could grant me. The results reshaped how I thought about building systems entirely.

I stopped trying to force structure onto domains that were not defined. I learned to model the domain first, and to treat diagrams as tools for discovery rather than documentation. I found that the diagrams that did become documentation communicate what exists—not what will exist. I learned that architecture is not something you impose—it is something you uncover.

Problems I Enjoy

I thrive in green-field environments where the domain is still being discovered and defined.
I work best with systems that have clear specifications and well‑articulated requirements.
I’m most engaged when solving problems that require subject‑matter expertise and collaboration with domain experts.
My background in test and evaluation makes me comfortable analyzing system behavior against specifications, especially in compliance‑driven contexts.
I gravitate toward roles where discovery, iterative refinement, and architectural clarity are central.

How I Design Systems

Form follows function.
Once enough of the domain is understood, I choose the language/s and follow the paradigm that best fit the problem.
Maintainability comes first.
I prioritize maintainability through readability, and extensibility. As the domain reveals itself, earlier solutions evolve, and because I build iteratively, I accumulate components that often serve future systems.
My workflow is built for discovery.
I break problems into coherent chunks, complete a pass, step away, return with fresh eyes, refine, and move forward. My process is thorough, deliberate, meticulous, and grounded in iterative review.

Principles I Work By

If the problem becomes unclear, you need more discovery.
If you cannot model it, you are on the wrong path. Diagrams are tools for discovery, not final architecture. Once the domain is clear, the architecture clicks into place.
Good architecture is simple to extend.
Most problems lead to familiar conclusions; your design will often resemble an existing implementation. Before inventing a pattern, study how others solved it.
Assume the design is wrong before assuming the technology is broken.
Ask questions early and often. Systems fail more often because of misunderstanding than malfunction.