After college/university you begin to forget a lot of the specific textbook stuff and begin to replace it with the put-food-on-your-table practical stuff.
After college/university you begin to forget a lot of the specific textbook stuff and begin to replace it with the put-food-on-your-table practical stuff.
Even in school, Big-O is used almost exclusively, very rarely do you see Big-Omega, Big-Theta, Little-O, etc. Even though in algorithmic analysis these are all used to give a more accurate characterization of the algorithms behavior.
Its funny, too, because the professionals (that are admittedly very smart) that like to talk down about Big-O as if it was a waste of time, seem to not realize there is a whole taxonomy of tools for analyzing and characterizing algorithmic complexity...
"The execution time of algorithm A scales up with the number of items, while algoritm B's is constant."
vs
"The execution time of algorithm A is O(n), while algorithm B's is O(1)."
I've spent so much time trying to chase down bugs caused by junior programmers because something that worked fine with 100 rows in db, slows to a crawl when we move a feature out of beta and we suddenly have 1000 rows.
If they had some idea that the query they were writing was O(n^3) they could have done a quick estimate and saved us all the trouble.
You can learn it in like 30 minutes, and understanding the concept behind it (not just the notation) is the core of understanding why some algorithms work better than others.