Plan the project before you write the code

I want to tell you what happens when a student opens their laptop on a Saturday, full of energy, and decides today is the day they finally build the scholarship tracker. They make a new folder. They open main.py. The cursor blinks. They start typing.

Forty minutes later, there are 180 lines, three functions that half-work, a for loop reading a file that doesn't exist yet, and a creeping sense that something is very wrong. They scroll up. They scroll down. They can't remember what the function at the top was supposed to return. They close the laptop and tell themselves they'll come back to it tomorrow. They do not.

I have watched this exact movie maybe a hundred times. The student didn't fail because they couldn't code. They failed because they tried to hold the whole project in their head at once, and a human head can't do that. Most first projects don't die in week three from a hard bug. They die in week one from trying to build the roof before the walls.

The fix is boring, free, and works every time: plan on paper for twenty minutes before you touch the keyboard.

Cooking, essays, chairs

Three quick analogies, because I think they make the point better than any lecture.

A chef doesn't start by turning on the stove. They do mise en place — every ingredient measured, chopped, and lined up in little bowls before anything hits the pan. It looks slow. It's the fastest way to get dinner out without burning the garlic.

A writer doesn't start an essay by writing the first sentence and hoping. They write an outline — three bullets, maybe four — and then the sentences. The outline takes ten minutes. It saves three hours of staring at a paragraph that won't end.

A carpenter doesn't build a house to learn how to build. They build a chair first. Then a stool. Then a table. By the time they're framing a wall, they've practised every joint twice.

Code is the same. Plan first. Build the chair before the house.

Step 1 — Write the steps in English

Before you type any Python, write a numbered list of what your program does. Plain English. The kind a friend who has never coded could read aloud and understand.

For the scholarship tracker, mine looked like this:

1. Read the saved scholarships from a file.
2. Show the user a menu — add, list, quit.
3. If they add, ask for the name, country, and deadline.
4. Save the new scholarship to the file.
5. If they list, print all scholarships in a tidy table.
6. If they quit, stop.

Six lines. No code. No imports. No worrying about json versus csv. Just the shape of the program.

The rule I keep coming back to: if you can't write the steps in English, you can't write them in Python. The Python is the easy part. The hard part is knowing what you want the computer to do. When the English is fuzzy, the code will be fuzzier. When the English is clean, the code almost writes itself.

Step 2 — The smallest version that works

The goal of your first hour is not the finished product. Not a beautiful menu. Not error handling. Not colours in the terminal. The goal of your first hour is a tiny version that does one of the steps on your English list. One.

For the tracker, I'd pick step 5 — listing scholarships — and hard-code a single fake scholarship at the top just so there's something to list.

scholarships = [
    {"name": "Chevening", "country": "UK", "deadline": "2026-11-01"},
]
 
for s in scholarships:
    print(s["name"], "-", s["country"], "-", s["deadline"])

That's the whole program. It runs. It prints something true. It does one of the six steps. Now I pick the next — adding a scholarship from user input. Then the next — saving to a file. Each step is a small win.

The temptation, when step one works, is to stop and polish. Make the print prettier. Add colour. Add a header. Resist. Polishing what isn't finished is how you end up with one shiny step and five missing ones. Get all six rough first. Polish last.

Step 3 — One file is fine, until it isn't

Start in one file. Really. main.py is enough for a project under maybe 150 lines. You don't need a folder structure. You don't need modules.

But there's a moment — and you'll feel it — where one file starts to fight you. You scroll up to find a function and lose your place. You change something at the top and break something at the bottom. The file is doing too many jobs at once: reading data and analysing it and printing it and asking the user questions.

That's the moment to split. Not before. The rough rules I use:

• Past about 150 lines, start thinking about splitting.
• If one file mixes concerns — talking to the user, saving to disk, doing the maths — those are three different jobs, and they want three different files.
• Name each file after what it does. storage.py for saving and loading. ui.py for prompts and prints. main.py for the small program that glues them together.

scholarship-tracker/
├── main.py
├── storage.py
└── ui.py

You don't have to start here. You should end here.

Step 4 — Names, again

I wrote a whole post about naming variables, but the rule extends to files and functions. A function name should be a verb — load_scholarships, save_to_file, show_menu. A file name should be a noun for what it owns or a verb for what it does — storage.py owns the saving and loading; ui.py does the talking.

The quiet test I use: if I can't think of a good name, the boundary is wrong. A function called handle_stuff is doing four things. A file called utils.py is usually a junk drawer. When the name won't come, that's the code telling you to split it again, or merge it back. Listen.

Take this with you

You will be tempted, every single time, to just start typing. The blank file is intoxicating. The plan feels slow, like procrastination dressed up as productivity. It isn't. Twenty minutes with a notebook, writing six lines of English, will save you the Saturday afternoon you'd have spent untangling code that never had a shape. Build the chair. Then the stool. Then, eventually, the house.