this post was submitted on 15 Jul 2024
313 points (99.1% liked)
Programming
16977 readers
167 users here now
Welcome to the main community in programming.dev! Feel free to post anything relating to programming here!
Cross posting is strongly encouraged in the instance. If you feel your post or another person's post makes sense in another community cross post into it.
Hope you enjoy the instance!
Rules
Rules
- Follow the programming.dev instance rules
- Keep content related to programming in some way
- If you're posting long videos try to add in some form of tldr for those who don't want to watch videos
Wormhole
Follow the wormhole through a path of communities !webdev@programming.dev
founded 1 year ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
My type is a dying breed too, the guys who do their best to write robust code and actually trying to consider edge cases, race conditions, properly sized variables and efficient use of cycles, all the things that embedded guys have done as "embedded" evolved from 6800 to Pic, Atmel and then ESP platforms.
Now people seem to have embraced "move fast and break things" but that's the exact opposite to how embedded is supposed to be done. Don't get me wrong there is some great ESP code out there but there's also a shitload of buggy and poorly documented libraries and devices that require far too many power cycles to keep functioning.
In my opinion one power cycle is too many in the embedded world. Your code should not leak memory. We grew up with BYTES of RAM to use, memory leaks were unthinkable!
And don't get me started on the appalling mess that modern engineers can make with functional block inside a PLC, or their seeming lack of knowledge of industrial control standards that have existed since before the PLC.
IMO I think that's more a reflection of business decisions rather than innate programmer skill.
Programmers used to do that because they had to do that, so the businesses valued it. Now they don't have to do that, so businesses don't allow them room to develop those skills.
I think that rate that people actually developed unnecessary skills outside of work likely remains the same, just the skills that people desire are different to the ones from back then.
That's a valid point, the dev cycle is compressed now and customer expectations are low.
So instead of putting in the long term effort to deliver and support a quality product, something that should have been considered a beta is just shipped and called "good enough".
A good example I guess would be a long term embedded OSS project like Tasmota, compared to the barely functional firmware that comes stock on the devices that people buy to reflash to Tasmota.
Still there are few things that frustrate me like some Bluetooth device that really shouldn't have been a Bluetooth device, and has non-deterministic behaviour due to lack of initialization or some other trivial fault. Why did the tractor work lights turn on as purple today? Nobody knows!