Computational Thinking: Planning Solutions Before Coding

Computational thinking means describing a problem and its solution clearly enough to carry out. A person, a computer, or both can follow the plan. Computer scientist Jeannette Wing helped make the term widely known in a 2006 essay.

Four practices that work together

These practices are not steps you must finish in one fixed order. While writing instructions, you may notice a missing part. You then return to decomposition. Some courses also name generalization, turning patterns into wider rules, and evaluation, judging a solution.

Plan a class bake sale

Start by splitting the job: choose products, set prices, make signs, handle money, and clean up. Each part now has a smaller goal.

Next, notice a pattern. Each product needs ingredients, baking, packaging, and a label. One checklist can serve several products.

For pricing, keep the ingredient cost and number of items. Plate color does not affect this pricing rule, so leave it out. That choice is abstraction.

Now write the pricing algorithm: "Divide the ingredient cost by the number of items. Round up to the next 25 cents. Add 50 cents." For brownies costing $9.00 for 24 pieces:

1. Divide $9.00 by 24 to get $0.375 per piece.
2. Round up to $0.50.
3. Add $0.50, giving a selling price of $1.00.

Carry out the plan

Programming, or coding, writes instructions in a language a computer can run. Scratch uses blocks; Python uses text. The plan can exist before either program.

An unplugged task uses no device. You might sort cards or give a classmate drawing instructions. Bebras puzzles also exercise these skills. An on-screen task might turn the plan into a Scratch game. Both need clear reasoning.

Planning also makes mistakes easier to find before much code depends on them. A diagram or written algorithm lets teammates discuss the same idea and share jobs. If everyone starts coding from a different idea, the finished parts may not fit.

A computer follows the instructions it receives. It does not supply the missing steps in your plan.

"The class library is a mess" names a concern, but it leaves much unanswered. Are books hard to find? Are loans missing? Defining the problem turns that concern into a clear goal for named users.

Ask questions before choosing a solution

For forgotten homework, ask who needs help, what they forget, and when they need a reminder. Then ask smaller questions: Which subjects? Who enters the due dates? Can students already check a shared board?

The answers may support a paper planner, a classroom board, or an app. Choosing an app first can hide the actual need. Keep the goal narrow enough to finish, such as helping seventh graders see tomorrow’s homework in one place.

Follow information through the solution

For a homework reminder:

This helps you see what information must be available. A reminder cannot choose tomorrow’s assignments if it receives no due dates.

Separate needs from limits

A requirement says what the solution must do: "Show every homework item due tomorrow." A constraint limits the solution: "Run on school tablets," "Cost nothing," or "Be ready in three weeks." Requirements and constraints form the design criteria.

A user story describes a need from someone’s point of view:

"As a seventh grader, I want tomorrow’s homework in one list so that I can plan my evening."

It names the user, the goal, and the reason. A parent might need a weekly summary instead. Those are different stories, even if one solution serves both.

Make success something you can check

"Easy to use" leaves people judging different things. "A student can add an assignment in under 30 seconds" gives a measurable check. "Every item due tomorrow appears in the list" gives another.

Write success criteria before building. For each one, decide what evidence would show it has been met. You could time a student adding an item, then compare the reminder list with a prepared list of due dates.

At the start, the problem definition tells you what work to split into parts. At the end, the same stories and criteria guide testing and evaluation. A broad aim such as "fix homework" needs narrowing before either job is possible.

Decomposition breaks a problem or system into smaller parts. Each sub-problem has a goal you can understand, solve, and check. Combining those smaller solutions completes the larger job.

Build a decomposition tree

Write the whole problem at the top. Under it, name the main parts. Ask whether each part is small enough to solve directly. If it still hides several jobs, split it again.

For "Make a quiz game," the first branches could be:

• Show the questions.
• Check each answer.
• Keep score.
• Show the final result.

The "Check each answer" branch can split further:

• Get the player’s answer.
• Compare it with the correct answer.
• Show "Correct!" or display the right answer.

A decomposition diagram shows these branches as a tree. The lines mean "this is part of that job." They do not show which instruction runs next. An algorithm will supply the order.

Find parts at a useful size

"Make the game" is too large to hand someone as a clear task. "Press a key" is usually too small to deserve its own branch. "Check an answer" has a useful goal, with a short set of steps behind it.

