3 ms·

I know a good many bad firmware engineers. A few of my theories about why: - Many of them have a concentration in EE, not software. The software they produce i

by kabdib 13y ago

I know a good many bad firmware engineers. A few of my theories about why: - Many of them have a concentration in EE, not software. The software they produce is what you'd expect from an amateur. - A lot of engineers do not spend time to think about the whole stack, from decisions at the hardware level all the way to how the user interacts with the product, and how the factory produces it. The more comfortable you are working in these domains, the better decisions you will be making. Unfortunately, for many firmware engineers their responsibility stops at (say) the USB protocol they've hatched. - Firmware engineering is often seen as a lower-class of programming than desktop. (To this, I say: Ha!) I've sure seen a lot of crappy firmware, much of it from contract houses that specialize in things like BIOS and board packages. They don't seem to hire carefully. If you run across that rare gem who can write desktop apps and UI, write host drivers, write firmware, and use a scope, hang onto that person.

tonyarkles 13y ago
For my bachelors, I did a dual degree in EE and CS, and had a decent programming background before starting. Watching most of my EE colleagues programming was incredibly painful; it was very hack & slash until it works, and then that's it. In EE, we weren't really evaluated on the quality of our code at all, just whether or not the final product worked (as determined by a 'scope or other physical output). My limited EE experience after school (I mostly do higher-level programming these days) reflects this; this is the education they left school with, and they didn't have anyone afterwards to teach them any better. Makes me cringe so hard, knowing what some of these guys are up to now.
jmpe 13y ago
I know a few good firmware engineers. A reason why they, too, produce "crap" is: - Many of them come across hardware errors or suboptimal designs during a later stage in the FW development. In most cases they hack a workaround that doesn't involve a redesign to be able to move on with the next item on the list. Folks higher up the chain of command see this as an excuse to avoid a redesign: "we're not going to do a redesign for that, Mark fixed it in software". Examples: pretty much every ARM System Board out there. - Someone picked a device that was available during the design phase, but went EOL a few months later before production. It happens. - Someone found a cheaper device than originally planned but it doesn't really do what it says on the box. Typically peripheral stuff like ethernet or usb. - And here's the big one: !!Crappy Datasheet!! Some companies, some really really big IC companies produce crap datasheets. Yo get accustomed to the fact that this new Cortex-M µC will probably have an errata or updated datasheet every few months. - the redesign fixed their EMC problem to get the certificate, someone fixed the power supply. But now you get into trouble if you drive this and that device because the voltage takes a dip. But I'd like to add: I agree with your post.
gte910h 13y ago
Mobile programming sucked many desktop/etc capable people out of the market too --iOS guy who came from embedded linux driver land.
svaha1728 13y ago
I'm having the reverse experience. I moved from embedded C++ to writing desktop apps. At my former job, Bjarne's C++ coding standard was required reading. Here, anything goes. The last programmer actually convinced the team the reason his code gave different mathematical results each time it was run was because "floating point math is stochastic".

by kabdib 13y ago

tonyarkles 13y ago

For my bachelors, I did a dual degree in EE and CS, and had a decent programming background before starting. Watching most of my EE colleagues programming was incredibly painful; it was very hack & slash until it works, and then that's it. In EE, we weren't really evaluated on the quality of our code at all, just whether or not the final product worked (as determined by a 'scope or other physical output). My limited EE experience after school (I mostly do higher-level programming these days) reflects this; this is the education they left school with, and they didn't have anyone afterwards to teach them any better. Makes me cringe so hard, knowing what some of these guys are up to now.

jmpe 13y ago

I know a few good firmware engineers. A reason why they, too, produce "crap" is: - Many of them come across hardware errors or suboptimal designs during a later stage in the FW development. In most cases they hack a workaround that doesn't involve a redesign to be able to move on with the next item on the list. Folks higher up the chain of command see this as an excuse to avoid a redesign: "we're not going to do a redesign for that, Mark fixed it in software". Examples: pretty much every ARM System Board out there. - Someone picked a device that was available during the design phase, but went EOL a few months later before production. It happens. - Someone found a cheaper device than originally planned but it doesn't really do what it says on the box. Typically peripheral stuff like ethernet or usb. - And here's the big one: !!Crappy Datasheet!! Some companies, some really really big IC companies produce crap datasheets. Yo get accustomed to the fact that this new Cortex-M µC will probably have an errata or updated datasheet every few months. - the redesign fixed their EMC problem to get the certificate, someone fixed the power supply. But now you get into trouble if you drive this and that device because the voltage takes a dip. But I'd like to add: I agree with your post.

gte910h 13y ago

Mobile programming sucked many desktop/etc capable people out of the market too --iOS guy who came from embedded linux driver land.

svaha1728 13y ago

I'm having the reverse experience. I moved from embedded C++ to writing desktop apps. At my former job, Bjarne's C++ coding standard was required reading. Here, anything goes. The last programmer actually convinced the team the reason his code gave different mathematical results each time it was run was because "floating point math is stochastic".