Engineering Problem Solving
Twenty-four short lessons. Start with the problem, reduce uncertainty, choose one useful step, and learn from what happens.
Frame the Problem
3 lessonsTurn a request into an outcome, the people involved, and a concrete definition of done.
Describe what changes for someone when the work succeeds. Keep technologies and proposed features out of the sentence.
List who interacts with the system and the concrete actions each actor takes. Verbs expose workflows; role names alone do not.
Replace “it works” with one concrete input, action, and observable result.
Find the Boundaries
3 lessonsName constraints, assumptions, invariants, and what is deliberately outside the first version.
Time, scale, regulation, team knowledge, and required integrations remove options before architecture begins.
An assumption is a temporary answer used to move forward. Write it down with a way to verify it.
Some properties cannot be traded away even in a small first version. State them before simplifying.
Turn Unknowns Into Questions
3 lessonsReplace vague topics with answerable questions and the smallest experiment that could answer each one.
Do not let facts, questions, and guesses share one undifferentiated requirements list.
A topic cannot be researched efficiently. Turn it into a question whose answer changes a decision.
Learn only enough of an unfamiliar technology to answer the current question, then return to the problem.
Decompose the Work
3 lessonsSplit the problem by user capability into pieces that can be built and observed independently.
Decompose around user-visible capabilities before splitting work into frontend, backend, and database layers.
A decomposition ends when each leaf has a clear action and an observable result.
Ordering becomes clearer when each piece names what must exist before it can work.
Choose the Next Step
3 lessonsRespect dependencies, expose risk early, and select the smallest useful vertical slice.
Choose one thin user action that crosses every necessary layer and produces a visible result.
First remove blocked work. Among the work that remains possible, choose by value, learning, risk, and effort.
A risky unknown may deserve an isolated spike before its feature reaches the front of the delivery queue.
Test the Idea
3 lessonsUse examples, predictions, and small prototypes to meet reality before the whole system is built.
Abstract claims become useful when a specific case forces a precise before and after.
Write down what you expect before executing a test, query, benchmark, or probe. A result only teaches when it can disagree with a model.
A successful experiment answers one question. Record its blind spots before confidence expands beyond the evidence.
Debug With Evidence
3 lessonsReproduce the symptom, form a hypothesis, and gather evidence that separates possible causes.
Before explaining a failure, make it happen on demand and capture the exact inputs, environment, and output.
A useful hypothesis predicts what evidence should look like if the proposed cause is true.
Gather the evidence that best separates the remaining causes, not simply the evidence that is easiest to collect.
Learn and Iterate
3 lessonsWrite down what changed, update the model, and keep ownership of decisions when using tools or AI.
After an experiment or implementation, write what changed in your understanding and what decision changes with it.
Record consequential decisions with their context, alternatives, evidence, and a trigger for reconsideration.
Bring AI a problem statement, your reasoning, and a concrete artifact. Ask it to challenge the work, then verify every consequential claim.