GP may be saying that senior devs tend to s---t all over people's code. I've certainly seen it happen. But I think that's more of a personality trait (well, lack of empathy) than anything else.
When I will see the problem, I will fix the problem. What the problem with that? Do I need to create a ticket and assign it to Junior with a book long description and proposed solution?
The problem is that when one fixes a problem by "s---ting all over people's code" like GP said, chances are they're introducing more bugs or restoring old ones.
That's why git-fu, comments and a collective memory is important. Not only we need to know what was done, but also why, when and in which conditions it was done.
No. It's not about satisfying bureaucracy. It's that at a certain point, any complex code system becomes a black box. You cannot fully reason about it. Your tests become your source of validating that box and any change you make is just as likely to break something as it is to fix something.
