What Is Pseudocode? How to Write It, With Simple Examples

Pseudocode is a rough draft of a program written in plain, structured language instead of a real programming language. It describes the steps a program should take, in order, without worrying about brackets, semicolons or the exact rules of Python or JavaScript. No computer can run it. Its only reader is a person, usually the one who is about to write the real code.

A first look

Suppose a program should tell a shopper whether they qualify for free delivery. In pseudocode, the logic might read:

1. GET the basket total
2. IF the total is 50 or more THEN show "Free delivery"
3. ELSE work out how much is missing and show "Add X more for free delivery"
4. END IF

Anyone can follow that, including a teammate who has never seen the language the shop is built in. The capital letters on words such as IF, THEN and ELSE are a common convention, not a law. They simply make the decision points stand out from the ordinary actions.

Why programmers sketch before they type

Writing code forces two kinds of thinking at once: what the program should do, and how the chosen language wants it expressed. Beginners often get stuck because the second task swallows the first. Pseudocode separates them. Once the logic is settled on paper, translating it into a language becomes a smaller, calmer job.

• It exposes gaps early. A missing step, such as "what if the basket is empty?", shows up while the plan is still cheap to change.
• It travels between languages. The same outline can become Python today and something else next year.
• It helps conversations. Teachers, classmates and non-programmers can comment on the plan without reading syntax.
• It doubles as comments. Many people paste their pseudocode lines into the file as comments and write the real code underneath each one.

How to write pseudocode in six steps

1. State the goal in one sentence. "Find the highest score in a list" is enough.
2. Name the inputs and outputs. What does the program receive, and what should it hand back or display?
3. List the steps in order. One action per line, written as an instruction: SET, GET, ADD, SHOW, RETURN.
4. Mark decisions and repetition. Use IF / ELSE for choices and FOR EACH or WHILE for loops, and indent whatever sits inside them.
5. Walk through it with real values. Pretend to be the computer and follow the lines with a small example. This is often called a dry run or desk check.
6. Refine the vague lines. Any step that hides a lot of work, such as "sort the list", can be broken down further or turned into its own small routine later.

Two more examples

Finding the highest score

SET highest TO the first score in the list
FOR EACH score in the list
  IF score is greater than highest THEN SET highest TO score
END FOR
SHOW highest

Notice the name highest. It behaves exactly like a variable in programming: a labelled value that changes as the loop runs. Pseudocode already uses the building blocks of real code; it just spells them out in words.

Checking a password length

GET password from the user
WHILE the password is shorter than 12 characters
  SHOW "Please choose a longer password"
  GET password again
END WHILE
SHOW "Password accepted"

The WHILE loop keeps asking until the condition is satisfied. Writing it out this way makes it obvious that the program needs a second GET inside the loop, a detail that is easy to forget when typing real code straight away.

Pseudocode vs flowchart

Both are planning tools, and many courses teach them side by side. They suit different moments.

	Pseudocode	Flowchart
Format	Indented lines of structured text	Boxes, diamonds and arrows
Best for	Detailed step-by-step logic	Seeing the overall flow and branches at a glance
Editing	Quick to change in any text editor	Slower to redraw when the logic shifts
Closeness to code	Very close; lines map to statements	Further away; shapes need translating

A useful habit is to sketch a flowchart when a problem has many branches, then write pseudocode once the shape is clear.

Common slips

• Writing real code by accident. If the outline is full of brackets and exact function names, it has stopped being a plan and become an unfinished program.
• Being too vague. "Process the data" says nothing. Each line should describe an action someone could actually perform.
• Skipping the edge cases. Empty lists, zero values and wrong input types belong in the plan, not in a later bug report.
• Never testing the plan. A dry run with two or three example values catches most logic errors before any code exists.

Questions beginners ask

Is there one official pseudocode syntax?

No. Pseudocode is informal by design. Some textbooks, courses and exam boards publish their own conventions, and when an assignment specifies one, follow it closely. Otherwise, any consistent, readable style works.

Do experienced developers still use it?

Many do, though often informally: a few comment lines describing a tricky function, a numbered plan in a notebook or a quick outline on a whiteboard during a design discussion. The habit of thinking in steps before typing stays useful long after the beginner stage.

What should come after pseudocode?

Turn each line into code, test it, and notice which steps became small reusable pieces. Those pieces usually end up as functions with their own names and inputs. And if progress feels slow, that is normal; learning to code takes a while for nearly everyone, and planning on paper is one of the habits that makes the time count.