The right size depends on what the team understands. If nobody knows how to handle answers, split that branch until the work is clear. Stop when each part can be solved with a clear step or short algorithm.

Use the same approach away from a screen

A museum trip can have five main parts:

Different people can take responsibility for different branches. Decomposition also works for systems: a bicycle has a frame, wheels, brakes, and gears. Understanding a part helps you locate a repair or improvement.

Check that nothing is missing

Go back to every requirement and user story. Find the branch that serves each one. If a quiz player must see a final score, "Keep score" alone is insufficient: something must display it.

Testing parts separately also narrows the search for errors. If answer checking works but the score is wrong, you can inspect scoring and the connection between them. You do not need to restart every part of the game.

Separate parts need clear connections. One part may produce information that another part needs. A dependency exists when a part needs another part’s result.

Follow outputs into inputs

In a quiz, checking an answer produces "correct" or "incorrect." The scoring part receives that result and updates a number. The result display receives the final score.

Agree on exactly what each part sends and receives:

If one teammate sends the word "five" but another expects the number 5, both parts may work alone and still fail together. Agreeing on the data early prevents that mismatch.

Work out what must be known first

For a trip, collecting payments depends on knowing the cost per student. The bus costs $450. Tickets cost $8 each for 25 students.

1. Ticket cost: 25 times $8 gives $200.
2. Total cost: $450 plus $200 gives $650.
3. Cost per student: $650 divided by 25 gives $26.

Now payments can be collected at the correct amount. Booking transport and designing permission slips can be independent jobs: neither needs the other’s result.

A program part can be built before its supplier is ready. To test a score display, provide a sample score of 4. That checks the display without waiting for the scoring part. When the full game runs, the real score must arrive from scoring.

Combine parts a little at a time

First check each part alone with known inputs. Then connect two parts and check the information passed between them. Add the next part when that connection works.

If scoring accepts a sample "correct" result but fails with the answer checker, inspect their connection. Perhaps one part sends "Correct" while the other expects a different value. Waiting until every part is built makes such problems harder to locate.

Reuse a named set of steps

A subroutine is a named group of steps written once and called when needed. Many languages use the names procedure or function. A quiz can call "Check an answer" for every question.

Recognizing that question 1 and question 2 need the same checking process links decomposition to pattern recognition. The data changes; the steps can stay the same. One shared subroutine also gives you one place to fix a checking error.

Pattern recognition means noticing similarities within a problem or between problems. Repeated steps, matching calculations, and trends in data can suggest a solution you can reuse.

Turn repeated steps into a loop

A drawing sprite makes a square by moving forward 50 steps and turning right 90 degrees. It performs that pair of actions four times:

REPEAT 4 TIMES
  MOVE FORWARD 50 STEPS
  TURN RIGHT 90 DEGREES
END REPEAT

The loop expresses the repeated pair once. Changing the length now requires one edit, without changing eight separate instructions.

Find what changes between cases

A regular polygon has equal sides and equal angles. A sprite drawing one makes a full turn overall: 360 degrees. Divide that turn equally among its corners:

A triangle needs 120 degrees per turn, a square 90 degrees, and a hexagon 60 degrees. The sprite turns through the outside angle at each corner.

Generalization turns this pattern into a rule for many cases. Repeat once per side, moving the chosen length and turning by 360 divided by the number of sides. The values that change can become parameters: inputs to a subroutine such as drawShape(sides, length).

Look for shared calculations

Five movie tickets at $8 each cost $40. Three pizzas at $12 each cost $36. The objects differ, but both use:

One algorithm can receive the count and price as inputs. It does not need a new set of steps for each product.

Patterns also appear in data. The numbers 3, 7, 11, 15 increase by 4. Adding 4 gives the next number, 19. A direct rule gives the value at any position:

Position 1 gives 3. Position 5 gives 19. Position 100 gives 399 without listing the earlier values.

Check the rule before using it

The start 1, 2, 4 can fit different rules. Doubling continues with 8, 16. Adding 1, then 2, then 3, then 4 continues with 7, 11. More examples or a reason for the rule helps decide what pattern is intended.

Abstraction focuses on the information needed for a purpose. It leaves out or hides other details so you can work with a simpler description. You must still be precise about the details you keep.

Let the purpose choose the details

