YES PLEASE, WHERE DO I SIGN.
144 karma · joined May 7, 2017
(For the uninitiated: https://youtu.be/9eyFDBPk4Yw )
("Make a problem that is ridiculously expensive unless you have a hint... in which case, it's a total breeze" is a foundational task in crypto)
Glad to see this now :)
If it helps, ^^have a brochure explaining all of the ways folks are dramatically misunderstanding us right now. :(
(P.s. don't ask any questions that they don't like, that would be Un-American).
Emphasis on "licensed" as in "you need to complete an ABET-accredited program and pass a licensure exam and complete continuing education courses to practice, because there are standards and regulations to prevent accidents".
The phrase "regulations written in blood" also comes to mind.
(Plot twist: You can get kindergarteners to "read" via sightwords, when they might otherwise only be intellectually-mature enough to do so (for real) starting in 1st-2nd grade... but the shortcuts catch up with folks when they hit ~4th-5th grade reading comprehension).
Please do.
1. Licensure 2. Bonding 3. Malpractice insurance 4. Unions
Every single other respectable engineering specialty is licensed, bonded, and insured. Most have local unions as well.
We are not going to stop dealing with the bootcamp script-kiddie middle-manager-with-an-LLM slopcode until we have an efficient way to confer proof-of-skills during the hiring process. It shocks me that ABET discontinued the PE exam subspecialty for software engineering due to lack of interest. Maybe we'll get smart enough to circle back and demand it.
Next is bonds. Large high-dollar government projects that take years to execute because they build critical public infrastructure are often paid in terms of bonds. Wanna know why? Because if the work is shoddy or the contractor tries to skip town, the bond can be rendered worthless. But if the job gets done, and gets done right, an engineering firm can list it on the balance sheet and continue paying salaries even when projects might take years and millions of dollars to come to fruition.
Next is insurance. Hospitals already found this one out the hard way with ransomware. And for those of you who think "it's just software, it's not a big deal"... I hope you never have to bet your life on your code. I wouldn't.
Finally, we have unions. I've noticed that game dev got smart and there was a bit of organization at a recent GDC. The rest of us, I guess, have glided along on the salary bump associated with the difficulty in finding and retaining software engineering "talent". I guess we're finally seeing that disappear now that folks are trying to see how many lessons they can learn the hard way through nontechnical brute force and LLM slop. Yeah, sure, some engineers are using LLMs responsibly in a way that matches their capabilities-- i.e. using it as autocomplete to type code faster. But there's a reason why other easily-digitized knowledge-work fields like law and architecture haven't been subsumed by LLMs. It's because accuracy matters, and because those regulations have already been written in blood.
Ours haven't (yet).
Use the royal "we" with caution, please.
P.S. in case it wasn't obvious, this isn't one of those "nyeh nyeh well you must be dumb because you don't cogitate in ways reminiscent of modern computing hardware" comments so much as a "you would not believe how simple-as-in-basic-as-in-limited some of us really cogitate while leveraging external systems to suggest otherwise ".
One morning, I heard something terrible while my boss's boss's machine was booting. Something akin to grinding. The thing was angry.
I gave boss^2 a heads-up that his hard drive might be failing, and that he might want to run a S.M.A.R.T. check on the poor thing. I also asked where the backup hard drives were, because I was brand-new and assumed that I just hadn't been issued one yet.
I checked the supply closet, found no hard drives, popped over to the office admin person, and recommended a deal I'd seen on some WD black drives before I realized that the place had gone quiet.
Everyone looked at me like I was from Mars.
Exactly 7 days later, boss^2's hard drive failed. We lost a week of work and had to zero out a 5 days x 3 employees worth of billable hours. We also ended up delivering late.
The client was pissed.
Based on the nasty looks that I got afterwards, it appeared that the standard assumption was that I had tampered with the drive to prove a point. (Um, nope).
I have since learned to ask prospective employers about their backup strategy.
1. You are the engineer of record on all of your commits.
2. As the engineer of record, you have a certain duty of care with regards to code quality.
3. If you are not signing your commits, you are not providing reasonable provenance and instead tossing your name around in a way that anyone can replicate with impunity.
LLMs have not changed the calculus there.
It effectively mandates a lower-limit on spend for budgeting purposes.
Sure, that money might be spent ineffectively... but corporations will figure it out if their only options are to
1. Not invest in regulatory compliance at all and get fined for noncompliance.
2. Throw money at the problem, spend it inefficiently, and STILL get fined for noncompliance.
3. Throw money at the problem, spend it well enough to pass muster, avoid fines.
I suspect that it is an attempt to broach an uncomfortable topic through vulnerable self-disclosure, but we need to be serious about admitting when there is a problem somewhere.
"Bugs" are not any more cute or fuzzy or entertaining or harmless than the engine "gremlins" that haunted the aviation industry back in the day.
I don't know how many accidents had to happen before the airplane people got serious, but software people are overdue for a similar reckoning.
I'm saying that LLMs are like really bad compilers hehe.
By "attesting to ... the person who owns it", I mean to talk about "identity" in the precise sense of "identifying" the relative physical location of whatever entity happens to be in control of some particular key material issued and registered a priori at some secure location. (That is, a supercomputer can bruteforce many kinds of strong cryptography eventually... but unless P = NP, it's not happening quickly. The odds are literally astronomical that one would be able to guess the right answers correctly and quickly. So we can all rest assured that anyone who can make it through a zero-knowledge proof protocol within reasonable time limits must physically control certain private key material).
Again: I am not talking about "identity" in the usual everyday sense of identifying some particular human being.
A better way to put it would be something like "SIM cards, but for cameras". You could even use similar terminology to what LTE has:
- IMSI (International Mobile Subscriber Identity) := the smartcard from your cell carrier which lets you use a particular phone number on their network. (For the camera use-case: you would subscribe to an attestation service that will vouch for your photos. The service would issue you a phone-number-like "subscriber number", perhaps via SIM smartcard, u2f dongle, or other physical "key")
- IMEI (International Mobile Equipment Identifier) := the network-specific serial number that device manufacturers issue to each device, in addition to the regular "make-and-model" serial number that one might expect. The function of the IMEI is to label a particular physical device as end-user equipment that can participate in the attestation system. (It also comes in handy to support anti-theft blocklists in the event that user equipment is stolen, and some nefarious third party attempts to connect later).
Note that in the case of LTE devices: it is possible to clone a SIM or steal a mobile device. Fortunately, the IMSI + IMEI combo gives cellular carriers enough information to do something reasonable in those situations. For the camera use-case, an attestation service could similarly do their part: 1. Refuse service if the request IMSI is associated with a spam dialer, a closed account, or a nonpaying subscriber (whose service has been shut off); 2. Refuse service if the request IMEI is associated with a stolen device.
Again, it doesn't give you the usual notion of "identity". But (in theory) it ought to give you something similar to the notion of an in-service phone number.
Each photograph would attach cryptographically-verifiable metadata attesting to both the identity of the camera and the person who owns it. (Say, m="Camera 123 owned by subscriber 456 created a raw 20MP image with sha 0xdeadbeef... at time 2026-01-23 4:56pm" countersigned by both the device and subscriber keys).
Image compression would be an immediate issue. Key lifetime management would be another major issue, as would key revocation behavior. Device manufacturers would take time to buy in and phase in hardware support. Consumers would object to yet another subscription service. Privacy and freedom-of-the-press advocates would probably have something to say about establishing a norm where we doubt the legitimacy of any digital images that refuse to "out" their creator.
And other than those pesky little non-starters, I've yet to find anything wrong with it :'-)
(see also: Schneier's Law)