Discussion on: Big O Notation for beginners!!

[Matthieu Cneude]

It's not that algorithms are too difficult to learn for beginners, it's more because, in many situations, it's not that useful. Less useful than making your code work, a minimum scalable, and maintainable.

Focusing on performance from the beginning on as often little benefits. Worst: it makes your code more complicated, and you should fight that instead of trying to get back some nanoseconds.

Don't get me wrong. This knowledge is very useful in some scenarios. In 10 years of programming, I didn't saw many.

Another thing: you have to be careful with the O notation because, as you said, it describes the upper bound depending on the input.

To take your example:

const pairs = (n)=> {
    for (var i = 0; i < n; i++) {
      for (var j = 0; j < n; j++) {
        console.log(i, j);
      }
    }
}
pairs(2);

This algorithm is O(n^2) because i and j goes from 0 to n, not because it's a nested loop. For instance, if you have:

const pairs = (n)=> {
    for (var i = 0; i < 2; i++) {
      for (var j = 0; j < n; j++) {
        console.log(i, j);
      }
    }
}
pairs(10);

Your time complexity is now more something like 0(n).

[Djamaile]

Also, it depends for which company you work. I worked for one company where graphs algorithms are a must and I actually used these algorithms. Of course I have also worked for a company where algorithms don’t matter as much.

[Jane Tracy 👩🏽‍💻]

To be one the safer side it's better to know it. You never know where you land for your first or second job.

[Matthieu Cneude]

The problem is: you need to know A LOT of stuff as a software engineer. I don't think big O notation and algorithm is what you should prioritize, at least as a beginner.

Just my opinion of course :)

[Jane Tracy 👩🏽‍💻]

I know you need to learn a lot. But the thing is, you will never stop learning.
Now, that I am learning frameworks, I can add AL on the side.
It's like how you go to coding boot camp, you learn and add extra work by yourself to go deeper.
But it all comes down to the individual and their goals. 💯🌟

[Matthieu Cneude]

Agreed. That's what I meant when I was writing:

Don't get me wrong. This knowledge is very useful in some scenarios.

[Jane Tracy 👩🏽‍💻]

Great input Matthieu.

[Jing Xue]

Focusing on performance from the beginning on as often little benefits. Worst: it makes your code more complicated, and you should fight that instead of trying to get back some nanoseconds.

I agree that over-optimization can be counter-productive. I will say, though, that the kind of performance "optimization" that squeezes out nanoseconds or milliseconds is not the same as algorithm optimizations measured by big-O. The later often actually makes a meaningful difference between whether you can get a result within a reasonable time frame.

[Matthieu Cneude]

It depends on the context. Going from linear time to logarithmic time for example won't bring much, except if your input is very big. Of course, going from factorial time to logarithmic time will do more than improving your execution time, it will allow you to run your algorithm :D

[Jing Xue]

Logarithmic time is actually faster than linear time. You are of course correct that these differences are meaningful only when the input is big.

[Matthieu Cneude]

Ooops you're right. My bad. I've edited my answer :) thanks!