I sometimes tell the following joke; "The last time I used an algorithm was in 2002". It's slightly exaggerated admittedly, but there's a point to it, which is very easily understood for anyone having as much experience in the software development profession as I do (25+ years as a professional, and 40 years in total).
80% of the world's software developers will end up working for companies that have software development as a secondary function. This might include insurance companies, banks, hospitals, etc. The reason is because our society has been completely saturated with software development, at every imaginable layer, and there exists very few industries, if any, that can survive without at least some few software developers helping them automate and improve their existing processes, to optimise things, and lubricate business processes.
This implies that 99% of their time they're creating web forms, securely extracting data from a database, maybe invoke an HTTP web API, etc. In this job knowledge about algorithms and data structures are about as useful as a PhD in combustion engine theory is for Michael Schumacher. Axioms such as software design, architecture, composition, etc becomes a bajillion more times important than knowledge about the Big O notation difference between A* and Dijkstra's algorithm. In fact, if you choose Bubble Sort instead of Quick Sort in some method or function, chances are your employer wouldn't even notice.
We don't need data structures, we've got PostgreSQL
The above might sound like a joke, but it's really not. When 99% of your job is to (securely) extract, insert and update data in some database, why would you need to know the difference between Binary Trees and B-Trees? If you persist data in your own structure, in such a way that indexing theory and data structures becomes important, you're probably doing something wrong, and somebody should teach you about the "Not invented here syndrome".
We don't need algorithms, we've got .Net Core
Yet again, the above might sound like a joke, but seriously, assuming you know the difference between O(1) and O(n) - Hint; Dictionaries and Lists - Nobody could care less about your ability to implement Quick Sort. The reason can best be illustrated with some snippet of code ...
List<Customer> customers = /* Some method that returns a bunch of Customers */
customers.Sort();
Using the best sorting algorithm is literally as easy as the above. No need to squeeze your head for the best pivot value.
Having some basic knowledge about algorithms and data structures is still (a little bit) important, for the same reasons that having (a little bit) knowledge about RISC x86 Assembly code is important. Knowing the basics makes you better at understanding the consequences of higher abstractions. But regardless of how many languages you're able to implement Quick Sort in, and how many different data structures you've memorised, chances are with 99% certainty that you will not become a "better employee" for your employer as you start working as a professional. Nobody really cares anymore - It's a mute problem. So the next time you're in a job interview and they ask you about Quick Sort, you should answer ...
Algorithms and data structures? No thx, I'm trying to quit my bad habits ^_^
Yes, in case you are wondering, the above answer will almost with 100% certainty guarantee you that you do not get the job - But then again, who would seriously want to work for such as company anyways ...? ;)
Top comments (5)
I don't understand, how they can be irrelevant? At some point they are implemented anyway, in any system. If you don't do it yourself and just put your confidence in the framework or the tools you're using, that's a thing. But if you just don't care about it, you're only becoming a bad developer that tends to add too much complexity and bad performance on its code because you don't understand anymore what you are doing and what is the real impact of your code.
(of course, when I say "you", I obviously don't speak about you directly ahah)
The higher up in the abstraction layer you move, the less relevant they become. 25 years ago we were much further down in our abstractions, with stuff such as C and C++ being "normal", and often implementing our own serialisation layers for even basic things. Back then knowledge about algorithms and data structures were crucial, just like knowledge about assembly was crucial 20 years before that, and so on.
It's still important to know (some) basic theory about algorithms, but much less so than other knowledge. You do a lot of React development, right? How often do you really need to understand big O notation to maintain your code today? When John Carmack created Doom, he had nothing to build upon. Today those creating games don't even need to know how to multiply two matrices, since they rely upon stuff such as Unity, etc ...
I don't do React ahah. But I see your point.
IMO understanding time complexity is, in fact, mandatory. For example, it is not rare that junior devs write O(N) code around REST requests or SQL queries. Just saying 😂
I also saw someone writing HTML input fields creation with a time complexity of O(N^3) thanks to a wrong understanding of hooks and component lifecycle.
Of course, what is irrelevant is knowing those algorithms by heart. And having to spit them at an interview. 100% with you on that!