Whether it is a machine-to-machine system, where robustness and flow come first; a business application, which must fit the work of the people who use it; or a consumer service, where everything begins with people and their circumstances, my approach remains the same: understand before building, and trace problems back to their causes rather than treating their symptoms.
This approach rests on one conviction: technology should strengthen our grasp of reality, not distance us from it. No one should have to compensate indefinitely for the flaws of a system or machine. I learned this first-hand while operating a production line: too often, the operator compensates for the system instead of being supported by it. Automation only makes sense when it frees attention for work that requires judgement and decision-making. And a problem properly addressed should do more than disappear: solving it should create knowledge and simplify the system.
For me, this question of control extends beyond software. From the scientific revolution to the industrial, digital and now algorithmic revolutions, our systems have grown ever more powerful and abstract. We must preserve our ability to understand what they do, why they do it and how they reshape the way we act. That begins with bringing our attention back to reality and taking the time to observe and model it.
I work between the why and the how, between design and implementation, and between people and machines. My role is to understand deeply enough to design with purpose, then command the technology well enough to make the result concrete, useful and durable. I want neither to design systems I could not build nor to build systems whose purpose I have not questioned.