Free Online SQL Server Training for the Week of January 12, 2013

If you’re a training provider and I’ve missed you, please drop me a line at brian {dot} kelley {at} sqlpass {dot} org.

All times are Eastern (New York). To convert to your local time, use the converter at timeanddate.com.

 

Monday, Jan 13:

• 11 AM – Big Boys’ Toys: ColumnStore Indexes with Table Partitioning – Andrew Whettam – PASS BI VC

Tuesday, Jan 14:

• 11 AM – Bus Matrix – the foundation of your Data Warehouse – William Anton –Pragmatic Works

Thursday, Jan 16:

• 11 AM – Necessarily Evils, Building Optimized CRUD Procedures – Jason Strate – Pragmatic Works
• 12 PM – Analytics at Cisco – Arun Saksena – PASS Business Analytics VC
• 12 PM – Attributes & Hierarchies in Analysis Services 2012 – Thomas LeBlanc – PASS BI VC
• 3 PM – Building a Rock-Solid Backup Solution – Brian Kelley – Idera / MSSQLTips.com

 

Training Providers I Regularly Review:

• Confio
• Idera
• Microsoft
• MSSQLTips.com
• Pragmatic Works
• Professional Association for SQL Server – I’m using the events page. If you’re a chapter leader and haven’t converted your meeting announcements over to Events, please check the Chapter Dashboard to learn how to do so.
• SQL Lunch
• SQL Sentry
• SSWUG.org

Being a Better IT Pro – Keep It Short

Keep your emails and communications as short as possible.

Make sure you cover everything you absolutely need to, but nothing more. When an email is too long, people won’t read it. Don’t believe me? Think about your own habits. When you see a wall of text, what do you do? If you’re the type to dig in and read, realize you are an exception.

Seth Godin wrote that the tl;dr reason is foolish. His point is one can’t judge quality by length. He is 100% correct. However, most people do. If you want your emails and communications read, keep them short and to the point. The shorter the better while still communicating what you need to get across.

Being a Better IT Pro – Get to the Point

When writing emails or other communications, state your point or request right at the beginning.

For instance, if you need the server team to reboot the server, tell them in the first sentence that you want them to reboot the server. Most IT folks attempt to reason through things logically and if you’re like me, you like to systematically prepare your argument or request. However, the problem with this approach – especially in emails – is it buries what you’re trying to convey to your reader. The further down the email something is, the more likely it will be missed or won’t be read at all. That won’t do.
What drove this home for me was reading about how journalists prepare news articles. They are supposed to use an “inverted pyramid” structure where the most important details are placed at the top of the article. The reason for this is primarily due to editing and layout. If the most important facts are at the top, then I can chop from the bottom without actually having to read the article.
When it comes to business communications, likely no one is trying to piece articles together to fit well on the printed page. However, most folks are deluged with emails on a daily basis. Therefore, the longer the email, the less likely it’s going to be read. If it is read, there’s a good chance the reader will skim the first few sentences and then move on to the next email. As a result, if your point or your request is not in those first few sentences, it will be missed. Therefore, an inverted pyramid works best with respect to email as well.

Let’s look at a simple example:

Bad:
Today we had a problem with SQL Server SalesSQL04. We are seeing symptoms of a memory leak. However, this server supports the main sales application and we can’t reboot it until after hours. If you all would, please reboot the server at 9 PM.

Good:
At 9 PM, we need SalesSQL04 rebooted.

We are seeing symptoms of a memory leak. However, the server supports the main sales application and we can’t reboot it until after hours.