Why Understanding Algorithms and Data Structures Actually Matters

The code runs, the test you wrote passes, and the page still crawls once the data is real. Nothing in the file looks broken. The order of the steps is, and so is the shape the data sits in. Those two choices decide how expensive a problem gets, and nobody reopens them until the slowdown is already on someone's screen.

About Algorithms

You can write code that runs, passes your quick test, and still uses the wrong tool for the job. Most of the time that tool is an algorithm or a data structure. This article covers why those two matter, with a few small examples.

Informally, an algorithm is the list of steps you follow to get something done. That's all. Nothing special.

The everyday example is printed on the back of an instant noodle package. Boil water, add noodles, wait, add seasoning. Yes, that is an algorithm too.

For a more technical one, take the factorial. You know, the number with an exclamation mark after it.

Now imagine explaining the factorial to someone who has never heard of it. They do understand variables, multiplication and subtraction. With only those tools, you can design an algorithm that produces the answer. It goes roughly like this:

1. Pick the number you want the factorial of and store it in a variable n.
2. Create a variable x with the value 1.
3. Multiply x by n and store the result back in x.
4. Subtract 1 from n and store the result back in n.
5. If n is greater than 1, go back to step 3. Otherwise, return x as the factorial.

That is the algorithm written for humans. A computer needs it in a language it understands, so here it is as Java 21:

public class Factorial {
  static long factorial(int n) {
    long x = 1;
    while (n > 1) {
      x = x * n;
      n = n - 1;
    }
    return x;
  }

  public static void main(String[] args) {
    System.out.println(factorial(5));
    System.out.println(factorial(10));
  }
}

I compiled and ran this on javac 21. It printed:

120
3628800

One small difference from the five steps: the while loop checks n > 1 before the first multiplication, not after. The steps check at the end.

This algorithm is not perfect, and some inputs break it. Negative numbers don't have a factorial, and an int can't hold a fraction, so the code as written does not handle either. An algorithm does not have to be perfect. It has to be good enough for the requirement it serves. If your program only ever asks for the factorial of 5 or 10, you are done.

About Data Structures

If an algorithm is about the steps you take on data, a data structure is about how that data is stored and arranged. The goal is to lay data out so the algorithm has to do as little work as possible.

Take an array and a linked list. An array is contiguous and indexed, so reading item 500 is a jump straight to it. That is O(1) random access. A linked list has to walk its nodes one by one to get there. Same data, different layout, very different work for the same question.

You will usually meet four families:

1. Linear: stored in a line. Examples: array, queue, stack, linked list.
2. Tree: stored in branches, like a hierarchy. Examples: binary tree, heap, AVL tree.
3. Graph: stored as items connected to other items.
4. Hash: stored scattered across slots, using a hash function to pick the slot.

Each structure comes with its own algorithms. You can't pair them at random, because each pairing only works under certain conditions. Algorithm and data structure support each other. Treat them as one unit, not two separate choices.

Why This Matters

The core of programming is choosing the right pair of algorithm and data structure for a problem. That's it. Just pick one, right?

The real answer is not that simple.

Before you can pick the right pair, you need to know what shape your data has and how each algorithm behaves. Only then can you match them to the problem.

Take social media apps like Instagram and Facebook. They share one thing: relationships between users, whether friends, followers or subscribers. If you know data structures, you immediately think graph. Social graphs are the standard example. Each user is a node, and each relationship (friend, follower, subscriber) is an edge.

Knowing the data structure first is a good start. It narrows the list of algorithms you can use. Choosing a data structure is also easier than choosing an algorithm.

Get the pair right and your program tends to be more efficient, easier to scale and easier to read.

Code Efficiency

Efficiency in programming means two things: space and time. Use as little memory as you can, and run as fast as you can. (Yes, we may also destabilize the space-time continuum along the way. Just kidding.)

The usual yardstick is Big O notation. Look it up when you have a minute. For now, it describes how much work an algorithm does as the input grows, usually in the worst case. The right algorithm and data structure are designed to keep that number small.

Here is an example. You are asked to add up the consecutive numbers starting from 1:

Written as a loop, it looks like this. Right next to it is the closed form, n * (n + 1) / 2:

public class SumRange {
  static long withLoop(int n) {
    long total = 0;
    for (int i = 1; i <= n; i++) {
      total += i;
    }
    return total;
  }

  static long withFormula(int n) {
    return (long) n * (n + 1) / 2;
  }

  public static void main(String[] args) {
    System.out.println(withLoop(100) + " " + withFormula(100));
    System.out.println(withLoop(1_000_000) + " " + withFormula(1_000_000));
  }
}

Both versions printed the same answers:

5050 5050
500000500000 500000500000

What I could verify: the two versions agree on those two inputs, on javac 21. I did not test other inputs.

The loop is correct, but it does more work than it needs to. It adds once per number, so it performs n additions. Its complexity is O(n).

The formula is a different story. Whatever n is, it does a constant number of operations and has no loop. Its complexity is O(1), or constant.

Easier Code

Algorithms and data structures often mirror things in the world around you. When you pick the right one, your logic makes sense from the start.

The easy example is the stack. Picture a pile of plates. You take the top one, because that takes the least effort. When you add a plate, you put it on top, for the same reason. A stack works exactly like that: last in, first out.

You use a stack more often than you think. Take the undo feature, the ctrl+z one. Each action you perform goes onto a stack. Each time you press undo, an action comes off, one at a time. Exactly like the pile of plates.

When you write code, picturing something like this helps you understand the problem. Connect it to something you already know, then pick the data structure that fits.

What Next

Nothing in this world is instant, not even making instant noodles.

Learning to program is the same. Knowing a language and its syntax is not enough. You need to know how to solve problems. After that, you still need to learn how to make your solutions efficient. Even that isn't the end, because the field keeps moving and you keep learning.

That's why practice hours matter. The more problems you solve, the better your algorithms get.

Reading other people's code helps too. Everyone thinks differently, and reading how someone else solved a problem shows you alternatives you would not have found alone.

Sites like HackerRank, Sololearn and LeetCode are good places to sharpen this. Try a few problems and read other people's solutions afterward.

Pick one problem this week, solve it, then read someone else's answer to the same problem. Happy coding 👋