> You should know how to implement a stack, queue, linked list, doubly-linked list, heap, and binary tree.
Not once in the last 20 years have I had to use one of those that wasn't already implemented for me. Nor, I suspect, have most people. It's like requiring a delivery driver to know the internals of engines - completely unnecessary to getting the day to day work done.
I remember in 9th grade there was one kid who complained the entire year about how he would never use algebra. He asked his dad and his dad said he had never used algebra. He must have brought this up 30 times and each time the teacher tried to give practical answers like calculating how much fertilizer or deer feed (we lived in a farming community). He was unswayed. Comically, he gave answers where algebra would be helpful if he knew, but because his dad didn’t know it was difficult (simultaneous solution for cow auction of different types of cows).
Just because you think you haven’t used or didn’t use, doesn’t mean it’s not useful. First, maybe I didn’t use because I didn’t know how to use. Second, maybe there is more to the world than me and the probability of folks needing info is 95% and I’m in the 5% of the lucky/unlucky.
I try to learn things based on curiosity and intrinsic value that I try to estimate. The act of learning is valuable as a system and I’m frequently surprised by putting unlikely topics together.
> First, maybe I didn’t use because I didn’t know how to use.
Alas, I grew up having to code my own data structures and consequently got a thorough grounding in the theoretical and infernal details therein at University.
> Second, maybe there is more to the world than me
You seem to have taken my personal anecdata as some kind of global diktat. I assure you, it most certainly was nothing more than a personal anecdata.
That's funny, I've had to implement a queue, linked list (singly and doubly), heap and binary tree, and other custom data structures that use concepts from all of these in the past month. Depends on what you're working on. If you're writing an engine of some sort, you need to know these things, and often importing third party implementations is neither desired nor worth it. If you're writing business logic, then of course, import some third party lib and do things the quick way.
It's still useful to understand data structures and algorithms on a conceptual level. Even if all you ever do is use premade ones it's going to be nontrivial to pick the correct ones in some cases if you never thought about the costs/benefits they come with.
And I wouldn't call it premature optimization either, just picking sane defaults.
Also...and that's just a personal opinion, I think it's good practice to show an interest beyond black box use when you work with stuff. Poking around in standard libraries can be great fun :D
That depends - it's entirely possible to design and build vehicles using black box engines. What you might mean is "designing an optimal vechicle"? But for most people, they're basically working on simple CRUD stuff which doesn't need to be supra-optimal etc.
(I could make all my internal code supra-optimal, write all my own data structure code, handcraft some assembly, etc. but it would be beyond pointless since 99% of the time it takes to do stuff is in the database server.)
If you didn't understand how an engine worked, you could make drastic mistakes designing the car (and not even talking about making it optimal). Imagine designing a car, but having no idea if the engine is electric or combustion. How are you going to make the rest of the car fit the nuances of the engine?!
You don't need to write the libraries yourself, but you have to know what the library does, and know the internals, and the intended uses of the library. Otherwise, you end up writing your app with an ORM and don't even understand SQL or how a database works, and disaster surely follows.
Not once in the last 20 years have I had to use one of those that wasn't already implemented for me. Nor, I suspect, have most people. It's like requiring a delivery driver to know the internals of engines - completely unnecessary to getting the day to day work done.