Yes, Adam is right: we've all written crap code (the topic of this month's T-SQL Tuesday Wednesday). Usually we have an excuse: tight deadline, short shelf life of the code, or didn't know any better. I'm sure if I perused my career codebase I'd find tons and tons of examples that I'd write differently today, because back then it fell under one of these categories.

I've developed a lot of habits over the years. Mainly, these habits are better for me, but they're not necessarily better for everyone. I have my reasons for shifting my coding style in various ways, and I've documented many of them right here.

Some of those ideas revolve around readability and maintainability, and I don't ever expect to convince everyone else that commas belong at the end of a line, not the beginning, or that [column alias] = (expression) reads better than (expression) AS [column alias]. A lot of these are just preferences – as I've preached many times in the past, the conventions you choose are not as important as how consistent you are in implementing them and whether they make sense to you and those around you.

So when I look back at older code, I definitely see some things from my list of habits that have changed. Nothing important enough to go back and correct, but noticeable nonetheless. I see some dumb, wasteful things like this, where I'm building a ginormous dynamic SQL string and then either printing or executing the string depending on a flag. But then I add other junk to the end inside the conditional.

IF @debug = 1
BEGIN
    PRINT @sql + ' OPTION (MAXDOP 1);';
END
ELSE
BEGIN
    EXEC(@sql + ' OPTION (MAXDOP 1);');
    PRINT @@ROWCOUNT;
END

No, this kind of thing is not a big deal, and there are other things in there that I'm even more appalled at (one: not trying to remove the dynamic SQL in the first place, and two: using EXEC instead of sys.sp_executeSQL). But I'm pretty particular about tidy code and this kind of redundant string-building just irks me to no end.

Anyway, I don't want to focus on code, I just wanted to point out that you shouldn't be too hard on yourself for crap code that you've produced in the past. You probably had a good reason (or at least a lame excuse) for putting it out that way, and we all had to start somewhere. I only know a few people who think they've been an expert in their field since the day they were born; most of us will admit that we're always learning.