DEV Community πŸ‘©β€πŸ’»πŸ‘¨β€πŸ’»

Discussion on: Big O Notation for beginners!!

Collapse
phantas0s profile image
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).

Collapse
djamaile profile image
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.

Collapse
tracycss profile image
Jane Tracy πŸ‘©πŸ½β€πŸ’» Author

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

Thread Thread
phantas0s profile image
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 :)

Thread Thread
tracycss profile image
Jane Tracy πŸ‘©πŸ½β€πŸ’» Author

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. πŸ’―πŸŒŸ

Collapse
phantas0s profile image
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.

Collapse
tracycss profile image
Jane Tracy πŸ‘©πŸ½β€πŸ’» Author

Great input Matthieu.

Collapse
jingxue profile image
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.

Collapse
phantas0s profile image
Matthieu Cneude • Edited on

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

Thread Thread
jingxue profile image
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.

Thread Thread
phantas0s profile image
Matthieu Cneude

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