If the code is bad, then improve or replace it, and do your best to help that developer improve his own skills, so this wont happen again.
If code output is constantly bad, then fire the developer, but there's also no reason to be condescending here.
I just can't see that treating a developer (or anyone else) like shit is going to have any positive outcome considering the current market for developers, where demand is much higher than supply.
There is a reason that you are reading it: you are maintaining it, adding a feature or trying to fix a bug. If it is not easy to read then it makes this harder and that makes code bad and increases the chances of the editor making a mistake and breaking the system. (Or just making your day bad).
Making the code easy to read is simply a technical matter, an intrinsic quality of the code. However, your code cannot be easier to understand than the business it models.
To convince yourself, have a look at some (good) framework like a HTTP Server, ORM, or browser, ... Their code is generally miles away from what you expect and hard to read if you do not dedicate days or weeks to them. But it is not due to bad code but due to the fact that you are aware of only a tiny fraction of the problem they solve.
EDIT: (I realise I didn't make a point) My point is that it is not a hard rule. If you are experimented with the business, familiar (a bit) with the code and it is still hard to read that is the sign of trouble.
On the other hand, sometimes code really is just shit. Being positive and saying "this is a good start, let's go through it and see if we can improve upon it" might be a massive waste of time if it's really shit. Sometimes holding people to high standards is necessary so the whole team doesn't get held back.