« Many people aspire to “silent success” at work - to do work that “speaks for itself”. Unfortunately this is the wrong move in the theatre of work. Instead we should aspire to the opposite - for knowledge work, the performance of the work is the work. »
Not sure what the author means by “knowledge work”, but I find this very true, for any type of work.
While writing embedded code I realized a major problem with code relative to the rest of the product. You can't see it, can't touch it, and it doesnt appear on the bill of material. To most people it doesnt even exist. This would be somewhat different if your product IS software, but the same still applies to the actual code - the author is the only one who will ever see what they wrote.
Count your blessings. My job involves typically big pieces that are visible to anybody who looks under the hood. And they are often expensive custom pieces, so it's painful to add or modify one.
When stuff is visible and tactile, folks assume that they should intuitively understand it. So my work is subjected to endless critique and brainstorming from everybody, including managers.
Sometimes I envy the embedded systems people because nobody ever looks at the innards of their designs.
>> Sometimes I envy the embedded systems people because nobody ever looks at the innards of their designs.
True, but the flip side is that nobody understands the complexity. Some will assume it must be easy, especially if you keep quiet about the challenges and just deliver mostly good stuff.
To your point, I was working on a hybrid system and one meeting dragged on because marketing was upset that the font was changed on the inverter. It was machined into the case, and they couldn't make the sharp interior angles needed. So yeah, even when you can see it, there may be hidden complexity.
I've actually seen a few customers listing it as such (based on some sales estimate), but it doesn't seem common. Which is a bit weird, especially in cases where you can trade software cost for hardware cost.
One very good reason for putting firmware/software on the BOM is to ensure that the correct version is used in production. Whenever we do a firmware release, part of our process is to update the BOM of whatever product it's for with the firmware revision number.
Not sure what the author means by “knowledge work”, but I find this very true, for any type of work.