Harry Beck’s 1933 London Underground map showed stations, their order on lines, and places to change trains. Straight lines at a few angles made the routes easier to follow. Station spacing did not show real distances.

That abstraction helps plan a train journey. It cannot reliably tell you how far to walk. A cycling map needs bike lanes and hills. A delivery map needs addresses and one-way streets. A detail can matter for one purpose and be unnecessary for another.

Choose data for a bus seat plan

The goal is to assign suitable seats without booking any seat twice. Start with the details available:

Seat color and the driver’s name do not help make these bookings. Leave them out of this plan.

Now check the smaller description against the goal. Can it identify a free seat, make a booking, and meet access needs? Dropping accessible-seat information would make the description too simple. A student who needs such a seat could receive an unsuitable one.

Describe a whole kind of case

"Jordan’s locker code is 4-7-2" is specific information about one locker. "A locker code has three digits, each from 0 to 9" is general information about the whole kind of code.

There are 10 choices for each digit, including a leading zero:

The possible codes run from 000 to 999. A general code checker needs the three-digit rule, not Jordan’s particular code.

Hide details behind a useful name

A variable named score represents the score’s current value. A subroutine named drawSquare(size) lets you request a square without reading every drawing step. A "Save" button similarly hides the storage steps from its user.

These are levels of abstraction. "Make a quiz game" is high level. "Check each answer" is a smaller, middle-level job. "Compare typed text with the stored answer" is lower level. Decomposition creates the parts; abstraction lets you think about one level without tracking every detail below it.

A model is a simplified representation of a real object or situation. It keeps the features needed to answer a question. A simulation runs a model step by step to explore what happens over time.

Describe a state and rules for change

A model’s state is its values at one moment. Its behavior is the set of rules that changes those values. To build a model:

1. State the question.
2. Choose the quantities to represent and name them.
3. Set their starting values.
4. Write the rules that change them.
5. Run the rules step by step and record the values.
6. Compare predictions with real observations.

Model a phone battery

The battery starts at 80%. Gaming uses 15 percentage points each hour. How many full hours pass before the level drops below 20%?

Each row uses the previous level minus 15. At four hours, the level equals 20%; it is not below 20%. The model therefore allows four full hours before it drops below that level during hour five.

The rule assumes the same use each hour. A brighter screen could use more battery. If the real level after three hours is 30%, the prediction of 35% was too high. The observed average use is:

Try a rule of about 17 percentage points per hour, then test it with new observations.

Model savings

A student starts with $10. Each week, $5 arrives and $2 goes on snacks. The weekly change is $3.

After week 1, the balance is $13. After week 8, it is $34. Headphones cost $40. Week 9 gives $37; week 10 gives $40, so the student can buy them after ten weeks.

This model assumes the weekly income and spending stay fixed. A gift or skipped snack changes the real balance. Assumptions are the conditions the model treats as true; they help you judge when its prediction will be useful.

Choose enough detail to answer the question

A cafeteria-line model needs arrival times and service times to predict waiting. Tray colors do not help with that question. More detail takes more work to build and check, so keep what affects the prediction.

A board game can model traffic without a computer. A spreadsheet can record one row per week. A Scratch simulation can update a pond’s fish count. Each needs a starting state, clear rules, and checks against the situation it represents.

An algorithm is a finite set of precise, unambiguous instructions or rules for a task. It starts clearly, follows a definite order, and finishes with a result. Someone following it should not have to guess the missing details.

Make an instruction precise

"Put peanut butter on bread" leaves several choices open. A clearer version is:

1. Open the jar.
2. Take about one spoonful with the knife.
3. Spread it over one side of one slice of bread.

For a movement task, replace "walk a little way" with "walk 20 steps." For repetition, replace "a few times" with "3 times." In an unplugged task, another person can follow the instructions literally to reveal gaps.

Follow a decision to a result

To find the larger of two numbers:

INPUT a
INPUT b
IF a > b THEN
  OUTPUT a
ELSE
  OUTPUT b
END IF

For 7 and 12, the condition is false, so the output is 12. For 5 and 5, it is also false: the second 5 is output. That still gives the largest value, since both values are equal.

Choose a way to show the steps

In a simple flowchart, an oval or rounded rectangle marks start or end. A rectangle shows processing. A diamond holds a decision, with labeled "Yes" and "No" paths. A parallelogram shows input or output. Arrows show where to go next.

