This content originally appeared on DEV Community and was authored by genix

You’ve probably seen and heard the phrase “What is an algorithm?” countless times. Even I have attempted to explain it before. But it has always felt… incomplete to me. I wasn’t just looking for a definition—I was searching for its philosophy. And that’s exactly why it still feels mysterious to me.

Questions like:

Why the word algorithm?
Why is the term so deeply tied to computer science?
Why do algorithms have to be step-by-step?
Why must an algorithm always have an end?
How do we decide if an algorithm is good or bad?
How do we find and choose the right algorithm for a real-world problem?

And most importantly:

Why are all the explanations and articles out there so academic and never truly satisfying?

I’ve had these questions for a long time. And here, I’ll try to share everything I’ve learned so far.

If I get something wrong, I’d love for you to correct me!

What is an algorithm really?

It’s actually very simple. Anything that leads us to a solution is an algorithm.

Let’s say I want to drink coffee. What’s my process?

I have to:

Stand up
Walk to the coffee
Grab a cup
Pour the coffee
Drink it
Done.

That’s an algorithm. I followed a set of steps to reach my goal: drinking coffee.

But here’s the thing—was this an important problem?

Not really.

The point is, algorithms exist everywhere, not just in computer science. They are the processes we use to get things done—whether it’s making coffee, solving a math problem, or navigating through a maze of decisions.

Algorithm definition in CS

But what exactly is the definition of an algorithm in computer science (CS)?

In CS, an algorithm is a sequence of instructions that a computer follows to solve a well-defined problem. It basically tells the computer what to do and how to do it.

Algorithms can instruct a computer on how to:

Perform calculations
Process data
Make decisions

Every program, every function, and every piece of logic in a computer ultimately boils down to an algorithm—a structured, step-by-step approach to solving a problem efficiently.

The story of the algorithm

Alright, so we’ve covered what an algorithm is in CS. But before diving deeper, let’s take a step back—why the heck is it even called an algorithm? Why not Aglagorikhtam or something equally ridiculous?

Well, the story of the word “algorithm” goes back over 1200 years. And believe it or not, it comes from the name of a real person: Muhammad ibn Musa al-Khwarizmi—a Persian mathematician, astronomer, and geographer from the 9th century.

He wrote a book about Hindu-Arabic numerals and computational methods, which was later translated into Latin. And during that translation, his name “Al-Khwarizmi” was adapted as “Algoritmi” in Latin. Eventually, over time, the term evolved into “algorithm”, and now it’s a fundamental concept in computer science.

So, essentially, “algorithm” literally means “a computational method inspired by Al-Khwarizmi”.

But why didn’t we end up with a word like “Aglagorikhtam”?

Well, first of all—because nobody’s name was Aglagorikhtam! And second, back in the day, Latin (the scientific language of Europe at the time) had its own rules for adapting foreign names. If things had gone differently, we might’ve ended up using something like “Al-Khwarizmi-Method” or “Khwarizmi-calculus” instead.

So, the next time you hear the word algorithm, remember—you’re using a term that’s been around for centuries, rooted in the work of an ancient mathematician. Pretty cool, right?

Why is this damn “algorithm” only heard so much in CS?

I mean, isn’t an algorithm just a way to reach a solution? If that’s the case, then every action we take in life is basically an algorithm, right?

When I go eat food, I’m running the “eating algorithm.”
When I play soccer, I’m executing the “soccer-playing algorithm.”

So, why the hell is it that if you ask someone to “explain the soccer-playing algorithm,” instead of answering, they’ll just kick you in the face?! Why is this concept so big in computer science, but in real life, no one seems to care?

Well, the answer lies in the difference between humans and computers.

Humans vs. Computers: The Algorithmic Divide

We, as humans, do a lot of things instinctively. We don’t consciously think in step-by-step instructions all the time. If you’re playing soccer, you’re not going,

Move toward the ball
Adjust foot angle
Calculate optimal force
Execute kick

No! Your brain just does it, automatically, without you having to analyze every tiny step.

But computers? They’re dumb.

They can’t do anything without being explicitly told how to do it. If you don’t give them a crystal-clear step-by-step breakdown, they’ll just sit there like an idiot, waiting for instructions.

This is where computer science (CS) comes into play. Since computers lack intuition, we have to translate our human-level understanding into explicit, unambiguous steps that a machine can actually follow.

For example, if you want to program a robot to play soccer, you can’t just tell it:

“Hey, go play like Messi!”

The robot would just stand there, clueless. Instead, you have to break it down like:

Detect the ball’s position using sensors
Calculate its distance from the ball
Move toward the ball while avoiding obstacles
Determine the best angle and force for a shot
Execute a kick using a precise motor function

See the difference?

A human just plays. A computer needs a structured set of steps.

The Reality: Algorithms Are Everywhere, But We Don’t Notice

The thing is, algorithms do exist in real life, but we don’t think of them as “algorithms” because we internalize them.

