Translating Everyday Processes into Pseudocode

From Routine to Algorithm: What “Translation” Means

Translating an everyday process into pseudocode means taking something you already know how to do (a routine) and expressing it as explicit, checkable steps that a computer or another person could follow without guessing. The main challenge is not the syntax; it is making hidden assumptions visible: what you start with, what “done” means, what can go wrong, and what choices you make along the way.

In this chapter you will practice a repeatable method for turning real-life tasks into pseudocode solutions that always include at least one decision and one repetition.

1) Identify Inputs, Outputs, and Constraints (I/O/C)

How to extract I/O/C from a real-life task

• Inputs: What information or items must be available before you start? (objects, settings, lists, preferences)
• Outputs: What is produced at the end? (a prepared item, a checked list, a sorted arrangement, a message)
• Constraints: Rules and limitations that affect steps. (time, available tools, safety, user preferences, missing items)

Quick checklist

2) Break the Task into Actions, Decisions, and Loops

Most routines contain three kinds of step:

• Actions: direct steps (measure, pour, open, move, mark).
• Decisions: branching points (if water is not hot, heat it; if an item is urgent, do it first).
• Repetitions: repeated work (stir until dissolved; check each task; sort each item).

A practical way to break down a routine is to write a “messy” numbered list first, then label each line as Action/Decision/Loop. Only after that do you rewrite it as clean pseudocode.

3) Resolve Ambiguity: Conditions and Edge Cases

Everyday language hides ambiguity. Pseudocode must replace vague words with measurable conditions.

Continue in our app.

You can listen to the audiobook with the screen off, receive a free certificate for this course, and also have access to 5,000 other free online courses.

Or continue reading below...

Download the app

Common vague phrases and how to make them precise

Edge cases to look for

• Missing inputs (no tea bags, empty list, unknown category).
• Conflicting constraints (no time to steep, too many tasks for available time).
• Unexpected values (task has no due date, item label is blank).
• Stopping conditions (when does a loop end?).

4) Rewrite to Match Course Conventions

Once your logic is correct, rewrite for consistency. Use the same naming style, consistent indentation, and clear step grouping. Also ensure each solution includes at least one decision and one repetition.

Rewrite checklist

• Use descriptive variable names (e.g., steepMinutes, tasks, categoryMap).
• Replace “and so on” with explicit loops.
• Replace “if needed” with a clear condition.
• Make end states explicit (what is returned/produced).
• Handle at least one edge case (missing item, empty list, unknown category).

Scenario A: Making a Cup of Tea

(1) Inputs, outputs, constraints

• Inputs: teaType (black/green/herbal), hasKettle, waterAmountMl, wantsMilk, wantsSugar, sugarTeaspoons
• Outputs: a prepared cup of tea
• Constraints: target temperature depends on tea type; steep time depends on tea type; cannot proceed if no tea bag/leaf available

(2) Discrete actions, decisions, loops

Actions: fill kettle, heat water, place tea bag, pour water, steep, remove bag, add milk/sugar. Decisions: choose temperature/time by tea type; add milk/sugar only if requested. Loops: wait until water is hot; steep until timer ends; stir sugar until dissolved.

(3) Ambiguity and edge cases to specify

• Define targetTempC and steepMinutes by tea type.
• Define what “water is hot” means: currentTempC >= targetTempC.
• Edge case: tea supply missing.

(4) Pseudocode (includes at least one decision and one repetition)

PROCEDURE MakeTea(teaType, waterAmountMl, wantsMilk, wantsSugar, sugarTeaspoons)  IF NOT TeaAvailable(teaType) THEN    OUTPUT "Cannot make tea: no tea available"    RETURN  ENDIF  IF teaType = "black" THEN    targetTempC <- 100    steepMinutes <- 4  ELSE IF teaType = "green" THEN    targetTempC <- 80    steepMinutes <- 2  ELSE    targetTempC <- 95    steepMinutes <- 5  ENDIF  FillKettle(waterAmountMl)  TurnOnKettle()  WHILE GetWaterTempC() < targetTempC DO    Wait(10 seconds)  ENDWHILE  PlaceTeaInCup(teaType)  PourWaterIntoCup(waterAmountMl)  StartTimer(steepMinutes)  WHILE TimerNotFinished() DO    Wait(10 seconds)  ENDWHILE  RemoveTeaFromCup()  IF wantsSugar THEN    AddSugar(sugarTeaspoons)    WHILE SugarNotDissolved() DO      Stir(3 seconds)    ENDWHILE  ENDIF  IF wantsMilk THEN    AddMilk(10 ml)  ENDIF  OUTPUT "Tea is ready"ENDPROCEDURE

Scenario B: Checking a To-Do List

(1) Inputs, outputs, constraints

• Inputs: tasks (list of task records), currentDate, availableMinutes
• Outputs: updated statuses and a short plan (what to do next)
• Constraints: tasks may have missing due dates; only plan tasks that fit in available time

(2) Discrete actions, decisions, loops

