Projects
It starts
with a question.
Behind the work
The decisions
behind the tools.
The work here moves between infrastructure, networks and software. Projects begin with something concrete: a repeated interruption, a fragile assumption, or a tool that makes a simple task harder to understand.
Before adding a feature, I ask whether the model describes the problem well enough.
That usually means asking whether two things a system treats as one are really the same thing. Pulling a cable is often what makes the distinction matter.
I care about what a system changes, what it preserves, and whether its behaviour can be explained. Those questions guide what gets built — and what gets left out.
Have a question about the work? Get in touch.
How I think
Before the algorithm,
understand the problem.
I start with a situation I want to understand. I break it into parts, make the assumptions explicit, and look for a model I can reason about. Then I choose how to solve it.
-
Find the actual problem
The visible task is not always the whole problem. I ask what someone is trying to achieve, where things break, and what needs to survive a change.
Arranging rectangles on a screen is a visible task. Keeping a working arrangement intact across restarts and hardware changes is the question underneath it.
-
Choose what the model represents
What are the objects? Which relationships matter? What is temporary, and what needs a stable identity?
A window handle disappears when a process closes. A monitor can be disconnected. The model needs to distinguish those events from the loss of the workspace itself.
-
Define what must remain true
Before searching for a good solution, I define an acceptable one. Hard constraints set the boundaries. Priorities decide between the choices that remain.
Filling unused space should never outweigh a decision the person already made. A choice a hard constraint rejected must not come back through a fallback.
-
Choose the strategy
Sometimes I can examine every possibility. Sometimes I can eliminate whole branches, reuse the answer to a smaller problem, or make a local choice.
I ask what each strategy assumes, what it guarantees, and what it costs. A heuristic needs a clear account of what it may sacrifice.
The choice follows the structure of the problem.
-
Challenge the result
I start with a small case I can follow by hand. Then I introduce a conflict, remove an assumption, or increase the scale.
Did the result respect the rules? Can I explain why it was chosen? How much work did it cause?
A fast decision is not enough if it moves things outside the scope it was given. When a test fails, I revisit the assumptions, the model, and the strategy.