Pseudocode has no single official style. Clear, consistent statements matter because another person must be able to follow the plan. A program expresses algorithms in a programming language a computer can run. The same plan can be carried out in different languages or followed by a person.

Give repetition a way to finish

"Keep stirring" never says when to stop. A loop needs a fixed count or a reachable stopping condition. "Stir for 30 seconds" gives a limit.

A WHILE loop stops when its condition becomes false. A REPEAT UNTIL loop stops when its condition becomes true. The repeated steps must be able to reach that stopping point.

Several algorithms can solve one problem. Directions using stairs and directions using an elevator can both reach a library. Their suitability depends on the user: a student on crutches may need the elevator route.

Algorithms combine three basic structures: sequence, selection, and iteration. Named values keep track of what changes, while subroutines let you reuse a group of steps.

Order and decisions

Sequence carries out steps one after another. Put socks on before shoes. Even correct instructions can fail in the wrong order.

Selection chooses steps using a condition that is true or false. Comparisons include =, <, >, <=, and >=. The last two mean "less than or equal to" and "greater than or equal to."

For movie tickets, under-13s pay $8, people aged 65 and over pay $9, and everyone else pays $12:

IF age < 13 THEN
  SET price TO 8
ELSE IF age >= 65 THEN
  SET price TO 9
ELSE
  SET price TO 12
END IF

Age 12 gives $8. Ages 13 and 40 give $12. Age 65 gives $9. Conditions are checked from the top, and the first true condition chooses the branch. Changing < 13 to <= 13 would wrongly include age 13 in the cheaper group.

Repeat the right steps

Iteration repeats work. A count-controlled loop has a fixed number of repetitions, such as REPEAT 4 TIMES. A condition-controlled loop depends on a changing condition, such as WHILE lives > 0.

Use a fixed count when you know how many repetitions are needed. Use a condition when the number depends on what happens. A repeated pair of drawing instructions can be edited once inside a loop, avoiding separate copies.

Store values with names

A variable stores a value that can change. SET score TO 0 gives a starting value. SET score TO score + 1 reads the current score, adds one, and stores the new score.

Values have data types. An integer is a whole number, such as 42. A string holds text, such as "Ana." A Boolean is true or false.

A constant is a named value that stays the same during a run. CONSTANT MAX_LIVES = 3 makes the limit easy to recognize. Capital letters are a common naming habit, not a universal language rule.

Combine the structures

SET score TO 0
REPEAT 5 TIMES
  SHOW NEXT QUESTION
  INPUT answer
  IF answer = correctAnswer THEN
    SET score TO score + 1
  END IF
END REPEAT
OUTPUT score

The starting value comes before the loop. Only a correct answer changes the score. The final output comes after all five questions. Moving that output inside the loop would show a score after every answer.

Reset the score at the start of each game. Scratch can retain a value from the previous game. Python reports an error if you use a name that has never received a value.

A subroutine such as drawSquare(size) stores reusable steps. The parameter size supplies the changing length. At a call, follow the subroutine with that value, then return to the instruction after the call.

Tracing means following an algorithm by hand, one step at a time. Record the values as they change. A trace table makes it easier to spot where the actual steps stop matching the intended result.

Trace a running total

SET total TO 0
SET n TO 1
WHILE n <= 4
  SET total TO total + n
  SET n TO n + 1
END WHILE
OUTPUT total

Each pass adds the current value of n, then increases n. When n becomes 5, the condition is false. The output is 10, the sum of 1, 2, 3, and 4.

Do not jump straight to the intended answer when tracing. Follow the written steps, including errors. A table is useful because it shows the point where a wrong value first appears.

Choose tests before running them

Testing compares actual results with expected results worked out beforehand. Include:

• Normal data: an ordinary valid input.
• Boundary data: values around an edge where behavior changes.
• Unexpected data: an empty answer, an impossible value, or the wrong kind of input.

For the ticket rule, age 30 should cost $12. Ages 12 and 13 should cost $8 and $12. Ages 64 and 65 should cost $12 and $9. These boundary pairs check both price changes.

Age −5 should be rejected. Without an extra check, age < 13 accepts it and charges $8. A normal test alone would miss this problem.

