Skip to content

PROBLEM_SOLVING_GUIDE.md

Latest commit

 

History

History
101 lines (72 loc) · 2.59 KB

PROBLEM_SOLVING_GUIDE.md

File metadata and controls

101 lines (72 loc) · 2.59 KB
Raw
layout default
title Problem-Solving Guide
parent Practice and Projects
nav_order 1
permalink /practice/problem-solving-guide/

Intermediate Problem-Solving Guide

Intermediate problems ask two questions: “Does the code work?” and “Is the design easy to change, test, and operate?” Solve correctness first and improve the design second.

The CLEAR routine

C — Clarify

Rewrite the problem in one sentence. List the input, output, rules, and anything still unknown.

L — List examples

Write at least three cases:

  • one normal case;
  • one boundary case, such as empty input;
  • one invalid or failure case.

E — Explain a plan

Write small numbered steps before code. Decide which responsibility belongs in each function or class and which data structure makes the rule clear.

A — Assemble and assess

Build the smallest working version. Run each planned case. Test behavior rather than internal line-by-line details.

R — Refine

Improve names, remove repetition, separate dependencies, and measure performance only when input size makes it relevant.

Example: group orders by customer

Input:

orders = [
    {"customer": "Asha", "total": 120},
    {"customer": "Ben", "total": 80},
    {"customer": "Asha", "total": 50},
]

Expected shape:

{
    "Asha": [120, 50],
    "Ben": [80],
}

Plan:

  1. Start with an empty dictionary.
  2. Read one order at a time.
  3. Create the customer's list if it does not exist.
  4. Append the total.
  5. Return the dictionary.

Only after this works should you decide whether defaultdict, a dataclass, validation, or a database is useful.

Design questions

Before finishing, ask:

  • Can names reveal the intent without comments?
  • Does each function have one clear responsibility?
  • Is external I/O separated from business rules?
  • Can a test replace the network, clock, or database?
  • What happens for empty, malformed, duplicated, slow, or very large input?
  • Are errors useful to the caller without exposing secrets?
  • Is added complexity solving a real problem?

Performance thinking

Do not guess from code length. Identify the operation repeated as input grows, create realistic data, and measure the whole task. A generator may save memory but can be slower or harder to reuse; concurrency adds coordination cost; a database index speeds some reads but costs storage and write work. Record the trade-off you chose.

Review worksheet

Problem:
Input:
Output:
Rules:
Normal example:
Boundary example:
Failure example:
Plan:
Dependencies:
Tests:
Complexity or performance concern:
What I would improve next: