This is my first TSL Tuesday post, and actually my first run at blogging. And on a special new day too! I have been reading other’s blogs for about a year now and thought that perhaps I could contribute something that helps someone else out one day.

This month’s T-SQL Tuesday challenge: reveal your crap to the world. Why is (or was) it crap? Why did you do it? And how did you learn from your mistake?

Yup, I’ll admit it…I’ve written lots of crap code! I didn’t sit down one day and decide to write some crap code just for the fun of it. I wrote crap code because I didn’t know a better way to solve the problem at the time.

There have been plenty of times that I have gone back to review code that I wrote in the past and said, “Matt, why on earth did you do that?!?!” I don’t have any specific examples to share though because I try to fix the bad code as quickly as I can and burn the old code.

Some things that I have learned the hard way over the years:
1. Don’t believe everything you read on the internet.

• Make sure you are using a reputable source. I’ve seen some crazy solutions posted online to solve simple problems.
• As I’ve read multiple times, Trust but Verify. Even if you find code to solve a problem from a reputable source there is always a chance that they made a mistake or syntax error in their code, were making an April Fools joke, or were flat out wrong about something.

2. Comment, Comment, Comment, Comment.

• And then make a comment about your comments.
• When you write bad code, including comments to explain what you are trying to accomplish will make your life a lot easier to try to remember what your goal was 6 months or 2 years ago.

3. If you get stuck, walk away.

• No, not forever…I mean take a break. I have had plenty of times that I was working on a script or a query that seemed very complicated. The length of code kept growing, and the entire thing kept getting more complex. What did I do? I saved the code, stopped thinking about it, went home and got a good night’s sleep. The next morning when I pull the code up, I can usually see that it is too complex, and bang out a much simpler solution that performs much better.

4. Find a mechanism to test your code. In SQL Server, there are many ways to test how well your code is performing.

• SET STATISTICS profile On (BOL) and SET STATISTICS time ON (BOL) to see measure how long it takes for the code to run
• Check the box in SSMS to include the actual execution plan, combined with the awesome tool SQL Sentry Plan Explorer
• And absolutely don’t forget to test that the output matches what you started with (or fixes an error in output). I have been embarrassed more than once when I *fixed* a report, only to have someone point out to me that there was now data missing from the new version.

5. Keep on learning.

• While I know enough to function and get by day to day, I know that there is still a heck of a lot that I don’t know.
• When I can find free time, I read other’s blogs. I almost always learn something new in the process about SQL Server, server performance, security, or tips and tricks to write better code.
• Here are some resources that I have found invaluable in my career as a DBA. (So as not to offend anyone, my disclaimer is that there are plenty more resources that I have found to be invaluable, this is a short list.)

1. Pinal Dave (blog)– As I was getting started, almost every question that I googled had Pinal on the first page of results.
2. Brent Ozar PLF (blog)
3. Thomas Larock (blog)
4. Blog aggregates: SQLServerCentral.com (rss) and SQLServerPedia (rss)
5. Microsoft SQL Server Books Online: http://msdn.microsoft.com/en-us/library/bb545450.aspx