IMO this is exactly what unit tests should be used for. Replace these comments with unit tests and you're doing TDD. The practical difference is by stating your intention as unit tests, you not only verify your initial implementation is correct but also that any future changes remain correct.
All employer / employee relationships have this dynamic. I get paid _n_ because my employer cannot figure out an effective way to do it cheaper, but as soon as they can I will no longer be paid _n_. While I think blackmail isn't an accurate description of this, what you're describing exists in all employment situations. Making yourself more disposable is only going to give the employer more power, which might work out better or worse depending on the employer.
Wrong, no employer relies on a newly hired employee the way they rely on a senior knowledge silo'd engineer with a decade+ of domain knowledge which they are reluctant to share. In most jobs the employee is not in a position to have that kind of bargaining leverage. That leverage is only gained by an employee either intentionally and maliciously making the codebase as esoteric and unmaintainable as possible, or poor management not planning for these risks sufficiently e.g. not hiring more staff for a legacy COBOL system team as it's members leave until there's only one guy left who understands it.
> While I think blackmail isn't an accurate description of this
I'd argue it is. You know their business depends on you as a result of you actively working to make it depend on you, you use that knowledge to leverage your position in bargaining for higher pay or to never get fired from a low-effort "cruiser" job. Essentially blackmailing the business into continuing your employment under threat of losses caused by you leaving and nobody else being able to maintain the mess you created. This is not a normal employer / employee relationship dynamic at all.
No, you just make yourself disposable.
War is peace. Freedom is slavery. Ignorance is strength.
Don’t listen to this article. It sounds like something overseers would tell their underlings.
And when you’re quitting, that’s the company’s problem, not yours.
You might be making yourself disposable specifically in the context of your original role which you are basically making redundant by documenting and automating everything - but trust me any sensible business will want to keep a staff member who massively improved their team's productivity (by enabling them to be more independent with less silo'd knowledge) and reduced the business' risk exposure (by making potentially critical knowledge more accessible and reducing single points of failure).
Employees who try to become indesposable by turning themselves into a mega-silo of knowledge that nobody else in the org has might gain some job security in the short term but they lose out on any potential job progression.
Turning yourself into a silo like this is practically blackmailing your employer into keeping you. They might keep you employed because they need to keep their systems online, but they will also not think twice about replacing you as soon as an opportunity is presented. That is making yourself disposable.
Turning yourself into a leader who improves the outcomes of various teams in a business will not only make you indespensable, it's genuinely the best (if not the only realistic) path for an engineer to work their way up into more senior or C-suite positions.
Just because a business can destroy another huge companies business model it doesn't mean that replicating it is a good idea.
You seem to be completely unaware of the multitude of data breaches and leaks that Apple has faced, some they've even tried to actively cover up. Apple has a very obvious track record of disregarding their customers interests in favour of trying to protect their PR. Why notify customers and address data breaches when you can cover it up and pretend to be the champions of customer privacy when announcing anti-competitive policies that gives Apple monopolies?
So... exactly like isomorphic/universal JavaScript?
What exactly is the practical benefit in this, compared to say, JS functions shared by serialising them as strings or by abstracting them into a common dependency package which can be ran both on front-end and back-end?
no, it doesn't. the headline makes it sound like facial recognition is unreliable for some reason.
the reason, in this case, is that the Apple store and/or SIS personnel gave the recognition system Ousmane's name when they weren't able to prove it was him, and the document provided for identification was not actual proof of identification.
Further facial recognition matches assigned further blame to the misidentified person, increasing the evidence against him.
Then, because store owners and security firms really want to put away shoplifters, they claimed that video proof of the shoplifting was routinely deleted when there was no policy describing a deletion policy within Apple or SIS, only for video proof that the individual was not Mr. Bah to later be found.
in this case, facial recognition tech was unreliable entirely because of the people running it.
Wrong.
In this case the facial recognition tech itself was arguably not unreliable. The human operators were the unreliable factor.
The recognition tech reliably tagged the impersonator as Ousmane exactly as it was instructed to do. The system worked exactly as intended. It is the human operator whose intention was wrong.
This has nothing to do with AI being unreliable and everything to do with the employees of this SIS company going "yep kid's black, he's the one who did it" without half a thought.