Importance of algorithm thinking and problem solving

Are algorithm thinking and problem solving important for a developer?

In the previous “several” years I’ve been working as a software developer, more than once have I been involved in a discussions about algorithms and if they are useful at all and if developers should invest their time into learning algorithms and solving problem tasks. So, I’d like to share my 2 cents.

Arguments for the discussion

The most common points people try to make are:

• Classic algorithm problems very rarely appear in real life situations
• Complex algorithm problems have been solved by others and I can just include their solutions into my code

*both go for standard web and mobile application development. Of course that people in the e.g. game industry or ML do not agree that algorithm thinking is not important. Or, if they do, they should seriously consider a career change.

Because of these points a common conclusion people then make is that knowing algorithms and problem solving is not necessarily important for being a developer.

I cannot (and will not) disagree with either of the points. I do web development for a living and most of the problems I face on a day-to-day basis are CRUD forms and operations.

But I will strongly disagree with the suggested conclusion.

What does “a developer” mean?

People tend to call anyone who can code a developer. We can continue doing this, but I don’t think this is the right approach. Developers should have some sort of levels / classification. And most companies do have that, but it is very often that they use it for salary ranges and hierarchy as opposed to understand who is doing what. So we get different junior developers, mid developers, senior developers, solution architects, system architects…

But the division before that one is, in my opinion, the following: a division into coders and developers.

There are people who choose a language, framework etc. and learn it inside out. They can be amazing at the execution of a given task. But, they require the given task to be really specified into smallest of detail, and then they translate it into clean, well written, commented code. I would call these people coders.

There are people who start from a requirement – what is the point of the given task? What is it that the end client is trying to achieve? After thinking about this, they can think of potential solutions and approaches. If posed with a problem that is unknown to them, they can provide a solution. And then they can translate their idea into clean, well written, commented code. I would call these people developers.

Note the difference: “they require the given task to be really specified into smallest of detail” vs. “If posed with a problem that is unknown to them, they can provide a solution”.

What does this difference entail?

Algorithm thinking makes you think about problems and break them down into smaller problems. It makes you think in “black boxes” (e.g. In order to solve my problem for N boxes, I need to solve the problem for one box and call it N times. I will decide how to solve a problem for one box later). It makes you think about different optimizations. It makes you consider all edge cases etc. Algorithm thinking makes you think about the data structures that will work best with your ideas and solutions, how they can be utilized, reused, extended…

In my opinion, all of these are really important and if you make them a part of your everyday coding routines, you will be a better developer. But there is much more.

In my opinion, if you focus on code, technology, and solving common problems using existing libraries and frameworks, you can get to being very good at what you do. However, if you end up needing to switch e.g. to a different tech stack, you might get into trouble. This primarily happens because the things you know are done in a certain way because “they are done that way in INSERT_FRAMEWORK_HERE“. If you do not invest time into what is happening, what the problem is, what the sequence of operations for it to be solved is and only then approach how it is implemented in the framework, you will never truly understand what you are doing. This will make two things very difficult:

• Switching to a different framework / tech stack
• Handling that one edge case where the existing framework doesn’t cut it

My approach is that I always focus on a problem and how I can break it into smaller problems I can handle. After I do that and have an understanding of that, only then can I check out how best to implement it in a language and/or framework.

And, of course, there are specifics of a language that make some things easier / harder and you can reuse some existing libraries in some language / framework to get a better solution. But, starting from the problem and breaking it down into smaller problems you can solve allows you to approach the whole task with a bigger picture in mind – what the client actually wants and how to achieve it.

Where do algorithm thinkning and problem solving come in?

You can always claim that you take this approach anyway. Why would you ever need to know what a knapsack algorithm is in order to do this?

The answer is: you don’t. The beauty of problem solving is that you get an unknown problem and find a way to solve it. Whether you are going to use some existing known algorithm or use your own is entirely up to you. In the end it is important that it works with a satisfying execution time.

But – this is similar to e.g. writing. In order to write a great book you need to have a big vocabulary. You cannot write a bestseller with a fund of 300 words (though, this book won the Croatian national award Kiklop for the bestseller of the year, and I sincerely doubt its high fund of words!). Chess players train with end-game studies, even though they are pre-composed positions that will never end up happening in a game. But, they provide them with ideas and directions in thinking that they can surely apply to actual games.

It is the same in software development. You don’t need to know the Dijkstra’s algorithm by heart for the purpose of knowing an algorithm. But you do need to be aware of it, and how it works, and what types of problems it solves. So, when you reach a similar problem, you can think about having solved something similar and at least have a good starting point. And then, when you have a good base of algorithms and structures you’re familiar with, you already come prepared with an arsenal of ideas for a wider range of problems.

How to get better at algorithm thinking and problem solving?

How to get to Carnegie Hall? Practice, practice, practice!

There are a zillion sites out there giving you problems for practice. The one I suggest to junior developers is Project Euler. Another, more advanced one is Codility.

And, every year between 1st December and 25th December there is the famous Advent of Code (which I really adore!).

If you follow the recipe from the book Atomic Habits by James Clear, then you can e.g. decide to do one problem from these sites per day, or e.g. 3 in a week. Add the solutions to your personal GitHub profile – this can only help your profile look more active and you landing the potential new job you might be looking for.

Conclusion

This blog post will never end up changing anyone’s mind.

People who agree with it agree with it anyway, regardless whether it was written or not. People who disagree with it stubbornly will keep disagreeing and finding arguments that support their stand. But, if one person dwells on it and starts working on their algorithm thinking and problem solving skills because of it, then it did exactly what it was intended to do.