Coding for 20 years | Working for startups for 10 years | Team leader and mentor | More information about me: https://thevaluable.dev/page/about/
Twitter: @Cneude_Matthieu
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).
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.
Coding for 20 years | Working for startups for 10 years | Team leader and mentor | More information about me: https://thevaluable.dev/page/about/
Twitter: @Cneude_Matthieu
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.
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. π―π
Coding for 20 years | Working for startups for 10 years | Team leader and mentor | More information about me: https://thevaluable.dev/page/about/
Twitter: @Cneude_Matthieu
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.
Coding for 20 years | Working for startups for 10 years | Team leader and mentor | More information about me: https://thevaluable.dev/page/about/
Twitter: @Cneude_Matthieu
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
Coding for 20 years | Working for startups for 10 years | Team leader and mentor | More information about me: https://thevaluable.dev/page/about/
Twitter: @Cneude_Matthieu
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:
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:
Your time complexity is now more something like 0(n).
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.
To be one the safer side it's better to know it. You never know where you land for your first or second job.
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 :)
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. π―π
Agreed. That's what I meant when I was writing:
Great input Matthieu.
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.
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
Logarithmic time is actually faster than linear time. You are of course correct that these differences are meaningful only when the input is big.
Ooops you're right. My bad. I've edited my answer :) thanks!