Find and repair a bug

An algorithm meant to display 1 through 10 says:

SET count TO 1
WHILE count < 10
  OUTPUT count
  SET count TO count + 1
END WHILE

It shows 1 through 9. Once count is 10, the test fails before output. Change the condition to count <= 10, or count < 11. This is an off-by-one error: the loop runs once too few.

To debug, find an input that reliably produces the error. Trace to the first unexpected value. Suggest a cause, change one thing, and repeat that test. Then rerun earlier tests to check that the repair has not broken working behavior.

Explaining each instruction aloud can expose a missing step. The same method works with a classmate following drawing instructions. Passing varied tests increases confidence, but an untried input can still reveal a bug.

A complete plan connects the users’ goal to smaller jobs, useful data, algorithms, and tests. Its stages can overlap. A test that reveals a missing case may send you back to the problem definition or decomposition.

Define a recycling challenge

Homerooms collect cans each school day. The student council needs weekly totals and a winner. A useful story is:

"As a student council member, I want the weekly can totals so that I can announce the winning homeroom on Friday."

Success criteria require each homeroom’s total, the winner, and a tie message whenever several homerooms share the highest total.

Split the work and find shared steps

The main parts are recording daily counts, totaling each homeroom, finding the highest total, and displaying results. Every homeroom needs the same five-day addition. One loop or subroutine can handle that repeated job.

Keep homeroom names and daily counts. The can brands and the people who carry the bags do not affect the totals. That abstraction tells the team what data to record.

Test the plan with a tie

A first algorithm remembers one winner. It replaces that winner only when it finds a greater total. Room 14 replaces Room 12, but Room 15 does not replace Room 14: 61 is not greater than 61. The algorithm misses a required tie.

Fix the design by keeping all names tied for the best total. Start with the first homeroom’s total and name. For each remaining homeroom:

• A greater total becomes the new best, with a new list containing that homeroom.
• An equal total adds that homeroom to the current list.
• A smaller total leaves the list unchanged.

The test now gives Rooms 14 and 15 together. Also plan how zero counts and missing daily entries will be handled. A missing entry must not silently be treated as a known zero.

Record enough for a team to build

Keep the decomposition diagram, named values, algorithms for each part, and tests with expected results. Give team jobs owners and deadlines. A possible timeline is week 1 for planning, week 2 for building parts, and week 3 for combining and testing.

The plan can run on a tally sheet with a calculator, in a spreadsheet, or in Scratch or Python. The method of carrying it out changes; the need for correct totals and fair tie handling stays the same.

Evaluation judges how well a solution meets its problem definition. Use evidence from tests and real users. Record whether each success criterion was met, along with the result that supports that judgment.

Judge the solution against its purpose

A recycling system that adds every total correctly but hides a tie still fails a success criterion. A homework reminder that lists the right items may still be too slow to use. Check each criterion separately.

Ask users to try the solution. A small button or confusing message may reveal a need the team missed. Turn that finding into a clear user story and a measurable check for the next version.

Compare algorithms fairly

Correctness comes first. A quicker algorithm that gives the wrong result is not an acceptable solution. Among correct solutions, compare efficiency and clarity against the project’s needs.

Compare two guessing methods

A secret whole number is from 1 to 100. Each wrong guess receives a truthful "too high" or "too low" hint.

Guessing 1, then 2, then 3, and so on can need 100 guesses. Guessing the middle of the remaining range rules out about half the possibilities each time. It needs at most 7 guesses for this range.

For the secret number 37:

1. Guess 50. "Too high" leaves 1 through 49.
2. Guess 25. "Too low" leaves 26 through 49.
3. The middle is 37.5. Round down and guess 37: correct.

The ranges shrink because each hint removes values that cannot be the secret. Counting guesses gives a simple efficiency comparison.

Choose an improvement that fits

The fastest correct method is not always the best fit for a small team. A slightly slower method may be easier for everyone to understand and change. Consider how much data the solution will handle and what its success criteria require.

Improve in small cycles: design, build, test, evaluate, and revise. Choose the most important problem found, change it, and repeat the earlier tests. If you change several unrelated things at once, a new failure becomes harder to explain.

Record the evidence for each improvement. "The tie test now names both winning rooms" gives a useful result. "It worked once" leaves most of the success criteria unchecked.