# What is Big-O Notation?

When I started writing *The Imposter’s Handbook*, this was the question that was in my head from the start: *what the f*** is Big O and why should I care?* It took a while but I think I figured it out.

Many people want to qualify the efficiency of an algorithm based on the number of inputs. A common thought is *if I have a list with 1 item it can’t be O(n) because there’s only 1 item so it’s O(1)*. This is an understandable approach, but **Big O is a technical adjective**, it’s not a bench marking system. It’s simply using math to describe the efficiency of what you’ve created.

, always. That means that even if you think you’re looking for is the very first thing in the set, Big O doesn’t care, a loop-based find is still considered O(). That’s because Big O is just a descriptive way of thinking about the code you’ve written, not the inputs expected.

# There You Have It

I find myself thinking about things in terms of Big O a lot. The cart example, above, happened to me just over a month ago and I needed to make sure that I was flexing the power of Redis as much as possible.

I don’t want to turn this into a Redis commercial, but I will say that it (and systems like it) have a lot to offer when you start thinking about things in terms of *time complexity*, which you should! **It’s not premature optimization to think about Big O upfront, it’s **and I don’t mean to sound snotty about that! If you can clip an O() operation down to O() then you should, don’t you think?

So, quick review:

- Plucking an item from a list using an index or a key: O(1)
- Looping over a set of
*n*items: O(*n*) - A nested loop over
*n*items: O(*n²*) - A divide and conquer algorithm: O(
*log n*)