There’s a version of engineering that treats speed as virtue one: open the editor, ship something, iterate later. I used to believe that. I still move fast — but the first output is rarely code now. It’s a diagnosis.
Symptoms lie. Systems tell the truth.
A slow site isn’t “needs caching” by default. A broken checkout isn’t “fix the plugin” by default. A messy admin isn’t “train the client” by default.
Those might be answers. They’re often guesses. Diagnosis means tracing the system until the guess becomes evidence.
What diagnosis looks like in practice
Before I propose a build, I try to answer:
- Where does data enter the system?
- Where is it transformed?
- Where does it exit — and who depends on that output?
- What fails silently today?
For WordPress work, that might mean Query Monitor before a refactor. For internal tools, it means watching someone use the current process — not the one in the doc. For products, it means reproducing the user’s failure path end to end.
The cost of skipping this step
I’ve shipped “fixes” that solved the wrong layer. Optimised queries when the real issue was editorial workflow. Built automation when the team needed clarity. Added features when the product needed fewer decisions.
Each time, the code worked. The system didn’t improve.
Starting with code is sometimes procrastination dressed as productivity.
The habit now
I block a short diagnosis phase on every non-trivial task. Even an hour. Even when pressure says skip it.
That hour has saved days — sometimes weeks — of rework. And it changed how clients and teammates trust the work: not because I’m always right, but because I can show my reasoning.
Diagnosis isn’t slowness. It’s aim.