T-SQL Tuesday #102 : Giving Back
Riley Major is hosting this month's T-SQL Tuesday, and the topic is Giving Back. I have been contributing throughout my entire career, and in fact it's what started my career, so it's going to be really hard to describe any of that without sounding like I am tooting my own horn.
Of all the blogging, answering, and presenting I've done, the three accomplishments I'm most proud of - in no particular order - are:
- MSSQLTips.com Author of the Year, 2016
- Legendary badges on both Stack Overflow and Database Administrators
- 20 straight Microsoft MVP awards
I'm also quite proud of things I've done to encourage and recognize fellow community contributors, for example the Community Influencer of the Year award. Winners so far:
In the end, I'm not looking for accolades or awards or anything else; I'm just trying to help people. When I started out, I was answering questions on a mailing list, then on NNTP newsgroups. Eventually, I got so bored answering the same questions over and over again, that I started blogging them. Then, instead of writing another elaborate answer, I would just post a link to the blog. Note that this was so long ago that it wasn't even called a blog yet.
More recently I've focused on T-SQL bad habits and best practices. I saw enough people getting confused by wrong results or errors when using code like
DATEPART(Y, ...), or
'dd/mm/yyyy', that I started a series describing why the results are wrong or why they got that error message. Again, partially out of selfishness, since I had learned years before that posting a link is a lot less work than typing up the explanation every time.
But I also had a secret motivation here: to help the helpers. I see the same kinds of coding conventions being used by people who are actually very good at T-SQL. They just have habits that don't form the best examples. In a lot of cases, sure, people "know what they're doing" so they feel free to use shorthand, cryptic logic, or undocumented tricks. I'm guilty of this too, but am trying to get better. My issue is that, when you use something simply because you know what you're doing, or know that in this specific case it can't break, you are writing or posting or sharing code that other people will learn from. But they don't have the same level of knowledge and, frankly, don't necessarily know what they're doing. They saw this respected expert do this thing, so that must be an okay way to do this thing, or might even be the best way to do this thing. No documentation in that code sample they copied from your blog post or Stack Overflow answer is going to warn them: this thing breaks if the language is not English, or if your version of SQL Server is prehistoric, or if your table has an identity column.
I may come across as pedantic at times, but I hope I can convince you that my heart is in the right place. It's easier to develop good habits from the beginning than it is to change bad ones later on, and I would love for people to remember that when they are helping others. I am going to continue contributing in this way, and I encourage you to do the same; be confident that you don't have to be a Drew or an Andy, or achieve some silly badge on a web site, to make a difference.
Aaron (@AaronBertrand) is a Product Manager at SentryOne, with industry experience dating back to Classic ASP and SQL Server 6.5. He is editor-in-chief of the performance-related blog, SQLPerformance.com, and serves as a community moderator for the Database Administrators Stack Exchange. Aaron's blog focuses on T-SQL bad habits and best practices, as well as coverage of updates and new features in Plan Explorer, SentryOne, and SQL Server.