Ugh. Another "let's-act-like-everything-is-happiness-and-rainbows" post.
In my experience, most of the time someone says "this is shit", it actually is, and it's indicative of serious failures in the hiring/training/code-review/management process.
The only ways that companies improve at those processes are by pointing out the shit, calling it by its name, and figuring out the best ways to keep it from happening again.
Having a "this is shit" culture can be GOOD -- it can hold people accountable and promote a culture of excellence.
> In the end it is a culture that values negativity rather than focus on solutions.
That doesn't follow. Call it shit, and then fix it.
> Start by understanding the code, and then find ways to improve upon it.
That means that, instead of fixing the underlying problem and making people accountable for their work, you take on the burden of cleaning after other people's shit? I don't think so.
The author is correct when they say:
> Don't blurt out negative assessments of others code for no reason, and with no understanding. ...Start by understanding the code
But that goes without saying. Don't be too quick to judge when you don't have the facts. But once you're sure the code is shit, it's ultimately counterproductive to hide that. Most employees will only start writing better code once they're expected to, and strongly held accountable -- like most people's performance in any job.
PS: To be clear, I'm not talking about disagreements over coding styles, etc. I'm talking about code with obtuse function names and no comments. I'm talking about CSS that is hack upon hack upon hack filled with negative margins and !important's. I'm talking about JavaScript that pollutes the global namespace by programmers who refuse to use "var". Or CSS declarations like "div div span div span tr td span {color:red;}". And there's a tremendous amount of this stuff out there. Stuff that there's never an excuse for.