Actions: read tasks, compute urgency, mark complete, build today plan. Decisions: overdue vs due soon vs no due date; include in plan only if time allows. Loops: examine each task; keep adding tasks until time runs out.

(3) Ambiguity and edge cases to specify

• Define “due soon” (e.g., within 2 days).
• Edge case: empty task list.
• Edge case: task missing estimatedMinutes (use default).

(4) Pseudocode (includes at least one decision and one repetition)

PROCEDURE ReviewTodoList(tasks, currentDate, availableMinutes)  IF Length(tasks) = 0 THEN    OUTPUT "No tasks to review"    RETURN  ENDIF  plan <- EmptyList()  remainingMinutes <- availableMinutes  FOR EACH task IN tasks DO    IF task.estimatedMinutes IS MISSING THEN      task.estimatedMinutes <- 15    ENDIF    IF task.status = "done" THEN      CONTINUE    ENDIF    IF task.dueDate IS MISSING THEN      task.priority <- "normal"    ELSE IF task.dueDate < currentDate THEN      task.priority <- "overdue"    ELSE IF DaysBetween(currentDate, task.dueDate) <= 2 THEN      task.priority <- "due_soon"    ELSE      task.priority <- "normal"    ENDIF  ENDFOR  SortTasksByPriorityThenDueDate(tasks)  index <- 1  WHILE index <= Length(tasks) AND remainingMinutes > 0 DO    task <- tasks[index]    IF task.status <> "done" AND task.estimatedMinutes <= remainingMinutes THEN      AddToList(plan, task)      remainingMinutes <- remainingMinutes - task.estimatedMinutes    ENDIF    index <- index + 1  ENDWHILE  OUTPUT planENDPROCEDURE

Scenario C: Sorting Items by Category (Laundry or Pantry)

(1) Inputs, outputs, constraints

• Inputs: items (list of item names or labels), categoryRules (mapping or rule set)
• Outputs: groups (e.g., categories dictionary from category name to list of items)
• Constraints: some items may not match any category; categories should be created as needed

(2) Discrete actions, decisions, loops

Actions: read item, determine category, place item into bin. Decisions: if item matches a rule; if category bin exists; if unknown category then place in “misc”. Loops: process each item; optionally re-check misc items with a second pass.

(3) Ambiguity and edge cases to specify

• Define matching: exact keyword match, prefix match, or lookup table.
• Edge case: blank item label.
• Edge case: duplicate items (allow duplicates or count them).

(4) Pseudocode (includes at least one decision and one repetition)

PROCEDURE SortByCategory(items, categoryRules)  categories <- EmptyMap()  categories["misc"] <- EmptyList()  FOR EACH item IN items DO    IF item IS MISSING OR Trim(item) = "" THEN      AddToList(categories["misc"], "(unlabeled)")      CONTINUE    ENDIF    category <- FindCategory(item, categoryRules)  // returns MISSING if no match    IF category IS MISSING THEN      AddToList(categories["misc"], item)    ELSE      IF categories[category] DOES NOT EXIST THEN        categories[category] <- EmptyList()      ENDIF      AddToList(categories[category], item)    ENDIF  ENDFOR  // Optional second pass: try to reclassify misc items using a broader rule  index <- 1  WHILE index <= Length(categories["misc"]) DO    item <- categories["misc"][index]    category <- FindCategoryUsingBroadMatch(item, categoryRules)    IF category IS NOT MISSING THEN      RemoveAt(categories["misc"], index)      IF categories[category] DOES NOT EXIST THEN        categories[category] <- EmptyList()      ENDIF      AddToList(categories[category], item)    ELSE      index <- index + 1    ENDIF  ENDWHILE  OUTPUT categoriesENDPROCEDURE

Practice Pattern: A Reusable Translation Template

Use this template whenever you convert a routine into pseudocode. It forces you to include decisions and repetitions and to clarify edge cases.

PROCEDURE RoutineName(inputs...)  // 1) Validate inputs / handle missing items  IF someRequiredInputMissing THEN    OUTPUT "Cannot proceed"    RETURN  ENDIF  // 2) Initialize outputs / working variables  result <- ...  // 3) Main loop over items or time  FOR EACH thing IN collection DO    // 4) Decision point(s) with explicit conditions    IF condition THEN      actionA    ELSE      actionB    ENDIF  ENDFOR  // 5) Repetition until a measurable stop condition  WHILE notDone DO    step  ENDWHILE  OUTPUT resultENDPROCEDURE

Mini-Exercises (Each Must Include One Decision and One Repetition)

Exercise 1: Tea customization

• Add a decision for “mug size” (small/large) that changes waterAmountMl.
• Add a repetition that checks temperature every 5 seconds until ready.

Exercise 2: To-do list cleanup

• Add a decision that archives tasks marked done for more than 7 days.
• Add a repetition that continues prompting for the next task to mark done until the user says stop.

Exercise 3: Category sorting with limits

• Add a decision that rejects items that are “expired”.
• Add a repetition that processes items until the input list is empty.