Registered non-governmental non-profit organisation certificate No. 1052p

Articles

Algorithmic thinking: the step before coding

15 min read

Breaking problems down, patterns and abstraction, conditions and loops, pseudocode and flowcharts, simple tasks and tracing by hand, plus practical exercises.

Many people start learning to program by installing a language straight away, then give up at the first error. In fact, a programmer’s core skill is not typing code but turning a task into clear steps that a computer can carry out. This skill is called algorithmic thinking. It comes before any language and stays with you even when you switch languages. In this article we look at what an algorithm is, how to break a problem into parts (decomposition), spot patterns and use abstraction, and how to write step-by-step instructions, using everyday examples: a plov recipe, a morning routine and a queue in a shop. We then cover conditions and repetition, pseudocode and flowcharts, work through finding the largest number, searching and the idea behind sorting, and practise checking an algorithm “by hand”. At the end you will find common mistakes, practical exercises and a checklist. You do not need a computer: paper and a pen are enough.

What an algorithm is and why it matters

An algorithm is a sequence of steps carried out in a set order to reach a result. A good algorithm has four qualities:

  1. Precision. Every step is understood the same way. “Add salt to taste” is fine for a person but not for a computer.
  2. Order. It is clear in which sequence the steps happen. First you boil the water, then you brew the tea, not the other way round.
  3. Finiteness. The algorithm ends at some point. A step such as “stir until ready” needs a clear meaning for “ready”, otherwise the process goes on forever.
  4. Result. At the end there is a definite answer or state: the plov is ready, the largest number has been found, the list is sorted.

A computer is very fast but does not “think” for itself: it does exactly what it is told. A person understands “go and buy some bread” and decides alone which shop to go to, remembers to take money and is careful crossing the road. A computer has to be told every step. That is why most of the difficulty in programming lies not in syntax but in breaking an idea into steps. Our article on getting started with programming makes the same point: the language is a tool, the thinking is the foundation.

Four core techniques: decomposition, patterns, abstraction, algorithm

Algorithmic thinking is usually divided into four techniques. Let us look at them through one example: Dilshod is planning how to host guests on Saturday.

Decomposition: breaking a big problem into parts

“Hosting guests” is a very large and vague task. We split it into smaller parts: clean the house, plan the menu, go to the bazaar, cook, lay the dastarkhan. Each part can be split further: “go to the bazaar” means write a list, take a bag, get to the bazaar, buy the items, come back. The parts should be small enough that you know exactly how to do each one.

Spotting patterns

Looking at the parts, some of them are alike. Chopping carrots, chopping onions, cutting meat: all of these are “wash the item, peel or trim it, cut it to shape”. This is a repeating pattern. Once you spot a pattern, you explain it properly once and afterwards only say “what” changes.

Abstraction: keeping what matters

Abstraction means setting aside unnecessary details and keeping only what matters for the task. When writing a shopping list, the colour of the carrots or the seller’s name does not matter; what matters is what you need and how much. A map is a good example of abstraction: it does not show every tree, only the streets and landmarks.

Algorithm: putting the steps in order

Finally, we arrange all the parts in the right sequence: first the list, then the bazaar, then the cooking. Some jobs can happen at the same time (the carrots are chopped while the meat fries), while others must happen one after another (the zirvak has to be ready before the rice goes in).

Algorithms in everyday life

Algorithms surround us every day; we just do not call them that.

A plov recipe

A recipe is a ready-made algorithm. Let us try to write it more precisely (amounts are illustrative):

  1. Put the kazan on the heat and heat the oil.
  2. Add the meat and fry until browned.
  3. Add the onion and fry until golden.
  4. Add the carrots and fry until soft.
  5. Pour in water, add salt and spices, and simmer the zirvak for a while.
  6. Spread the washed rice evenly and check that the water sits slightly above the rice.
  7. Keep the heat high until the water has boiled off.
  8. Gather the rice into a mound, cover with the lid, lower the heat and let it steam.

Notice the phrases “until browned”, “until soft”, “until the water has boiled off”: this is conditional repetition, where an action continues until a certain state is reached. The check “is there enough water?” is a condition. These are the basic building blocks of programming.

A morning routine

Every day before work, Zarina does the same things: wakes up, washes, has breakfast, gets dressed, checks her bag and leaves. Besides the sequence, there are conditions too: “If it is raining, take an umbrella”, “If the phone battery is low, put the charger in the bag”. Thinking such a routine through once and then following it automatically is a simple way to save time.

