A problem definition says what a program should accomplish, not necessarily how to code it. Look for the task, the inputs, the expected output, and any behavior that changes with the situation. If the steps are missing, you must work them out. section 12.1 section 2.5
From a vague request to a useful one
“Bake a loaf of bread” leaves many recipes open. Asking for a two-pound rosemary loaf and specifying ingredient amounts narrows the task, though you still need to decide how much rosemary to use and how to combine the ingredients. A programming request can leave similar decisions to you. section 2.2
Before writing code, treat the proposed program as a black box: what goes in, what comes out, and what should happen in special cases? Write a few sample inputs beside their expected outputs. A sketch can make the interactions easier to see; pseudocode can then turn the sketch into possible steps. section 2.3 section 12.1
Use the bread-machine black box to separate given ingredients from the result before deciding on recipe steps. section 2.3
Quick check: two names in, one mashup out
Suppose a user enters two full names. The program separates first and last names, mashes up each pair, and displays the new name. Before coding, sketch that path and try short, long, odd-length, and even-length names as test inputs. Which cases might need special handling? section 12.1
Once the task is clear, divide it into smaller pieces of code. Test each piece against your examples, debug what fails, and repeat. Understanding the problem first makes those divisions easier to find. section 19.3 section 2.5