For us, “playing soccer” is an intuitive process that happens in our brain.

For a computer, “playing soccer” is a complex problem that needs an explicit solution.

That’s why algorithms in real life are invisible, but in CS, they’re everything. In the world of programming, without an algorithm, a computer is just a useless box of silicon and wires.

Why does the algorithm have to end?

If an algorithm doesn’t have an end, it means you’ve entered an infinite loop. Imagine you’re using Google Maps for directions, and it tells you:

“Turn left”
“Now turn right”
“Now turn around”
“Now turn left again”
And the cycle repeats forever!

Result? You’ll never reach your destination. You’re stuck in an endless loop.

The same thing happens with computers. If you design an algorithm that doesn’t end, your program might never stop. It’ll keep consuming RAM and CPU, eventually making the system freeze or crash. That’s why a good algorithm must have a clear end point. After a certain number of steps, it should produce the final output and terminate.

Think of it this way: when you’re writing an algorithm, you’re essentially talking to a three-year-old kid who has no idea about the world. If you miss a single step or give vague instructions, that kid will get confused and do things wrong. The computer is exactly like that kid, just with the ability to process information at the speed of light! So, if your algorithm doesn’t have a definite end, it will never know when to stop and just keep running, wasting resources.

In the world of algorithms, the end is just as important as the beginning. Without it, you’re just chasing your own tail.

Why are some algorithms approximate, while the definition of an algorithm emphasizes exact answers?

When we define an algorithm, we often say that “the final result should be visible and predictable,” meaning the algorithm should have a defined process that leads to a result we can understand or expect. However, this doesn’t necessarily mean the result must always be exact. What matters is that the algorithm provides a clear and repeatable process that gives us an acceptable solution. But then, a big question arises:

Why are some algorithms approximate instead of exact?

1. Time and resource constraints
Some problems are so complex and computationally heavy that finding an exact solution within a reasonable time frame is impossible. For instance, the Knapsack Problem in its general form is NP-Complete. This means that, to find the exact solution, you’d have to evaluate all possible combinations, which becomes exponentially slow for large inputs. Instead of waiting hours or even years for a solution, we use approximate algorithms or heuristics that provide a “good enough” solution in a much shorter time.

2. Nature of the problem itself
Some problems are inherently non-deterministic, meaning they don’t always have a single, well-defined answer. Even if we write an exact algorithm for these problems, we might not always get a perfect solution. For example, in image processing, algorithms that detect faces can’t definitively say if the face belongs to a particular person. Instead, they provide a high probability that the face matches a known individual. This makes the algorithm approximate, rather than exact, because there’s no single, definitive answer.

3. “Approximate answer” is better than “no answer”
Imagine searching for something on Google, and it tells you: “No results found!” That would be a total letdown! This is why search algorithms, even when they can’t find an exact match, try to offer the best possible result. In situations like this, providing an approximate answer is better than having no answer at all. The algorithm might not give you the exact thing you’re looking for, but it gets you as close as possible, which is often good enough.

4. Randomized algorithms and machine learning
Some algorithms, like randomized algorithms or those based on machine learning, don’t always produce fixed or exact results. For example, a genetic algorithm used to find the optimal path in a network might give you a slightly different solution every time it runs. While it doesn’t guarantee the perfect answer, it’s designed to find a very good solution. In cases like these, the algorithm doesn’t aim for perfection; it seeks a great enough answer that can be applied in a reasonable amount of time, making it useful even in complex, unpredictable environments.

In essence, approximate algorithms are often a pragmatic approach. They acknowledge that, for many real-world problems, finding a perfect solution isn’t feasible, so they aim for the best possible solution within the constraints of time, resources, and uncertainty.

Designing and Understanding Algorithms

Designing an algorithm is like putting together a puzzle—it’s all about breaking down a problem into manageable pieces and figuring out a clear, step-by-step plan to get from the problem to a solution. Here’s how you can do it:

1. Deeply Understand the Problem

Before you write even a single line of code, you need to fully understand what problem you’re trying to solve.

Read the problem carefully.
Identify exactly what you’re looking for.
Ask yourself: What is the problem? What do I want as an outcome?
For example, if you’re trying to find the largest number in a list, you need to know what your input is (a list of integers) and what the expected output should be (the maximum integer in that list). Think of this step as reading the blueprint before you start building a house.

2. Define the Inputs and Outputs

Once you understand the problem, clearly define:

Inputs: What data will you receive? (e.g., an array of integers)
Outputs: What should your algorithm produce? (e.g., the largest number in the array) This step helps avoid any confusion later on—like knowing exactly which ingredients you need before you start cooking.

3. Identify Constraints and Edge Cases

Every problem comes with limitations and special conditions:

Constraints: These might include time limits, memory usage, or specific conditions that the input must meet.
Edge Cases: Consider unusual situations like an empty list, a list with only one element, all elements being the same, or even negative numbers. Handling these cases is like checking all the “what if” scenarios before launching a new product—ensuring your solution works under all circumstances.

