How to Think Like a Programmer: Algorithms Explained

When people hear the word algorithm, they often picture green text streaming down a dark screen, complex mathematical equations, or mysterious AI systems deciding what shows up on social media feeds.

In reality, the concept is far simpler, much older, and deeply human.

Before a programmer touches a keyboard, writes a single bracket, or chooses whether to build in Python, Java, or C++, they have to solve the problem in their head. That solution is the algorithm.

On a personal note, I often see courses that teach programming and skip teaching algorithms, and it makes me sad, since I think this is the part that separates a good programmer from a bad or mediocre one.

In my 30 years in software, I saw languages come and go. Many developers who started with languages that are almost forgotten today moved easily to Java, then Python, then whatever came next. The syntax changed. The way of thinking did not.

Even today, with Generative AI like ChatGPT or Claude, where you ask it to do something in a natural language prompt, without using any programming language, the quality of the output will be different depending on whether a programmer or a non-programmer wrote the prompt, for example, a programmer will include requests for validating wrong inputs to the program.

There are three reasons the algorithm matters more:

1. The same algorithm can be written in any language. An algorithm looks almost the same in Python, Java, or JavaScript. Learn it once, use it everywhere.
2. A bad algorithm stays bad in every language. A slow solution written in the fastest language is still slow. A smart solution written in a simple language often wins.
3. AI writes code, but someone must think. Today, tools like Claude and Copilot can write code in seconds. But they need a person who understands the problem, breaks it into steps, and checks that the answer is right. That person thinks in algorithms.

Knowing a programming language makes you a translator. Knowing how to build algorithms makes you a problem solver.

What actually is an algorithm?

An algorithm is a clear, step-by-step set of instructions that solves a problem. You give it some input, it follows the steps, and it gives you an output.

For example, this morning you probably made coffee. You did not think about it much. Boil water. Put coffee in the cup. Add sugar if you like. Pour the water. Stir. If the coffee is too strong, add milk.

Congratulations. You just ran an algorithm.

Or: when you look for a word in a dictionary, you do not start from page one. You open somewhere in the middle, see if your word comes before or after, and jump again. That is an algorithm too, and as we will see later, a very famous one.

Think of it like writing an international bestseller:

• The programming language is like learning French, English, or Spanish. It gives you grammar, punctuation, and vocabulary.
• The algorithm is the plot and logic of the story.

If it still sounds complicated, here are some simple examples of how you develop an algorithm for a problem or task you need to solve.

Drawing the algorithm: flowcharts

Writing steps as a list works well. But when an algorithm has many decisions, "if this, go there, otherwise go here", a list becomes hard to follow.

So, programmers learned to draw their algorithms. This drawing is called a flowchart.

Flowcharts are common in many aspects of planning a software system, from describing a single algorithm to explaining a full system.

Let's start with an example. We'll first describe the algorithm in words, step by step, and then show it as a flowchart.

Example 1: what type of triangle is it?

The problem: someone gives us three numbers, the lengths of three sides of a triangle. We must say what type of triangle it is.

From school we remember three types:

• Equilateral: all three sides are equal (5, 5, 5).
• Isosceles: exactly two sides are equal (5, 5, 8).
• Scalene: all three sides are different (3, 4, 6).

Sounds easy. Most beginners write the three checks and think they are done. But a programmer stops and asks the most important question: what could go wrong?

What if someone types 0, 0, 0? Or -3, 4, 5? Those are not triangles at all.

And what about 1, 2, 10? Try to build it with sticks. The two short sticks together are only 3 long, so they can never reach each other across a stick of 10. That is not a triangle either.

There is a simple rule from geometry: any two sides together must be longer than the third side. This is called the triangle inequality.

Now we can write the full algorithm, step by step:

1. Receive three numbers: A, B, C.
2. If any number is zero or negative, answer "Not a triangle" and stop.
3. If any two sides together are not longer than the third, answer "Not a triangle" and stop.
4. If A equals B and B equals C, answer "Equilateral" and stop.
5. If A equals B, or B equals C, or A equals C, answer "Isosceles" and stop.
6. Otherwise, answer "Scalene."

