A more robust and less passive aggressive way to do this is to write a unit test that fails under the "wrong code".

That's another thing that could get removed/modified/disabled and it's action at a distance

Proximity is really fucking important but of course is only a proxy for other practices and anti pattern avoidance

Regardless, if you need to engage, do so at the obvious point of engagement, not off in some test suite where you cross your fingers on predicting the future on the diligence of its upkeep.

I mean write the test, do your rain dance. It's not going to protect you against the stupidity you have to worry about, X years after you've left the building.

Your code will live longer than you think and be modified more times by more people, who you will never meet, then you realize.

You don't have to feel responsible for that. But I do and that's one of the examples of how I practice it. You're leaving notes for future archaeologists to remove their guesswork.

Again, tests are great, linters are fine, but your nth generational successors may not agree with you or how you did them or how often they should be run or... and there goes your hardwork. Don't rely on them for assuring protection past your tenure.

Future coders are probably 10 times more likely to curse you as a nuisance than appreciate your diligence. Assume they'll hate you.

I actually completely agree with you in your approach, but also feel you/we should not take upon our shoulders quite so much responsibility to make the things we build perfectly resilient to bad decisions made by successors in the future. Put another way, I love and also do the “Note: do not use “‘86400 seconds’ - fails 2x per year” comment - however, I have not ever had the “there goes my hard work” thought after I have quit. If they don’t hire equal or more competent developers than me, and they mess up things, that’s actually kind of funny! (Note: if I worked in the medical, military, or nuclear fields, I’d feel very differently!)

Those industries are fundamentally different. They don't build software by the same rules.

It's like comparing say, clothing you buy at the mall to the clothing of a hazmat suit - sewing is involved, materials, you need something that fits over a body, it's roughly the same but they're fundamentally different.

There's extensive compliance and regulation. I've done avionics/automobile software. It's not fun or sexy and it isn't supposed to be.

If you try to play by the same rules as the rest of software you get Theranos. It doesn't work.