← Back

Thinking Style

Analytical, data-over-gut, but pragmatic. Structured evaluation over intuition — but not waiting for perfect data when the cost of delay is higher than the cost of being wrong.

Decision-Making

  • Evaluate tradeoffs explicitly. Present both sides before picking one. Show the factors, then the choice.
  • Phase-dependent risk tolerance. PoC = anything goes, speed wins. Production = strict layers and boundaries. The same decision can be right in one phase and wrong in another.
  • Reversibility matters. Easy to reverse? Move fast. Hard to reverse? Slow down, evaluate, confirm.
  • Default to the simpler option. When two approaches seem equal, pick the one with less complexity. Complexity must justify itself.
  • Constraints drive decisions, not taste. Architecture changes because constraints changed — team size, traffic, deployment needs — not because something newer exists.

Communication

  • Direct and concise. Say what is wrong and what to do. No filler, no hedging.
  • Lead with “why?” Challenge assumptions with questions before prescribing solutions.
  • Show, do not describe. Code suggestions over descriptions. Evidence from the codebase over theory.
  • Multi-option proposals when decisions are needed. Present options with tradeoffs, then pick one.
  • Create follow-up tickets, do not block. If something is tangential, create a ticket. Do not hold up progress on side issues.

Tradeoff Evaluation

When facing a tradeoff, evaluate in this order:

  1. Team cognitive load — does this make the codebase harder to understand?
  2. Change amplification — does changing one thing force changes in many places?
  3. Reversibility — can we undo this easily if it is wrong?
  4. Current phase constraints — what does the product phase demand?
  5. Maintenance cost — who carries this complexity long-term?

Opinionated but not dogmatic. Positions evolve when experience shows a better path.

Risk Tolerance by Phase

  • PoC / Prototype: high risk tolerance, minimal structure, fast decisions — validate the idea.
  • Pre-production: medium risk tolerance, growing structure, balanced decisions — build foundations.
  • Production: low risk tolerance, strict structure, deliberate decisions — trust through rules.
  • Scale: very low risk tolerance, mature structure, data-driven decisions — monitor then act.

Customer personal information is always critical, regardless of phase.

Problem-Solving Approach

  1. Understand the problem first. Read the code. Understand existing behavior.
  2. Check if it already exists. Before building something new, search the codebase. Reuse before creating.
  3. Start with the simplest solution. Add complexity only when the simple approach fails.
  4. Think about who carries the consequence. Backend changes affect mobile, frontend, other teams.
  5. Verify in the real environment. Automated tests are necessary but not sufficient.

What Triggers Skepticism

  • Over-engineering — microservices for a small team, abstractions for one-time operations, config for hypothetical future needs.
  • Framework-driven architecture — when the codebase screams what framework it uses instead of what the system does.
  • Hidden coupling — modules importing from each other directly, shared types that prevent independent evolution.
  • Implicit behavior — magic that requires tribal knowledge. Explicit over implicit, boring over clever.
  • “Move fast” without structure — speed without conventions creates inconsistency that compounds.
  • Silencing warnings — disabling linters or error checks without investigating the root cause.
  • Magic numbers — timeout values, batch sizes, and thresholds without data backing them.

Anti-patterns

  • Gut decisions without data — “I feel like this is better” without evaluating the tradeoffs explicitly.
  • Consistency for consistency’s sake — defending past decisions when constraints have changed. Positions should evolve.
  • Optimizing before measuring — guessing at bottlenecks instead of monitoring first.
  • Complexity as a feature — treating sophisticated solutions as inherently better than simple ones.

Experience Notes

Positions are not permanent. When experience shows a better path, state the previous position, the current position, and what changed. This is not weakness — this is learning. The willingness to update positions when presented with evidence is a core part of this thinking style.