I'm going to have to disagree with you on this one.

There is definitely some code out there that deserves criticism.

I look at some of the database designs and stored procedures I wrote a few years ago, and I cringe. Definitely worthy of criticism, by me or anyone else.

My predecessor at my current job left behind a mess that was doing things like losing 16.7% of the orders placed for materials on our websites. (Lost 5 minutes of data twice an hour = 10 out of every 60 minutes ~= 16.7%.) This was not due to the pressure to design the thing, lack of training (degree in Comp Sci), experience (over 20 years), or anything other than not paying attention to the details of the project. Same developer also lost an unknown percentage of data, because of the way it handled inserts into sub-tables after inserting into a parent table. Instead of using Scope_Identity, or some other common method (could have used Output, it's SQL 2005, but I can easily forgive not knowing about that one), the code instead queried the table it had just inserted into for the ID of a row with the same e-mail as the input parameter value @email. One person with a blank e-mail got all the data for everyone who ever put in a blank e-mail, and the whole process would fail and rollback without raising an error if the @email value was null. E-mail was NOT a required field on the websites, nor required by business rules.

There's an ETL process that's so complex the original author would take 2-3 days to find out what was going on any time a row of data didn't transfer correctly. To move data without non-trivial transformation from one server to another. (The only transformations were renaming columns and tables.) I can't even begin to describe how this process works, because it would take a book to do so. It takes 4 SQL Agent jobs, three Replication publications, and dozens of stored procedures, all using dynamic SQL. The shortest stored procedure is over 1000 lines of code. I'm in the middle of replacing it with a single stored procedure that just uses Merge (for the 2008 targets) and 2-step upserts for 2005 targets. Troubleshooting takes seconds now, instead of days.

There were replication jobs that pushed data from one server to another, then pulled the data back and overwrote the original, completely eliminating all user input at both ends. Those I fixed a year ago.

I replaced a 2000-line stored procedure with pages of dynamic SQL in it, with a single Insert Select statement, just last week. It processes the data correctly, the business users are thrilled that it's not losing data any more and that the results from it are verifiably correct, and it runs in a few milliseconds instead of several minutes.

That's just the surface of it. There's a LOT more where that came from. And did I mention the only documentation he left behind was 2 Visio flowcharts, one of which was just plain wrong (servers that had never existed were on it), and the other consisted of two servers with an arrow between them from one to the other, and nothing else.

The only good thing is there's years left of work for me just to bring tables and processes up to at least the kind of standards I'd expect from a junior DBA with a couple of years of experience, much less up to any sort of expert level. That's only good because it pretty much guarantees employment. I'm good at what I do, but this guy is making me look like some sort of hyper-genius, to the managers and my co-workers.

I'm told the guy left because he wanted to get back into what he really enjoys, which is writing software for offshore banks. (Yeah, he writes banking software. That scares me too.)

I never walked in his shoes, so I prefer not to criticize him. There may have been valid, to him, reasons to build the Rube Goldberg machines he built, and there may have been reasons to avoid documenting incredibly complex, business-critical processes, databases, et al. I'll never know. (Note: I try not to criticize him. I'm not sure I succeed all the time, but I do try.)

But I'm definitely going to be critical of the code. And then fix it. And then be critical of my own code when I review it next year or whenever. Otherwise, it'll never improve.