I believe most times when people hear the word algorithm, they get all riled up and think of an image in their mind of a mathematician solving complex problems. This is generally not true and in this post, I hope to help you see how algorithms are not that foreign to you and how they help us all to solve problems, from the simple to the complex, from the kindergarten teacher to the computer science professor.

What is an algorithm?

Like I said earlier, I believe people generally have a misconception of what an algorithm means. Part of this may be because the word is not common lingo, and it doesn't help either that it's majorly used in the academic sense.

In truth, an algorithm is just

a set of well-defined step-by-step instructions on how to solve a problem or perform a task

Yep, that's pretty much it for algorithms. At its core, that's all it is, it's just a set of instructions on how to solve a certain issue. So the next time you hear the word, don't associate it with math gurus and professors; instead, think of it as something that you use every single day.

How to think in algorithms.

Take a moment to think about how you would go about making a peanut butter sandwich in the morning. It would probably go something like this:

1. Take two slices from the loaf of bread

2. Spread out the peanut butter on a single face of both slices

3. Place the peanut butter-covered faces next to each other

4. We're done.

If we break down this algorithm, you'll notice I took extra care to make sure I was not too vague but specific enough. This is what we mean when we say that an algorithm is "well-defined". Also, an algorithm is ordered and follows a "step-by-step" approach; this means that you generally can't interchange steps in an algorithm.

Let's think of another example. Say you are playing a "guessing game" with your Dave where Dave tells you he is thinking of a number, n, between a and b and asks you to guess the number. A way you could solve this is:

1. Guess a random number (let's call it g) between a and b

2. If g is equal to n, you're done

3. Else, go back to step 1

While this might not be the only or best way to solve the problem, it is a way to solve the problem and is a valid algorithm. That's the beauty of algorithms: you can take different steps and arrive at the same result/solution.

Maximizing the efficiency of algorithms.

Here's a very popular quote (and one of my favorites) in the programming community by the now-deceased Joe Armstrong:

Make it work, then make it beautiful, then if you really, really have to, make it fast. 90% of the time, if you make it beautiful, it will already be fast. So really, just make it beautiful!

The quote above highlights two major stages in the development of algorithms:

• Make it work

• Make it beautiful (efficient)

Your first and most important goal in solving any problem is to find an algorithm that works. Only after it works can the question of optimizing even come in.

All good programming is re-programming.

To make algorithms more efficient, you first need to identify where it is deficient. In our "guessing game" example, say Dave was thinking of a number between 1 and 100, It would likely take you a while to get the answer right. But say whenever you guessed a number, Dave gave you some info about the number you guessed g and the correct number n and told you whether g was lower or higher than n. Can you think of a better algorithm to solve this then? One could be as follows:

1. Guess a random number, g

2. If g is equal to n, you're done

3. Else, If Dave says g is less than n, go back to step 1 but only guess numbers greater than g

4. Else, If Dave says g is greater than n, go back to step 1 but only guess numbers less than g

Using this new approach we can probably find n quicker. But still, random guessing is usually never a good idea in programming. Can you think of an even more efficient algorithm for this problem? Well, I'd argue there's one more we can try.

Let's call the maximum value in the range we will search max and the minimum value we'll search min. Now let's look at another approach.

1. Pick the middle value mid of max and min

2. If mid is equal to n, you're done

3. Else, If Dave says mid is less than n, go back to step 1 but update your min value to your guess, mid

4. Else, If Dave says mid is greater than n, go back to step 1 but update your max value to your guess, mid

The algorithm I just described above is commonly referred to as binary search where you're halving the problem each time.

This is truly a beautiful algorithm and all we did was identify the deficiencies and try to fix them. That's the general process of making algorithms more efficient.

Why should you care as a developer?

Okay, so at this point, you may be thinking: "That's cool and all, but how does this relate to me as a developer?". Well, I'd reply that no matter what kind of developer you are, you will eventually need to start thinking in algorithms and optimizing them.

Algorithms aren't just a topic that should come up in the interview setting. As a developer, if you truly want to master your craft, you should at least try to understand the underlying algorithms. Nowadays, a lot is abstracted and complexities are hidden from us. While this is generally a good thing when you're just starting your career, it becomes a necessity to have a true understanding of the underlying algorithms if you want to be able to create efficient solutions to problems.

Conclusion

And that brings me to the end of my post. I hope I've been able to shine a light on the topic of algorithms and make you see that it's just a fancy word for something you literally do all the time. Of course, the problems discussed in this post were relatively simple and you'll face much harder problems that require a lot of thought to even complete the first step (making it work), I hope that now you can look at that problem with fresh eyes and start thinking in algorithms.