4. Choose an Appropriate Algorithmic Technique

There are many techniques to choose from, and the right one depends on the problem:

Greedy Algorithms: Best for optimization problems where making the locally optimal choice at each step leads to a global solution (e.g., coin change problem).
Divide and Conquer: Useful when you can break the problem into smaller subproblems, solve each one, and then combine the results (e.g., Merge Sort).
Dynamic Programming: Ideal for problems with overlapping subproblems where you can store intermediate results (e.g., Knapsack Problem, Fibonacci sequence).
Backtracking: Great for problems where you need to explore all possible solutions, like generating permutations or solving puzzles. Choosing the right technique is like picking the right tool for a job—each tool is best suited for certain types of problems.

5. Develop the Algorithm Step-by-Step

Now that you know what to do, outline the steps of your algorithm:

Break the problem down: Divide it into smaller, manageable parts that are easier to solve.
Write down each step: Clearly describe what happens first, what comes next, and how each step uses the result of the previous one. For example, to find the maximum number in a list:
1. If the list is empty, return a specific value (like None or an error).
2. Assume the first element is the largest.
3. For every other element, if the current element is larger than your assumed maximum, update the maximum.
4. Return the maximum after processing all elements. This is like creating a detailed recipe that even someone with no cooking experience could follow to make a perfect dish.

6. Write Pseudocode or a Flowchart

Translate your step-by-step plan into pseudocode or a flowchart:

Pseudocode: A language-agnostic way of outlining your algorithm that anyone with basic programming knowledge can understand.
Flowcharts: Visual diagrams that show the process flow and decision points. This step helps you ensure that your logic is sound before you get bogged down in coding syntax.

7. Analyze the Algorithm

Evaluate your algorithm for efficiency:

Time Complexity: How does the number of operations scale with input size? (e.g., O(n), O(n log n), etc.)
Space Complexity: How much memory does your algorithm require? For example, a simple algorithm to find the maximum number in a list runs in O(n) time and uses O(1) extra space. This analysis is like stress-testing your solution to make sure it can handle the expected workload.

8. Test the Algorithm

Run your algorithm through a variety of tests:

Normal Cases: Use typical inputs, like a list [3, 1, 7, 4] where the output should be 7.
Edge Cases: Test with empty lists, single-element lists, lists with all identical elements, or lists containing negative numbers. Testing is like taking your car for a test drive on different roads before you decide it’s ready for everyday use.

9. Optimize if Necessary

Based on your tests and analysis:

Refine your algorithm to improve efficiency if it’s too slow or uses too much memory for large inputs.
For simple problems (like finding the maximum number), your initial approach might be optimal, but more complex problems might require rethinking your approach. This is like tuning up a machine to ensure it runs at its best possible performance.

10. Document Your Algorithm

Finally, document your algorithm:

Explain the purpose: What problem does it solve?
List the inputs and outputs: Make it clear for anyone else (or future you) who reads your code.
Describe each step: Provide comments or a separate document that explains the logic behind each step. Documentation ensures that your algorithm can be understood, maintained, and improved upon in the future—just as a well-written manual helps someone use a new gadget correctly.

Remember, designing an algorithm is like solving a puzzle. The clearer your strategy and instructions, the smoother the process—whether you’re guiding a computer or explaining your method to someone else.

Brain Algorithms: A Masterpiece of Divine Engineering

Now, let’s step away from the dry and formal world of computer science and look into the most incredible processor in existence: the human brain.

Have you ever really noticed how your brain makes the best possible decision in the blink of an eye? Imagine you need to descend a flight of stairs. If you’re feeling playful, you might decide to jump over the last three steps. But how does that jump actually happen?

In the span of a few milliseconds, your brain is busy analyzing dozens of variables:

The height you plan to jump.
The speed and angle of your leap.
The strength of your leg muscles and the amount of knee flexion.
The positioning of your arms to maintain balance.
The likelihood of injury based on the landing surface.

Without you even noticing, billions of neurons perform these complex calculations almost instantaneously. They then dispatch precise signals through your nervous system, instructing your muscles to execute the safest and most efficient movement possible. This entire process is a real-time decision-making algorithm—one that has been fine-tuned over millennia.

It’s a stunning example of biological engineering, where every tiny detail is orchestrated perfectly to ensure your survival and well-being. The brain’s algorithms are not written in code, but they work with a level of precision and speed that even the fastest computer programs struggle to match.

So, next time you effortlessly navigate a set of stairs or make a split-second decision, remember: you’re witnessing the extraordinary work of your brain’s built-in algorithms—truly a masterpiece of divine engineering.

Conclusion

Ultimately, algorithms are not just about solving problems, but about finding the best possible solution given the constraints of time, resources, and real-world needs. Choosing the right algorithm can be the difference between a fast and smooth program and a processing nightmare.

And if there’s one thing we should always remember, it’s this: Everything in life is, ultimately, an algorithm.

This content originally appeared on DEV Community and was authored by genix