Break Problems Down Before You Code
Lesson 1 of 5 · View course roadmap
Learn the idea
Staring at a blank editor isn't a coding problem — it's a decomposition problem. Professionals never solve "the task"; they solve a chain of tiny steps:
- What comes in? (a list of numbers)
- What goes out? (a count, a total, an average)
- What are the steps between? — each one small enough to be one or two lines
Write the steps as comments first, then turn each comment into code. This "comment skeleton" technique feels almost too simple, and it is exactly how experienced developers start anything unfamiliar. A problem you can list, you can code.
Where you'll use this
Ticket breakdowns, pseudocode in design docs, TODO-comment skeletons — decomposition is the daily bread of professional programming. Interviewers score the way you split the problem before they score your syntax.
Common mistakes
- Starting to type before you can say the steps out loud — blank-editor paralysis is a planning gap, not a skill gap.
- Steps that are too big ('process the data') — a good step maps to one or two lines of code.
- Skipping the 'what comes out?' question and coding toward the wrong output format.
Pro tip
If a step feels hard to code, decompose that step again. Recursion isn't only for functions — it's how you plan.
Try it yourself
The lesson example is loaded and ready — press Run, then change something and run it again. Breaking it is part of learning. Want a clean slate? Tap “New blank”.
Output appears here…
Pass the challenge +30 XP
Decompose and solve: for nums = [4, 8, 15, 16, 23, 42], print the count of numbers, then the total, then the average — one per line.
6 108 18.0
len(nums), sum(nums), and their division. Print each on its own line.
nums = [4, 8, 15, 16, 23, 42] count = len(nums) total = sum(nums) print(count) print(total) print(total / count)
Run your code to check it…
Check your understanding
Your notes (saved on this device)
Tip: use ← and → to move between lessons, ⌘K to search everything.