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!
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!