It depends on the job though. I do Java backend transaction processing so our team always needs to understand a basic understanding of runtime (and memory usage) when we code. It's mostly basic things like why something is 'faster' then O(n2). Sometimes to reduce runtime, we cache, but then we have to consider the size of the cache, etc
That being said, for front-end web dev, I don't think I've ever had to ever think about it.
Yes, I think the key point is that after some good or bad experiences, most developers will have an implicit knowledge that helps deciding on how to program something and when something’s very slow to find out why.
That said, I’ve probably used it a lot of times. But I never wrote down or talked explicitly about O().
And by the way, I was a java Backend developer for most of my time and just recently started in the frontend as well.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
It depends on the job though. I do Java backend transaction processing so our team always needs to understand a basic understanding of runtime (and memory usage) when we code. It's mostly basic things like why something is 'faster' then O(n2). Sometimes to reduce runtime, we cache, but then we have to consider the size of the cache, etc
That being said, for front-end web dev, I don't think I've ever had to ever think about it.
Yes, I think the key point is that after some good or bad experiences, most developers will have an implicit knowledge that helps deciding on how to program something and when something’s very slow to find out why.
That said, I’ve probably used it a lot of times. But I never wrote down or talked explicitly about O().
And by the way, I was a java Backend developer for most of my time and just recently started in the frontend as well.