From problem to program: plan, then code

Part of the free LogicWiz Python course, Module 2: Decisions and loops. The examples and practice run in the app.

Meher reads the lab task: read the units used and print the electricity bill. She opens a new file. The cursor blinks. Five minutes later the file is still empty. She knows if and loops; what she is missing is a plan.

You'll learn to

  • Turn a task into input, process and output, and work one example by hand
  • Write the steps as pseudocode, and read the standard flowchart shapes
  • Turn each step of the plan into Python
  • Dry run with a trace table, then test the edge cases

Learn

Six steps, every time

Good programmers rarely start by typing. They follow the same six steps every time, and so can you:

  1. Understand: write down the input (what comes in), the process (the work) and the output (what gets printed).
  2. Example: work one case by hand, with real numbers.
  3. Pseudocode: write the steps in plain English.
  4. Flowchart (optional): draw the steps as shapes and arrows.
  5. Code: turn each step into a line or two of Python.
  6. Test: dry run it (on paper, line by line), then try the edge cases: odd inputs like 0 or a negative.

Steps 1 to 4 happen on paper. By step 5 you are not inventing any more. You are translating.

Steps 1 and 2: input, process, output, and one example by hand

Example 1. Task: read the units used and print the bill. The first 100 units cost ₹3 each, the next 100 cost ₹5 each, and every unit above 200 costs ₹7. Add a fixed charge of ₹50.

Input Process Output
units, a whole number slab maths, then add ₹50 Bill: Rs <amount>

By hand, for 250 units:

  • first 100 units: 100 × 3 = 300
  • next 100 units: 100 × 5 = 500
  • last 50 units: 50 × 7 = 350
  • energy 1150, plus 50 = ₹1200

Now you know exactly what the program must print for 250: Bill: Rs 1200.

Step 3: pseudocode

Pseudocode is your plan written in plain English, laid out like code. There are no strict rules, so you cannot make a Python mistake yet. One line is one step, and indenting shows what belongs inside an IF.

READ units
IF units <= 100
    energy = units × 3
ELSE IF units <= 200
    energy = 100 × 3 + (units − 100) × 5
ELSE
    energy = 100 × 3 + 100 × 5 + (units − 200) × 7
bill = energy + 50
PRINT "Bill: Rs", bill

Check it against your hand example: 250 goes to the ELSE line and gives 1150, then 1200. The plan works before any Python exists.

Step 4: a flowchart, if you want one

A flowchart draws the plan as shapes joined by arrows. Exams ask for them, and there are only five shapes:

Shape Name Holds
Oval Terminal Start or Stop
Parallelogram (slanted box) Input/Output READ units, PRINT bill
Rectangle Process a calculation: bill = energy + 50
Diamond Decision a yes/no question: units <= 100?
Arrow Flow line which step comes next

A diamond has two arrows out, marked Yes and No. Our bill: Start → READ units → units <= 100? → Yes to one rectangle, No to the next diamond → all paths meet at bill = energy + 50 → PRINT → Stop. A loop is an arrow going back up to a diamond.

Step 5: each line of the plan becomes Python

units = int(input())
if units <= 100:
    energy = units * 3
elif units <= 200:
    energy = 100 * 3 + (units - 100) * 5
else:
    energy = 100 * 3 + 100 * 5 + (units - 200) * 7
bill = energy + 50
print("Bill: Rs", bill)

Put it next to the pseudocode: READ became int(input()), ELSE IF became elif, × became *. It prints Bill: Rs 1200, the same as our hand example.

Step 6 starts with a dry run: running the code on paper with a trace table, one column per name. Press Step through and compare:

Line units energy bill Output
units = int(input()) 250
units <= 100? No
units <= 200? No
the else line 1150
bill = energy + 50 1200
print(...) Bill: Rs 1200

Test the edges, not just the example. Most wrong programs work for the number in the question and fail at the edges. Change the input above and try:

  • 0: Rs 50, only the fixed charge
  • the slab borders: 100, 101, 200, 201
  • a big value: 1000 gives Rs 6450
  • a negative: -5 gives Rs 35, which is nonsense!

The plan never said what to do with a negative. Go back to the pseudocode, add IF units < 0 → PRINT "Invalid units" as the first test, and then add it to the code.

Example 2: is it a leap year? The plan

Task: read a year and say whether it is a leap year.

Input: a year. Output: 2024 is a leap year or 2023 is not a leap year. Process: the calendar rule: every 4th year is a leap year, except century years, which must divide by 400.

By hand: 2024 divides by 4: leap. 2023 does not: not leap. 1900 divides by 100 but not by 400: not leap. 2000 divides by 400: leap.

Pseudocode, the strictest test first:

READ year
IF year divides by 400       → leap
ELSE IF year divides by 100  → not leap
ELSE IF year divides by 4    → leap
ELSE                         → not leap

Example 2: the plan in Python

year = int(input())
if year % 400 == 0:
    print(year, "is a leap year")
elif year % 100 == 0:
    print(year, "is not a leap year")
elif year % 4 == 0:
    print(year, "is a leap year")
else:
    print(year, "is not a leap year")

Divides by 400 became year % 400 == 0. Now test it with the four years you worked by hand: 2024, 2023, 1900 and 2000. Your hand answers are your tests. This is the same rule as the one-line condition in Combining conditions; the plan just gave a ladder that is easy to check line by line.

Exams ask you to write an algorithm (numbered steps in plain English), write pseudocode or draw a flowchart for a small task, and to dry run code with a trace table. Use the five standard shapes, and fill in every row of the trace table. The plan earns marks even if one line of code slips. Interviewers like it too: say your plan aloud before you type.

In one line

Plan, then code: input, process, output; one example by hand; pseudocode (a flowchart if asked); Python line by line; then a dry run and the edge cases.