You're beginning to sound less of an impostor as days go by Rob!

BTW, I think you might have a typo:

That’s what we’re measuring when we talk about Big O – time complexity, or HOW long something takes given the inputs to an algorithm you’re working with.

Thanks for being awesome!

Deleted.

I really wish you wouldn't have deleted your replies! They're thoughtful and represent sooooo many questions people have on this stuff. I very well could have stated things poorly - I would love a chance to reply! Your comment about building houses was well done - it captures the idea perfectly ... so I'll respond here and hopefuilly you'll undelete.

Two builders might give me a quote to build my house, yes. These quotes are the result of each builder evaluating their process and deciding on a number. They can do that because they've asked me questions and understand the parameters for building my house. These are not algorithms - they're results.

Big O is completely about algorithms! Only code. Only the process itself! So - to use your analogy - I could ask each builder how they're going to build my house. Builder One might say "when we build walls with bricks we lay each one down, then we go through each brick and decide if it's in the best place possible and, if needed, we'll adjust".

The programmer in me would think about this and say HA! Laying the bricks is O(n), but optimizing their placement is O(n^2)!

Builder two might tell me "we lay the bricks once and use more mortar to accomodate spacing problems". That's O(n), since it's one operation/brick.

In terms of pure brick-laying, the second builder always wins. In the Real World, however, yes there are a million things that could make that simply not so! In Big O terms - we only care about the conceptual bits. Big O is a "technical adjective", a way to conceptually grasp the pure efficiency of a routine. In theoretical terms, the first builder will always be less efficient.

Now, to the broader point I think you're trying to make: yes, the first builder will probably build the better wall since they're taking the time to fit things properly. Big O doesn't care about that - it really is just a super abstract way of thinking about efficiency, minus any discussion about reality :).

Hi Matthew - thanks for the note. I would encourage you to embrace the conceptual nature of Big O. I think this is a sticking point for many people as they see performance coinciding with the amount of data - and that's not the case.

> O(log n) is not by definition better than O(n)

By definition O(log n) will *always* have better time complexity than O(n). This is math and there's no skirting that. I think your point, however, is "if I have only have < 10 items it doesn't matter" - which _has nothing to do with Big O_. Big O is a conceptual thing, it's not qualified by the size of data set, which is why we use "n" instead of "10".

> Secondly, what are the values of z, y and x? Sure the shape of the curve for O(log n) is flatter than for O(n) - but what is often interesting is the break even point, which depends on the values of y and z.

In Big O notation there is no concept of z, y and x. It's just conceptual shorthand - so 10 * O(n) is still O(n). You could have a function with 3 loops in it (not nested) and it wouldn't be 3O(n) - it would still be O(n).

Hope this makes sense.

Thanks. In the end I realised my discussion was just muddying the waters of your overall article, so I decided to remove it. But great comments - thanks!