Big O notation , or at least a Big O way of thinking is definitely useful when doing things like optimising queries and data structures etc.

For example I've solved performance issues in the past with DBs with poor indexing strategies (or no index at all). When I read the DB manual and it talks about different types of indexes and says "doing X will cause Y or doing Z will cause A". Knowing something about Big O notation and related things means that I can immediately intuitively understand what they key differences between Y and A would be.

Thinking about performance in terms of growth also helps me guess which parts of the application require the most optimisation. For example which parts have a roughly fixed n and which parts n will grow with time.

Abstractions leak, especially when you are dealing with parallel processing which will become increasingly important as time goes on. How you store and think about your data is going to have huge implications for just about everyone in software in the coming years when having to scale sort operations etc over hundreds of discreet CPU cores becomes the norm.

I think a degree in CS is not intended to teach you "what you will need to be a successful software developer today" but more "here are the tools to think about whatever the problems may be for software developers in 10 years time".

I agree that maybe there is going to be a gap between what is required for a CRUD implementer vs what is required for someone who designs DBMS systems for oracle and that employers want people qualified in the latter to perform the former.

OTOH I feel that this is something that the free market will correct over time and is already beginning to do so. I know a few programmers who are productively employed who are not well versed in CS theory but are still payed well because they can bring other skills to the table.

I'd place a person's debugging skills, their ability to predict bugs, system design, knowledge of common (applicable) libraries (more so knowing when to use them, not method signatures), and perhaps even ethics above algorithms. Probably many more but there's a couple to start. Having never needed to build my own sorting algorithm in 14 years of coding, I'm pretty confident I don't need an engineer who can do that, either.

I've been developing software professionally for 23 years. I have a BSc in Computer Science [1] and an MSc in a computing-related field. And I have never needed to be able to answer questions like these to do my job. I have a vague understanding of big-O notation, and equally vague knowledge of the characteristics of various algorithms like heapsort, but thats all. If I need a sort algorithm then the framework or standard library provides a selection, all written by smarter people than me.

If you are developing a relational database or Google-scale distributed platform then, yes, you probably need to know this stuff. But most developers don't. I have to understand how to capture customer requirements, fit them into systems that already exist, estimate and implement them quickly and reliably, deal with the practical details of IIS or an RDBMS, maintain code, etc. I wonder if the author needs to get out more.

[1] Badly named, I learned little real comp sci.

I'm self taught, and for many years didn't know about algorithms, big-O notation, and similar. You can do a lot of stuff without that knowledge, but there are definitely some areas that require it.

So, in this case, programmers would use this stuff when a sort takes up too much time or too much RAM for what it's meant to do. Then you need to know what big-O is and how to fix it.

It seems a bit odd to spend all this time preparing for things that don't happen every day, but, really, that's what people pay the big bucks for: Someone who can smooth over life's little difficulties, at least in that specific realm.

As for the specific questions: It's definitely good to know big O notation, so maybe I was a bit quick to dismiss the first question. However, a more realistic/useful comparison would be between O(n^2) and O(n log n).

For picking a collection to use – definitely knowing when to use a hash map versus a list. Asymptotic run-time behavior of Quicksort – no. Binary search tree – that's the one example I mentioned in my blog post, so yes, useful. Graphs – never needed in the applications I've worked with. Same for using a heap, never seen/needed.

Disregarding a few years that was mostly WordPress consulting, my experience is largely enterprise C#. Lots of line of business applications, glorified CRUD apps, and some client work. Zero need for any ability to write a BST or radix sort.

If you're working for SpaceX, or Twitter, or a Big 4, of course you should know those things. But most developers don't work for one of those companies. The vast majority of programming is done to further a business other than programming.

Your profile says that you are a web application hacker. I think that explains why you may not feel that data structures or algorithms are important. I was the same way myself (started my programming life by building Perl cgi scripts, made a nice little cms, definitely didn't use any fancy stuff to do that).

You should take it from me though. You will suddenly develop a deep and profound appreciation for understanding algorithms when you have a problem that requires having to comb through over a hundred thousand records, perform some type of operation on them, and sort by the results of that operation - all within a fairly narrow time period.

I think that it actually is a question of problem domains. If you never encounter this type of problem, then not knowing about things like big o notation and the various sorting algorithms will never impact you. However, when you do, that knowledge quickly pays for the time invested in learning it.

99.9% of coders just need to know what things in their chosen language(s) are performance sensitive and what aren't - very few actually need to know the exact reason why. And even fewer need to be able to improve on said algorithms.

If something needs sorting, you call the sort function in the object. There's absolutely no need to know what algorithm it uses, the only thing that matters is that the end result is sorted correctly.

I dont know any of these. I know they exist, i know of the concepts, but no specifics. I would argue that these are good to know, and a must if you are working in a domain where this matters. For design, architecture and implementation in a high level language when the problem do not touch these areas this is not a MUST have.

Does not mean I never used much of this knowledge I have needed at some points. But by that tine I had to refresh the knowledge again...

I find most things in all code to be generic and obvious. The same functions are used by lots of other software with just different names that there's nothing novel.

After you've learned to classify lots of functions with big O notation, you will end up writing things in an obvious way for a base-level optimization that fits naturally.

I concur: Nowadays, the basic building blocks are done. Good sorting, database indexing, O(1) set-membership, many variants of lists, hash tables, and other higher level data structures are well covered by modern libraries. The foundations of modern system design are algorithms and data structures, and they are largely commoditized, for general use. Certainly, working on general purpose, clever-but-foundational algorithms is becomming increasingly niche.

I disagree with the final conclusion that somehow algorithms have faded into obscurity.

Anyone writing any program has to consistently track their expected program performance as it shuffles data between commodotized library calls or between network end points. This is algorithm design. Many "foundational" algorithms like max-flow actually make use of "foundational(er)" algorithms and shuffle data between them.

This is what the modern programmer does when he decomposes a data-intensive problem into sub-problems and uses commoditized libraries and re-composes those solutions.

The push to catalog and archive a wide array of well-implemented algorithms and data structures tracked the emergence of the personal and commodity hardware. The emergence of new hardware will require new solutions. Mobile, webassembly (perhaps), ASIC-based data centers, CUDA, are all exciting new areas where our "foundational" algorithms and canonical solutions need to be revisited, redesigned, and re-tuned. Or at least re-composed.

The part that makes me frustrated enough to comment on this is that I've found that a lot easier to convince a dev who doesn't know Big O that they need to than it is to convince a dev that does know Big O that it's not always necessary. Convincing is significantly harder if the dev graduated from college in the past 3 years.

99% of the things I have built in the past (and continue to build on a daily basis) consist of just gluing things like APIs together, or building user interfaces that essentially just allow users to display and modify data in various databases.

I've had to learn tools like Docker, Git, Travis, Ansible, and Kubernetes. I've had to be able to learn the basics of languages like Javascript and Python and Ruby in a matter of months or even weeks. I've had to pick up frameworks like Angular and React and whatever new shiny thing exists, at the drop of a hat.

I have built large web-based software projects that power multi-million dollar companies, and that handle millions of users on a daily basis.

I don't have a college degree, and my knowledge of advanced math ends at Algebra. But that didn't stop me from assembling and launching a machine learning platform for the company I work for.

But yeah. I don't know shit about algorithms or your "Big O" that you love so dearly and love to judge every "programmer" by.