Re: Nothing wrong with the chips.
>All a proper dev needs to do his job is
Think a bit. My domains of competence are Python and SQL, along with some more proprietary stuff.
Any time that I want to write fast Python code, I will often think of using dictionaries, aka hashmaps. Now, they are not applicable 100% of the time, but they are very, very fast. The, slow, Python interpreter mostly gets out of the way and calls highly optimized C that's been tuned for years and years. AFAIK the underlying implementation is a B-Tree type algo. A big part of writing fast Python code is knowing which built-in data structures to use to tap into the fast C stuff underneath.
Now, instead of being a lazy shit dev, I could take out my editor (I dislike IDEs, but disagree with you that that shows skill of some sort) and wrangle some C hashmap code myself. Even if I knew C well enough, would my code be as fast as that evolved over years by folk very much smarter than me? I think not.
You're gonna say "Lazy turd, using a scripting language". News to you, modern system languages are evolving towards having more or less built-in maps - Rust, Go, Swift have them. I don't mind system languages, I loved a quick dip into C a while back. But there is a lot of value in providing building blocks on top of even system languages. Who wants to implement a linked list? Who wants to use code with gratuitously hand-written linked lists, unless there is a very very good reason?
That's the power, and costs, of abstractions. I now how, and when, to use a hashmap, but I have little idea of how it is put together. I do know that Python speeds can go up by orders of magnitude when you know the little tricks.
Let's not even get into the abstractions involved with working on top of relational database. A good SQL coder will write stuff that is infinitely faster than a noob. Both have a limited idea, or interest, in knowing the rdbms internals, though the experienced coder will know about indices, NOT IN slowness, full table scans, etc...
Every so often people bemoan that software engineering (hah!) is nothing like say mechanical engineering. Now, by your metrics, does that mean the automotive engineer needs to design his own subcomponents (bolts, drive belts, brakes), each and every time? That would do wonders for both car costs and car quality, would it not?
No, we expect re-use there as well and don't call car engineers out for "just" assembling car components together.