[evilsnoopi3]

The problem of course is that so many things are experiential (rather than data driven) so the question “What would convince you otherwise?” could only be answered by “Having lived a different life.”

Take, for example, a software engineering opinion that I hold dearly: “Good commit titles and descriptions, with sufficient description of why a change was made and notes on any non-obvious implementation decisions, are valuable and necessary.” This arises from my experiences trying to debug code in repos filled with commits titles ‘wip’ and ‘address feedback’ and ‘changes’ which inexplicably touch 5k LoC. I simply despise trying to divine what some past developer intended without any clue as to why; it is an epistemological impossibility even when sometimes the past developer is me. More over I am convinced this is necessary because I also have the experience of doing all the work to understand some spaghetti—using old issue tickets and git blame to slowly build a mental model of the codebase—finding the bug, changing it, and having the whole system violently reject my fix because what appears to the naive observer to be a bug is, in fact, intended behavior the system depends on.

What would convince me otherwise that spending time on writing good commits is not worth the time and effort? Either an impossible-to-execute-without-confounding-variables longitudinal study that measures developer happiness over time in code bases that do/do not emphasize commit message quality. Or I could have different experiences that lead me to not care. Like if I never had to maintain legacy code or if everywhere I ever worked had issue trackers filled with explicit technical details and motivations then maybe I wouldn’t care; but that’s not my experience so I do care.

I don’t know how you hack your way past the reality that there is not one perfect way to write maintainable software and even if there was nobody actually has time for that. So you have to chose what to prioritize and some of those priorities may become your personal cargo cult.

[stevage]

That's a great example. My experience is precisely the opposite. I gave up on commit messages years ago in my own projects and it has never had the slightest negative effect. I literally have sequences of hundreds of commit messages that are simply "update".

But my experiences are not yours. my projects are likely simpler, and I don't collaborate much. It would be dumb for me to follow your practices, and you mine.

[evilsnoopi3]

Exactly. What is important is knowing what to prioritize for the project at hand. If it’s useful it’s not a cargo cult. Of course the less experienced would ask “how do you know if it will be useful?” but truly the answer is you experiment.