How I Think
My framework for navigating ambiguity and engineering tradeoffs.
Engineering Philosophy
Software and hardware are just tools. The real skill is effective problem solving in unconstrained environments.
The Ambiguity Reduction Loop
When faced with an open-ended problem, I apply a recursive process to identify constraints and critical paths.
Example: Field Issue Analytics Dashboard
Managers knew they needed "better visibility" into field issues—but what did that mean? Applied the ambiguity reduction loop:
- Identified hard constraints (data sources, refresh requirements)
- Defined soft constraints (stakeholder preferences, timeline)
- Prototyped KPI trees until we found metrics that drove action
- Scaled to a dashboard reviewed daily by multiple teams
Tradeoff First Thinking
Every architecture decision is a tradeoff. I explicitly list what we are optimizing for (e.g., Latency) and what we are sacrificing (e.g., Throughput, Complexity).
"There are no solutions, there are only trade-offs." — Thomas Sowell
Example: Automated Load Carrying Cart
The cart project required explicit tradeoff decisions:
- Stability vs Maneuverability: Chose differential drive (simpler, more stable) over holonomic wheels
- Cost vs Accuracy: Selected ultrasonic sensors at 1/10th the cost of LIDAR—sufficient for indoor demo
- Control complexity vs Performance: PID-based avoidance over more sophisticated planners
Each decision documented what we gained and what we gave up.
Verification Model
I believe in "shifting left" on verification.
- Unit Tests: Logic verification.
- Integration Tests: Interface verification.
- Simulation: System behavior verification in safe environments.
- Hardware-in-the-Loop: Reality check.
Example: Applied Materials Debugging
When investigating opto-mechanical drift at a customer site:
- Isolated variables systematically (unit-level thinking)
- Tested interactions between thermal and mechanical factors (integration)
- Correlated against tolerance specifications (system model)
- Validated fix in the actual operating environment (reality check)
The structured approach led to root cause faster than ad-hoc troubleshooting.