There are plenty of libraries: from low level hardware abstraction layers to high level libraries like you'd find in the Arduino ecosystem. Those closer to the former (the HALs) require more understanding thus more reading, the latter expose less of the power of the chip because they target the least common denominator.

However, when you're making a mass produced piece of hardware with a $10 BOM cost and it turns out that you can save even 25 cents by using 90% of the power of a cheap chip instead of 5% of the power of an expensive chip, you're going to have to dive down into the documentation to figure out how to get every last ounce of processing power out of the cheaper chip.

That usually means exploiting the unique configuration of peripherals on a chip which can't be cleanly abstracted away by a software library. My first few projects, for example, I had to work around silicon errata in the family of chips the projects had chosen: STM32F4s couldn't run both DMA channels simultaneously at max speed when outputting to different peripherals. I wouldn't have been able to figure out what's going wrong at any level of abstraction without reading the documentation.

That's why I'm now in frontend instead of embedded.

There are many libraries, but the peripherals on modern microcontrollers are wildly configurable and the odds of any particular library supporting every single mode possible is essentially nil. And even if it did, then the library documentation would approach the chip documentation in terms of complexity.

It's obviously exaggerated and reductive, but you have to admit that not knowing how to use React properly is massively prevalent in frontend, let alone being able to recognize _when_ to use React.

I’ve never seen plankton sink a ship or halve its performance but sure. One can only take a metaphor so far.