About
How I think, how I work, and why behavior matters
I’m Jose Flores, a software engineer and technical advisor. I focus on helping teams ship complex systems with confidence. I started making behavior explicit after watching how quickly things drift when the decisions stayed implicit.
That shift still shapes how I work.
My background (the short version)
- Product teams shipping customer-facing systems.
- Founders navigating scale and technical uncertainty.
- Local businesses turning websites into reliable lead engines.
In the teams I worked with, the stalls were rarely about code quality. What I kept seeing was unclear expectations and behavior that was hard to reason about.
How I think about software
A lot of complexity I ran into came from hidden assumptions. When behavior lived only in people’s heads or scattered across components, teams slowed down, bugs repeated, and decisions got revisited endlessly.
I make behavior visible and shared by:
- Modeling flows with statecharts.
- Structuring systems using the actor model.
- Turning assumptions into scenarios you can test.
- Writing decisions in plain English so they don’t drift.
In practice, this doesn’t add overhead. It removes friction.
How I work with teams
- Clarity matters more than speed.
- Decisions are documented, not tribal.
- Collaboration beats heroics.
- Shipping sustainably is the goal.
I don’t arrive with a fixed framework or agenda. I help teams choose the smallest tool that solves the real problem. That might be a workshop, advisory support, or hands-on engineering, depending on what the system is asking for.
What people usually notice
- I ask the right questions early.
- I explain tradeoffs clearly and calmly.
- I reduce ambiguity instead of adding process.
My goal is always the same: make future work easier, not harder.
Open source and teaching
I maintain and contribute to open-source projects like Actor-Web and Ignite-Element. These tools exist because I care about developer experience and systems that scale cognitively, not just technically.
Teaching and writing help me sharpen these ideas. They also help others avoid the mistakes I’ve already made. See open-source work →
Who I tend to work best with
- Teams that value clear thinking over buzzwords.
- Projects where behavior is made explicit instead of assumed.
- Collaborative environments where decisions are shared, not centralized.
- Work that prioritizes long-term stability over short-term fixes.
The engagements that have gone best for me are the ones where I’m brought in as a thinking partner, not just someone to take over decisions. If that kind of collaboration resonates, the writing and open-source work here will give you a good sense of how I operate.
What’s next
If you want to go deeper, start with the Behavior & Boundaries series. I usually point people to When Code Becomes Cheap first.