A queue in a shop

The queue at the checkout also follows an algorithm: while there are people in the queue, the cashier serves the first customer, that customer leaves, and the next one moves forward. When the queue is empty, the cashier waits. This is a clear example of a loop: “while the queue is not empty, serve the next person”.

Conditions and repetition

Condition: if … else

A condition is a decision. It always starts with a question that can be answered “yes” or “no”:

IF it is raining
    take an umbrella
ELSE
    go out without an umbrella

Conditions can also be nested. For example, Bekzod decides depending on the day: if it is Saturday or Sunday, he rests; otherwise, if it is past 8 o’clock, he calls a taxi; otherwise he takes the bus. When nested conditions pile up, it is best to draw them on paper; otherwise it is easy to lose track of which case leads to which answer.

Repetition: the loop

A loop means doing an action several times. There are two main kinds:

  • Counted loop: you know in advance how many times to repeat: “for each guest, set a plate” (the number of guests is known).
  • Conditional loop: it continues until a condition is met: “wait until the kettle boils”.
FOR EACH guest
    set a plate
    set a spoon

WHILE the kettle has not boiled
    wait

The key question for a conditional loop is: is it guaranteed to end? If the condition never changes (for example, the kettle was never put on the heat), the loop goes on forever. In programs this is a common cause of “freezing”.

Variable: a “box” for a value

Many algorithms need to remember a value: how many customers have been served so far, which number is the largest. For this we use a variable: a named “box” whose contents can change. For example, the cashier first writes 0 in a box called “served” and adds 1 after each customer.

Pseudocode and flowcharts

There are two handy ways to write down an algorithm, and neither is a programming language yet.

Pseudocode

Pseudocode is an algorithm written in plain language but with a strict structure. It uses keywords such as IF, ELSE, WHILE and FOR EACH, and indented lines. The rules are simple:

  • one action per line;
  • actions inside a condition or loop are indented;
  • instead of vague words (“a little”, “to taste”), use an exact condition or number (even an illustrative one);
  • the start and end are clearly visible.

The advantage of pseudocode is that it is easy to translate into any language. When you take your first step in Python, you will see that Python code is very close to pseudocode in its structure.

Flowchart

A flowchart is a picture of an algorithm. The main shapes are:

  • Oval: start and end.
  • Rectangle: an action (“heat the oil”).
  • Diamond: a condition, with two arrows coming out: “yes” and “no”.
  • Parallelogram: input or output (“ask for a number”, “show the answer”).
  • Arrows: the direction of execution.

Drawing a flowchart on paper is the quickest option. If you would rather use a computer, try the free diagrams.net (draw.io) service and the shapes in its Flowchart section: drag a shape from the left-hand panel and pull an arrow from the edge of one shape to another. A loop shows up in a flowchart as an arrow going back to the top of a diamond. If a diamond has an arrow going back but no way out, the loop is endless.

Simple tasks: the largest number, searching, sorting

Now let us apply what we have learnt to some classic tasks. The numbers are illustrative.

Finding the largest number

Task: Nilufar, a teacher, has a list of her pupils’ test scores (for example, 7, 12, 9, 15, 11) and wants to find the highest one. A person can spot it at a glance, but what if the list has five hundred numbers? The algorithm:

largest = first number in the list
FOR EACH number in the list
    IF number > largest
        largest = number
show largest

The idea is simple: we take the first number as “the largest so far” and compare the others with it one by one. If a bigger one turns up, we remember it. Why start with the first number rather than 0? Because if the list contains only negative numbers, 0 gives the wrong answer. That small detail is algorithmic thinking in action.

Searching

Task: Shahnoza, a librarian, is looking for a book title in a list. The simplest method is linear search: check the titles one by one from the start, stop if you find it, and say “not found” if the list runs out.

If the list is in alphabetical order, there is a faster method: binary search. This is how we look up a word in a dictionary: open it in the middle, see whether the word comes earlier or later, and discard half. With each step the search area is halved. But this method only works on a sorted list, which is why sorting matters so much.

The idea behind sorting

There are many sorting algorithms, and one of the easiest to understand is the idea of selection sort. Imagine you are holding pencils of different lengths:

  1. Find the shortest pencil of all and put it on the left.
  2. From the rest, find the shortest again and put it next to the first.
  3. Repeat until no pencils are left.

