It’s been sometime since my previous posting. I am getting married next month and have been quite busy accordingly. However, it’s time to get back in the saddle. Algorithms have been the hot topic among my fellow graduates. Both data structures and algorithms are something that are apparently very common among interviewers. Unfortunately, neither of these topics were touched on in our program’s curriculum. Considering many of us have recently began our job searches, and are thus preparing for interviewing, it appears to be in all our interests to tackle this topic.
Let’s begin by defining algorithm. An algorithm is a process that is followed in problem-solving operations. Effectively, it’s a set of instructions that when followed, produce results. Although we did not cover the topic directly, it turns out we’ve been using algorithms all along. Many, if not all, of the methods/functions we had been using were algorithmic. Methods like .sort() or .includes() or .pop() all operate on existing data to provide some kind of result. Each of the previously mentioned methods could be created from scratch in custom methods, but thankfully, that work has been done for us and made a part of the base nature of many programming languages.
Where exactly then am I going with this? While these langauges include many algorithms innately and those do fit the definition of an algorithm, they don’t exactly satisfy what it is we need to know about them. During our time at Flatiron, performance was never really discussed. My very first project took an abhorrently long time to load, I even mentioned it in my technical review, but they didn’t mind much (which is fair as we were just beginning).
With that said, digging into the world of algorithms in the professional environment revealed that performance is king. Performance in our code is most practically determined by the number of operations within the code or more specifically, within a function.
I’m going to pause right here to inform you that I never liked math…
Algorithmic performance in programming is often refered to as Big O notation. There is a crazy amount of information to unpack concerning this topic and I am far too ignorant to adequately explain it.
Here are a handful or articles that you should absolutely check out to understand Big O.
https://en.wikipedia.org/wiki/Big_O_notation
https://www.freecodecamp.org/news/big-o-notation-why-it-matters-and-why-it-doesnt-1674cfa8a23c/
https://web.mit.edu/16.070/www/lecture/big_o.pdf
Ideally, I’ll arrive at a point where the math/logic side of Big O clicks with me a little better. The main takeaway I found was that Big O is a metric by which we as programmers can measure the efficiency, or ineficiency, of the algorithms that we use.
Stay tuned as I have a lot more to discover about this topic.