An algorithm is a step-by-step set of instructions that solves a specific problem

An algorithm is not code. It is a plain-language description of how to get from a starting point to an answer. You write it before you write code, the same way a recipe comes before you cook. The algorithm says what to do; the code says how to do it in a particular programming language.

Most algorithms follow the same shape: take in some input, process it through a series of decisions or calculations, and produce an output. A sorting algorithm takes an unsorted list and outputs a sorted one. A search algorithm takes a target value and a collection, and outputs whether the target exists and where. A pathfinding algorithm takes a starting location and a destination, and outputs the shortest route between them.

You do not need advanced math or computer science knowledge to write a working algorithm. You need to think through the problem step by step, test your logic against real examples, and write down what you find. This guide shows you how.

Key Takeaways

  • Write your algorithm in plain language first, not in code, so you can test the logic before you spend time programming.
  • Break the problem into smaller pieces: what input do you have, what output do you need, and what steps connect them.
  • Test your algorithm by hand on paper using real examples, including edge cases like empty lists or negative numbers.
  • Use pseudocode — a mix of English and code-like statements — to bridge the gap between plain language and actual code.
  • Trace through your algorithm line by line with a test case to catch logic errors before you write a single line of real code.

Define the problem and what you are starting with

Before you write a single step, write down what you are solving. Not "sort a list" but "sort a list of student names alphabetically." Not "find a number" but "find whether a specific email address exists in a user database." The more specific you are, the fewer wrong turns you will take.

Next, write down what you have to work with. What is the input? Is it a single number, a list, a string of text, a combination? What format is it in? Can it be empty? Can it contain negative numbers or duplicates? A sorting algorithm that works on a list of five numbers might break on a list of five thousand, or on a list with gaps in it.

Then write down what the output should be. Not just "the answer" but the exact form: a single number, a yes-or-no, a new list, a path, coordinates. If you are sorting, is the output a new list or do you rearrange the original? If you are searching, do you return the item itself or its position in the list?

Break the problem into smaller steps

Write down the steps you would take if you were solving this by hand, without a computer. If you were sorting a pile of index cards by name, what would you actually do? Pick up the first card. Look at the second card. If it comes before the first alphabetically, swap them. Keep going. That is an algorithm — it is just not written in code yet.

Do not jump to the clever solution. Write the obvious one first. The obvious solution is usually easier to understand, easier to test, and easier to code. You can optimize later if you need to. A beginner's sorting algorithm might compare every pair of items and swap them if they are out of order. That is not the fastest way, but it works, and you can trace through it on paper without getting lost.

As you write each step, ask yourself: what information do I need to remember? If you are searching a list, you need to remember which items you have already checked. If you are sorting, you need to remember which items are already in the right place. Write down these pieces of information — they will become variables in your code.

Use pseudocode to test your logic

Pseudocode is a mix of English and code-like statements. It looks like code but reads like English. It lets you test whether your logic works before you write actual code in a real programming language.

Here is an example. Suppose you want to find the largest number in a list. In pseudocode, you might write:

Set largest to the first number in the list For each remaining number in the list   If that number is bigger than largest     Set largest to that number Return largest

This is not Python or JavaScript or Java. It is a description of the steps in a form that is close enough to code that you can spot mistakes. You can read it aloud and ask: does this actually find the largest number? If I have a list of [3, 7, 2, 9, 1], does this work? Start with largest = 3. Check 7: is 7 bigger than 3? Yes, so largest = 7. Check 2: is 2 bigger than 7? No. Check 9: is 9 bigger than 7? Yes, so largest = 9. Check 1: is 1 bigger than 9? No. Return 9. Yes, it works.

Test your algorithm by hand on paper

Before you write code, trace through your algorithm with a pencil and paper using real examples. Write down the state of every variable at every step. This is called tracing, and it catches most logic errors before you waste time coding.

Use at least three test cases: a normal case, a small case, and an edge case. For a sorting algorithm, the normal case is a list of five mixed-up numbers. The small case is a list of two numbers. The edge case is an already-sorted list, or a list with duplicates, or a list with one item, or an empty list. Edge cases are where most algorithms break.

Write down each variable and its value at the start. Then go through each step of your pseudocode and update the variables. If your algorithm says "if X is bigger than Y, do Z," actually check whether X is bigger than Y with the real numbers you are using. Do not skip steps or assume they work. Write it down.

If you find a mistake, fix the pseudocode and trace through again. Do not move to code until your pseudocode works on all three test cases.

Handle the cases that break most algorithms

Certain inputs break algorithms that were not designed to handle them. Think through these before you code:

  • Empty input: What happens if the list is empty, the string is empty, or there is no input at all? Does your algorithm crash or return a sensible answer?
  • Single item: What if there is only one number, one name, one item to search? Does your algorithm still work?
  • Duplicates: If two items are the same, does your algorithm handle them correctly? Does it count them once or twice?
  • Negative numbers or special characters: If your algorithm assumes all numbers are positive, or all characters are letters, what breaks when it encounters the opposite?
  • Already solved: If the input is already sorted, or already contains the target, does your algorithm still work?

For each edge case, trace through your pseudocode. If it breaks, adjust the steps. You might need to add a check at the start: "if the list is empty, return nothing" or "if the list has one item, return that item." These checks are not elegant, but they prevent crashes.

Translate pseudocode into real code

Once your pseudocode works on paper, translating it to a real programming language is mostly a matter of syntax. Each line of pseudocode becomes one or more lines of code. The logic is already tested.

The pseudocode "Set largest to the first number in the list" becomes largest = numbers[0] in Python or int largest = numbers[0]; in Java. The pseudocode "For each remaining number in the list" becomes a for loop or a while loop. The pseudocode "If that number is bigger than largest" becomes an if statement. You are not inventing new logic; you are just writing it in the language's grammar.

Keep your pseudocode comment in the code as you write it. This helps you and anyone else reading the code understand what each section does. It also makes it easier to spot where you went wrong if the code does not work the way you expected.

Frequently Asked Questions

Do I have to write pseudocode, or can I just write code?

You can jump straight to code if the problem is very simple — finding the maximum of three numbers, for example. For anything more complex, pseudocode saves time. Most beginners who skip it spend twice as long debugging code as they would have spent writing and testing pseudocode first. The choice is yours, but pseudocode is the faster route for most people.

What is the difference between an algorithm and a function?

An algorithm is the logic — the steps that solve the problem. A function is a piece of code that runs those steps. One algorithm can be written as a function in Python, a function in JavaScript, and a function in Java. The algorithm is the idea; the function is the implementation in a specific language.

How do I know if my algorithm is efficient?

Start by making sure it works. Once it works, you can think about speed. An algorithm that checks every item in a list one by one is slower than one that cuts the list in half each time, but it is simpler and works fine for small lists. For a beginner, a correct slow algorithm is better than a fast broken one. Learn about Big O notation once you understand how to write algorithms that work.

What if my algorithm does not work on the first test case?

Go back to your pseudocode and trace through it again, step by step, with a pencil. Write down the value of every variable. Most of the time you will spot the mistake in the logic — a step you skipped, a condition you got backwards, or a variable you forgot to update. Fix the pseudocode, test it again on paper, and only then write code.

Can I use someone else's algorithm instead of writing my own?

Yes, for real projects. Libraries and frameworks exist because you do not need to reinvent sorting or searching. But to learn how algorithms work, write your own first. Once you understand how a sorting algorithm works by writing one, you will understand why a library's sorting function is fast and when to use it. Learning comes from doing, not from reading.