A little hard to follow, and this is only a 6-step algorithm. Now let's visualize it with a flowchart:

As you can see, the flow of logic in a graphical way is much easier to follow.

The secret of a flowchart is its geometry. Every shape has a fixed meaning, so a reader knows what kind of step it is before reading a single word inside it:

The diamond is the most important shape. It is where the algorithm thinks. Every diamond is one "if" in the code. Count the diamonds and you know how many decisions your algorithm makes.

An algorithm is not just about describing a solution in small steps, but also about finding the most efficient solution. Let's explain it with an example.

Example 2: finding a word in a 1,000-page dictionary

Imagine searching for the word "Momentum" in a physical dictionary containing 1,000 pages.

Algorithm A: linear search (brute force)

1. Turn to page 1. Look for "Momentum".
2. Turn to page 2. Look for "Momentum".
3. Repeat page by page until you find it.

If "Momentum" is on page 500, it takes you 500 page turns. This works, but it's painfully slow.

Algorithm B: binary search (divide and conquer)

Because the dictionary is already sorted alphabetically, an algorithm can exploit that order:

1. Open the dictionary precisely to the middle (page 500).
2. Look at the words. Let's say you see words starting with M, but later alphabetically, like "Music".
3. You immediately know: "Momentum" cannot possibly be in pages 501 to 1,000. You just eliminated 500 pages in one step.
4. Now open the remaining 500 pages right down the middle (page 250).
5. Compare again. Too early? Throw away pages 1–250 and search the middle of the remaining slice.

With this algorithm, a 1,000-page book takes at most 10 checks to find any word. If the dictionary had 1,000,000 pages, the linear method could take a million checks; the binary algorithm finds it in just 20 steps.

That dramatic leap in speed isn't because the computer got faster, it's because the algorithm was smarter.

So far, I've shown some simple examples, and for this article we'll stay at this level. But yes, algorithms can get complicated. Imagine you've got a task to program software to fly a rocket to the moon. Thousands of decisions need to be made for the rocket's course, the amount of fuel, meteorological conditions, and more.

In fact, for complex issues there are people whose entire job is to define algorithms, and they are not necessarily software engineers. they can be physicists or mathematicians, depending on what the solution is all about.

How to think like a programmer

Look back at the examples. The problems were different, but the way of thinking was the same. Here are the habits behind it:

1. Understand the problem before solving it. What exactly goes in? What exactly should come out? Many bugs are born from a problem that was never clearly understood.
2. Break it into small steps. A big problem is scary. Ten small problems are easy. "Classify a triangle" became six simple checks.
3. Ask "what could go wrong?" Zero, negative numbers, an empty list, a huge input. The strange cases are where software breaks.
4. Pay attention to order. Checking "Equilateral" before "Isosceles" was not a detail. It was the difference between right and wrong.
5. Look for a smarter way. The simple way works. The smart way is millions of times faster. Always ask: is there a shortcut?
6. Solve it on paper first. If you cannot explain the steps to a friend in plain words, you are not ready to write code. The code is only the translation.
7. Test it. Try normal cases and strange cases. Do not trust your algorithm until it survives them.

None of these habits require a computer. You can practice them while planning a trip, organizing a closet, or teaching a child to tie shoes.

The takeaway

An algorithm is not a mysterious thing that only geniuses understand. It is simply a clear way to solve a problem, step by step, so that even a very fast and very literal machine can follow it.

The word came from a mathematician in Baghdad 1,200 years ago. The idea is even older. And in the age of AI, when machines write more and more of the code, it matters more than ever. The machine can type. You must think.

So next time you make coffee, look up a word, or search for your keys, stop for a second and ask yourself: what is my algorithm? Could it be smarter?

That is the moment you start thinking like a programmer.