Think from first principles

Most answers are copied. Someone picked a number, a tool, or a process step under constraints that no longer hold, and everyone downstream inherited it as fact. The discipline here is separating what must be true from what merely happens to be true, then rebuilding from the first group.

This is not contrarianism. Convention is often right, and the point is to know why you believe it.

When to spend the effort

Run the full workflow when the decision is expensive to reverse, when the gap between options is large, or when the user asks for it. Otherwise take thirty seconds to ask what you are treating as given, and proceed normally if nothing interesting falls out. Grinding a full teardown through routine work buries the answer.

The workflow

1. Recover the real objective

Write down the outcome the user actually wants and the metric that would prove it. The requested method is not the objective: "add a caching layer" is a proposed means, "p99 read latency under 100 ms at 10k requests per second" is an objective.

Watch for two objectives fused into one request. "Cut the queue backlog because the bill is too high" contains a throughput goal and a cost goal, and they often have opposite solutions, since buying throughput usually raises the bill. Separate them and ask which one the user is judged on.

In a single response, do not stall on questions. State the assumption you are proceeding on, label it, and carry the open questions into the final section as the cheapest test.