[kristopolous]

Depends on your comment philosophy.

Under mine, the AI should sign and date the comments, something like so

AI 20230524

Comments are an odd asset. Some of the most useful ones I've seen when debugging are rotted ones that describe the code that used to be there.

You'll then turn back the clock and find the bozo that "fixed" something by removing important code but for some reason left the comment behind. It's pretty common.

This AI tactic could protect against that so when the next bozo comes in with their wrecking ball fingers and leaves the ai comments behind, you can go in there with your mop and broom and recover things quicker.

What would be really nice is my favorite commenting technique which is where I write obvious but also counterintuitively very wrong code and I aggressively comment it like

"Hello, if you're here you may be asking yourself why it's not like this

(Wrong code)

I did too! That's what #231 and #302 are about! I know I know, I fell for it too. If you're going to change it, open a ticket or something because you're probably going to break it as well"

If the AI can do that then we're in gold territory

[dmurray]

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

[kristopolous]

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.

[xp84]

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!)

[kristopolous]

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.