In any team environment, a developer may have to adapt another's code. When they fail to understand it, they condemn it. This attitude isn't helpful, in fact it's hurtful.
Everyone's probably done it. I certainly have. It's easy, simple and others won't hesitate to either agree with you or to straight up egg you on in your quest to vilify and codem the previous developer. Sometimes, you might actually be right, and the code really is shit; but just remember that everyone writes shitty code.
One of the biggest skills I think I've picked up over the last few years is to become more understanding of exactly what this statement does, and what it accomplishes; which is nothing.
The code you think is so awful may have been written at a time when "so and so" was the "manager/CEO/pointy-head boss" and they had no idea what they were asking for, or what the requirements were. Who knows, maybe the deadline was that night and there was no other way to do it. Point is, no one goes out of their way to actually write awful code, and no one is trying to write an unmaintainable mess. Sure, there are plenty of junior developers and other inexperienced folks writing code, but I've found it far more common for somone to stumble upon an experienced developer's work and say this, rather than the other way around. If you aren't extreamly familiar with the time and place when it was written, take a moment to get context from anyone there or your manager before you attempt to throw the last developer under the bus.
One thing I can no longer tolerate is anyone being incredibly unhelpful by opening their mouth. This goes beyond talking about another developer's code as well. Hearing people talk just to hear themselves talk about how shitty something is doesn't do anything to solve the underlying problem. If you want to be effective and meaningful, solve the damn problem. Discussing with anyone your negative opinion on the last implementation also doesn't do anything to solve the problem, it just causes strife and breads a hostile environment.
Instead of spending time rallying troops to get behind your critisim of the previous developer, rally around the idea of moving forward and building something of greater value. Managers and others are more receptive to positive communication about the current state of affairs and it doesn't require you to throw anyone under the bus. In times where I've wanted to be negative I'm instead trying to go with this statement:
"This code is getting a little complex and difficult to maintain. Would you mind if we spent a few days addressing this so we can move forward with the new features we have planned for this quarter?"
This sounds a lot better than "this is shit".
And who knows, that next piece of code might just be yours.