I was pretty early in my carreer at the time, working as an engineer, integrating PCS7 in food processing plants across western Europe. Our client had a few stuxnet infections at some point. they immediately put a no usb device policy into place.
Semantics are really important in these situations. We have a system with an E-stop (emergency stop) circuit. Any break in the loop and the system will shut off. It needed to work together with one particular vendors board that insisted on having a "hardware enable" signal that it could control. Rather than adding an additional circuit, someone decided to have "hardware enable" flip a normally open relay in the E-stop circuit. Technically this "works" because enable clears the E-stop condition and allows the thing to function. From a practical point of view this has caused no end of odd problems, particularly when diagnosing issues where things fail because the meaning of this signal has been compromised.
This reminds me of what I've seen happen with the internal health-check endpoint often added to APIs. Simple at first, but eventually there are endpoints to cause the health-check to synthetically fail for deployment purposes; the health-check is also monitoring downstream dependencies; the health-check becomes much more and much less than it was intended to be.
If you're doing three-wire control [0], it also means you can add additional "stop" buttons by wiring them all into the circuit in series.
A nice-to-have addition to your table saw is a big red stop button you can reach with your foot so you don't have to take your hands off of your work pieces to shut the saw down if things have gotten more interesting than you expected them to. Three wire control makes this super easy to add (once you've found the big red mushroom-head n/c switch, of course).
I think for a foot pedal, it'd make more sense to have an enable rather than e-stop. Altough, that also depends on if you only work from one location or many. (Presses in industry often use such a design for hands, so that it ensures you hands aren't in the press.)
OTH the best programmers in the world proudly call themselves 'coders' (the 'demo scene coders'). And TBH, every time somebody calls themselves a 'software engineer' I have to supress some heavy eye rolling, what currently goes as acceptable quality level in software development simply isn't worth calling it 'engineering'.
I’d risk saying that the technical choices most of us here are challenged with are close to the ones Linus faces than to what .theprodukkt deals with in their demos. Irrespective of technical merit, I’d call those of us in the Linus camp “software engineers” but not the demo scene people (whose output is art rather than engineering).
Similarly, the people making game engines are software engineers while the people making games with them are (probably) not, even if they spend just as much time programming.
There’s many roles where your day-to-day work is largely composed of writing code, but only some particular specialisms put robustness and long term maintainability at the top of their priority list. Just because many individual engineers suck at that side of the job doesn’t change the job description.
> every time somebody calls themselves a 'software engineer' I have to supress some heavy eye rolling
I'll always back you on that one. I wish I could make every company I've worked for not call me that. I'd accept literally anything else, but I always liked programmer. Developer seems like a fine compromise, I don't see what's wrong with that. It seems to convey building something potentially multi-faceted or sprawling via a variety of different activities plus programming, but when it comes down to it just by any means necessary.
Software Engineer was bearable if the person was skilled but kinda got its image ruined by being the de facto styling of people fresh out their 6 week React bootcamp
Once, I came across a programmer calling themselves a contractor. I wanted to ask them what they did: hang drywall and install toilets? That's what a general contractor does.
And along the same lines, to most people a developer is someone who buys land and builds houses, not someone who writes and fixes programs. Don't call yourselves that, unless you want people to potentially misunderstand your job.
Programmer is a word that is specific, succinct, and widely understood even by grandmas.
Now, we have individual contributor. That sounds like you gave money to someone's kickstarter project.
Yep, typechecking performance will be drastically improved. Using the trace generator [0], I discovered tsc spent more than three seconds [1] to locate and parse all source files googleapis pulls in during type checking. Replacing it with the individual packages almost completely eliminated that overhead.
So when can I start building on top of webcontainers myself? You seem to be present it as some sort of new browser api, or a library, but from the looks of it it's only the proprietary technology that underpins the stackblitz product.