Did you notice? The first step is the “largest number” task in reverse (finding the smallest). This is pattern reuse: a ready-made solution has become part of a new task. Real programs use faster sorting methods, but this is enough to grasp the idea.

Checking an algorithm “by hand”

The algorithm is written, but is it correct? The most reliable way to find out is to act as the computer yourself and carry it out step by step on paper. This is called tracing with a table.

Let us check the largest-number algorithm with the list 7, 12, 9, 15, 11:

Stepnumbernumber > largest?largest
Start——7
17no7
212yes12
39no12
415yes15
511no15

Answer: 15. Correct. Now try the edge cases, because that is exactly where errors hide:

  • A list with one item (for example, just 5): the answer should be 5.
  • All numbers the same (4, 4, 4): the answer is 4.
  • Only negative numbers (−3, −8, −1): the answer is −1. This is where starting from 0 went wrong.
  • An empty list: what will the algorithm do? This case needs separate handling, such as showing the message “the list is empty”.

An error in a program is called a “bug”, and finding and fixing it is called debugging. Tracing by hand is the first and simplest debugging method: you can do it without a computer and before writing any program at all.

Common mistakes

  • Vague steps. “Wait as long as needed”, “add a little”. A computer will not understand this. Write every step so that it can be measured.
  • Wrong order. Forgetting to set a value before using it: “largest” has not been set yet, but the comparison has already started.
  • Endless loop. Nothing inside the loop changes the condition. For every conditional loop, ask: “what will stop it?”
  • Off-by-one errors. The loop runs one time too many or too few: for example, the last item in the list never gets checked. Tracing with a table shows this quickly.
  • Forgotten edge cases. An empty list, a single item, negative numbers, identical values.
  • Rushing into code. If the idea is not clear, the code will be muddled too. Pseudocode or a flowchart first, code second.
  • Trying to solve everything in one big step. Remember decomposition: if it feels hard, the step is still too big.

Practical exercises and checklist

Write each exercise in pseudocode first, then draw a flowchart for at least one of them and check it by hand with a table.

  1. Making tea. Write making tea as an algorithm of at least 8 steps. Include at least one condition (“if there is no water in the kettle”) and one conditional loop (“wait until it boils”).
  2. Morning routine. Write down your own morning routine and add two conditions that depend on the weather and the day of the week.
  3. The smallest number. Change the “largest number” algorithm so that it finds the smallest. Check it by hand with the list 6, 2, 9, 2, 5.
  4. Counting. Write an algorithm that counts how many pupils in a list of scores (illustrative: 7, 12, 9, 15, 11, 10) scored 10 or more. The counter variable should start at 0.
  5. Searching. Write a linear search algorithm that checks whether the name “Aziz” is in a list of names. Remember the case where the name is not found.
  6. Test it on a friend. Write instructions for folding a paper aeroplane and give them to a friend. They should do only what is written. Wherever they go wrong, that step was written vaguely.

You can also build the exercises from blocks in a free visual environment such as Scratch (scratch.mit.edu): its “if”, “repeat” and “repeat until” blocks match exactly the conditions and loops you wrote on paper.

Checklist

  • The task is broken into small, clear parts.
  • Every step is precise and can only be understood one way.
  • The steps are in the right order, and values are set before they are used.
  • Every condition covers both the “yes” and the “no” case.
  • Every loop is guaranteed to end.
  • The algorithm has been traced by hand with a table.
  • Edge cases have been tested: an empty list, a single item, identical values.

Algorithmic thinking is not only for programmers: it also helps you plan work, write instructions and solve problems in an orderly way. Each day, break one simple task into steps and write them down. In a few weeks it will become a habit, and learning a programming language will be much easier.

If you would like to learn programming systematically with a teacher, take a look at our association’s free programming course and other training programmes. When you are ready, submit an application and our specialists will get in touch.

Back to articles

More articles

14 min read

Using AI tools responsibly at work

What AI chat assistants are good for at work, how to write a good prompt, how to check the output and which data never to type in.

14 min read

Free online learning resources: how to choose

How to choose free online learning resources, judge their quality, avoid scams and actually finish what you start: a table, an example and a checklist.

Start learning today

Enrollment is open. Leave an application — our specialists will contact you and help you choose the right field.

Message us on Telegram