I like to start from constraints: time, energy, safety, and the smallest set of moving parts. When the problem space feels messy, I write down the key invariants that must hold true regardless of implementation.
For robotics work, those invariants often include: latency budgets end-to-end, deterministic control loops, and observability so I can see what the system believes is happening. Once the boundaries are clear, I run the simplest baseline possible and measure it—usually before any "smart" components appear.
A few habits that help me move faster:
- Keep the first prototype intentionally boring. Get data flowing and sensors calibrated before chasing performance.
- Write short build logs the moment I make a decision. Future me (or a collaborator) should be able to trace why something exists.
- Use physical intuition when possible: if a mechanical tolerance feels tight, treat it as a software risk as well.
This approach is slow only on day one; by day seven it composes into momentum. The main goal is to avoid magical thinking and let constraints do the shaping.