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.)
- Pinal Dave (blog)â€“ As I was getting started, almost every question that I googled had Pinal on the first page of results.
- Brent Ozar PLF (blog)
- Thomas Larock (blog)
- Blog aggregates: SQLServerCentral.com (rss) and SQLServerPedia (rss)
- Microsoft SQL Server Books Online: http://msdn.microsoft.com/en-us/library/bb545450.aspx