Uhhh, maybe bad programmers do that. Any programmer worth their salt with actual responsibilities is damn sure going to make an effort to figure out exactly what is happening and why as apart of fixing it.
Maybe I've been doing this for too long, but if I come across a project that isn't built via CI, I instantly think it's by amateurs and I don't trust it.
Lose a little credibility now, or a ton of credibility later? Sounds like a pretty short-sighted tradeoff, and a good opportunity to find a less shitty employer.
I feel like the "we don't know what this function does" meme is kinda bad. There's no reason beyond maybe time crunch why you shouldn't be able to dissect exactly what it does.
Despite this, the notion of a load-bearing function is still very relevant. Yeah, sure, you know what it does, including all of the little edge case behaviors it has. But you can't at this time fully ascertain what's calling it, and how all the callers have become dependant on all the little idiosyncracies that will break if you refactor it to something more sensible.
It has been several times now where a part of my system of legacy code broke in some novel fantastic way, because two wrongs were cancelling out and then I fixed only one of them.
I feel like these memes have to (mainly) stem from badly documented or broken libraries. The only times where I don't understand what I'm doing are when I try to figure out what someone else is doing
The most recent library I wrote for my team at work is painstakingly documented, and everyone has been invited to the multiple recorded training sessions.
They still act like it's black magic and just push all work and questions to me.
If the tests pass, then everything is fine... Unless we expected the tests not to pass...then it's time to burn the codebase down and try again after a long vacation to clear our heads.
Of course, I'll usually settle for fixing the test suite after a long weekend. But in my heart, I'll know what I should have done...