I mean, they're great when applied correctly, but someone looking specifically to apply design patterns will often end up CCPing.

Blog posts are too small to provide a lot of information. So in 2021 if you're programming a STM32 you're probably doing something complicated so if its license compatible blah blah etc you're probably/possibly pulling in the whole MBED OS along with include rtos.h and doing everything in separate threads etc.

Which is good for real world projects that are complex enough to benefit from a full featured RTOS.

But its cargo culting if you're literally blinking a LED for a kids toy or similar level of complexity.

The world is full of microcontrollers that do little more than act as timers or do protocol conversion. If you implement a car transmission microcontroller that needs to convert a quadrature motion input to a single canbus thing, if you do it as a raspi with full Debian linux including GUI and 5 layers of middlewear you have seemingly infinite security surface and reliability surface and will never be able to prove its unhackable or even reliable. But if you do a quadrature encoder and canbus interface in, I donno, 50 or so lines of commented C that handle various error conditions and sensor failure conditions, its going to be very easy to prove it works reliably and very difficult if not impossible to hack as one of the 375 microprocessors supposedly installed in every new car. On the other hand the GUI and 5 layers of middlewear might unfortunately be the best way to implement the stereotypically hypercomplicated GUI that new car buyers have come to expect/dread.

Maybe it isn't the case that books work better in making people better programmers, maybe it is the case that those who are more dedicated to learning programming properly, tend to be the same people who grab programming books.

What's funny in tech is corporate cargo culting. You'll see it quite often. Things like "we're a tech company" but there's no distinction between Software Engineering and IT. Or they still see both as a cost center.

Even better, "we're like Google" except they give you a blank stare where you ask about the 20% time, free food, compensation or where they hire from. Turns out it's all bootcamp/local wages no stock, no 20% time. But hey, they have beanbag chairs!

You can see this heavily in the Clojure community, at least in the hn/reddit/slack circles. It gets annoying seeing others think they have some kind of superpower because they use Clojure. I blame Rich Hickey videos since they are heavily in the style of a good salesman.

The Java people have the ISO9000 engineers who are extremely proud of their documented and approved 175 page procedure explaining every detailed step of how its an enormous amount of extra work but technically possible to remove replace and reinstall a 400 Hz power converter.

The Clojure people have the simplicate and add lightness aerospace engineer people who proudly re-engineered the plane's electrical system to not require a 400 Hz power converter anymore, resulting in a lighter, faster, cheaper, more reliable, simpler aircraft. Follow the money... can't sell replacement parts if the plane doesn't use them, so you can guess what corporate thinks of "simplicate and add lightness" designs. Much like in software there's an expanding gap between software people try to sell you vs software you paid to develop for yourself.

The cognitive load on the dev is higher, but its technically possible to write lispy functional style programs in Java if you follow rules about versions and if you drag all the other required complexity of Java into it ... its just simpler to write in Clojure.