How I Learn Algorithms

Also, known as how I learned to stop worrying by thinking like a computer.

Hey all, this week I’m going to keep things simple. I really wanted to learn about some Computer Science but with the holidays moving in things are starting to get real busy. Instead, I’m going to share with you my technique for studying, understanding, and checking algorithms.

I didn’t get this from anywhere but rather developed it organically so if it seems primitive, I’m open to recommendations. Else if it helps you to learn then I’m glad I shared it. I know my handwriting might be gibberish, fingers crossed, maybe Santa will drop me a tablet. I’m also experimenting with ways to do algorithm ‘post-mortems’. I’m playing around with taking pics of a debugger but a picture of my whiteboard is still way more efficient.

The deets of the problem I’ll be using to step through my process with.

In general, I follow this method to solve problems:

• I think about the problem. I break the problem into basic pieces, trimming the fat from what is being asked, and record the pieces in their barest form. If done properly, two different questions describing the same problem will be seen to be composed of the same pieces. This is how we begin to determine the problem-solving patterns we will need.

As in function, strings, arguments, characters

• Pseudocode a solution to each piece of the problem and then combine the pieces of pseudocode. Sometimes this can be multiple functions according to functional programming and sometimes this can be declaring the variables you need, then the loops you need, then defining the conditions of completion. A lot of the time I end up needing to make adjustments because my mind makes a lot of abstractions I’m not consciously aware of.

It’s not perfect, the details will come as you write it and that’s the point

• Whiteboard your pseudocode to test that your logic works out and to make minor adjustments. I will go step-by-step, with sample arguments, taking care to update the state appropriate to only what is written in the pseudocode above. This will often make me aware of the need for more or less variable and conditions. These first three steps make logical problem-solving completely independent of syntax and are a great way of practicing to step through problems like a computer.

Just a sketch. Details and redundancies will appear as you write them.

• Compile your pseudocode into your language of choice, on a whiteboard, taking broad strokes first. Your code doesn’t need to be perfect until it’s in the editor (even then, start with a naive approach initially if that’s the easiest way for you to compile your logic).

Each step I write what the function expressions evaluate to at that point in time. I underline updates.

1. Again, walk through your syntax step-by-step, with sample arguments, taking care to update the state appropriate to only what is written in the syntax you wrote above. This is when a bulk of your work will be done and where you’re most likely to find the syntax errors.

You ever look back at your old projects and wonder what ‘past you’ was thinking? Just wait until the refactor

• Now we’re ready to move to the editor. At this point, you should be able to take the syntax you wrote on the whiteboard and transcribe it to the editor. Be sure to check any assumptions along the way. If your syntax checks out but you get unplanned results, one of your assumptions is wrong. This is where you learn. This is where you check your assumptions. Are your operators expressing the way you expect them to? Are your method arguments in the correct order? And so on.
• Repeat steps 5 and 6 until your algorithm is producing the expected results.

What extra work were you doing?

• Refactor. Repeat steps 1 through 8 and this time, the problem is “How can I simplify my algorithm?” This doesn’t mean you have to refactor. The main point is to spend the time thinking about each piece of your algorithm to determine if that was the most efficient way of thinking about the problem. We tend to construct things in pieces, adding pieces as they are needed.

If index values are the same, move idx1. Always move idx2. If idx1 isn’t at the end of str1 by the time the loop breaks return false. Simply what was asked.

I hoped this was helpful to some of you. Yes, this is a time-consuming process. This isn’t the method to use in an interview when you have 15–30min to solve a problem. This is the method you use to commit patterns to muscle memory and correct flaws in your logical assumptions. Once your assumptions are corrected that logic just becomes an abstraction to be called upon. In an interview, you’ll break the problem down into the ‘objectives’, determine the pattern or patterns to use of the patterns in your mental library of abstractions, and then write the steps of those patterns as pseudocode. Then it’s right to the editor. You’ll be able to do some light logic checking with your interviewer.

If anyone has any comments, suggestions, corrections, resources, or wants to chat, feel free to reach out to me on LinkedIn or down below as a comment. Thanks for sharing your time with me. Until next time.