Search results matching tag 'Speaking'

Speaking - Tech Ed, Tech Ed, SSWUG, PASS

AllenMWhite — Wed, 22 May 2013 18:48:00 GMT

I feel like I've hit the speaker's lottery this year, starting with SQL Cruise Miami, and it just keeps getting better! After a great trip to SQL Bits I'm now preparing for my travel to New Orleans for more great SQL fun!

In early June I'll be speaking at Tech Ed North America, this year in New Orleans. I'll be presenting the same session later in June at Tech Ed Europe, in Madrid. Here's the session details:

Maintain SQL Server System and Performance Data with PowerShell
Maintaining a solid set of information about our servers and their performance is critical when issues arise, and often help us see a problem before it occurs. Building a baseline of performance metrics allows us to know when something is wrong and help us to track it down and fix the problem. This session will walk you through a series of PowerShell scripts you can schedule which will capture the most important data and a set of reports to show you how to use that data to keep your server running smoothly.

I've also been selected to be part of the SSWUG.org Summer Camp 2013 Conference and will present multiple sessions that you can view online, starting July 9.

Today the announcements were made regarding the PASS Summit 2013 presentations. I'm happy to say that I was selected again this year, and this time I'm presenting a brand new session, in the BI Dev Track!

Automate Your ETL Infrastructure with SSIS and PowerShell
Much of your ETL process flow consists of packages that are very similar in structure, capturing data from a single source and transferring that to a single destination. Creating the individual packages can be tedious and it's easy to miss something in the process of generating the same basic package over and again. BI Markup Language makes it easy to build new packages, and PowerShell makes creating the BIML scripts easy. In this session we'll show you how to use PowerShell to generate dozens of SSIS packages doing similar tasks from a defined set of ETL sources.

I have a special fondness for the PASS Summit. My first Summit was in November of 2003, and there I met many amazing and wonderful people, including Johan Bijnens, Morten Baden Rohde, Brian Knight, Steve Jones, Andy Warren, Kevin Kline and many more. Each year I've gone back I've renewed those friendships and made many more. I've been fortunate to have been selected to speak again this year and am excited to see everyone again this year in Charlotte.

I look forward to seeing you there.

Allen

Why We Write #5–An Interview With Jason Strate

drsql — Mon, 20 May 2013 02:40:59 GMT

My next guest is a person I have known for years, and have worked with on several occasions, Jason Strate (@stratesql). Jason is a very active writer and speaker (at my first SQL Saturday event, he spoke four times!), and always seems very busy. His blog (jasonstrate.com) had 23 posts just last month, and his twitter account is always active with interesting SQL and non-SQL tweets.

If the blogs and tweets weren't enough, just this past year, Jason was a coauthor on one book last year (Expert Performance Indexing for SQL Server 2012), contributed to another (Pro SQL Server 2012 Practices), and is credited as a tech editor on yet another (Professional Microsoft SQL Server 2012 Administration), and if all this wasn’t enough, published an kindle eBook about SSIS (31 Days of SSIS with SQL Server 2008 R2).

I look forward to seeing Jason's answers to my interview, as he is probably the most driven writer I know, so I expect his answers will get me that much closer to the understanding of why we writers do what we do...

------------------------------------------------------

1. There was a point in time when you didn't have a blog, didn't tweet, and probably had no public presence whatsoever. And then, one day, you made the decision to put yourself out there. What prompted you to get started writing?

When I first started writing it was basically a way for me to read something at home, then catalogue it for ease of access when I got to work. Often it was just a link with an explanation to why I thought it was interesting. Other times, it would be a script with the tweaks I had made - blogged just for safe keeping. I did this for a number of years without any knowledge of whether people were reading the posts, I was just keeping a running collection of notes.

At some point, about 10 years ago, I watched a webcast that Kimberly Tripp had put together on index fragmentation. One of the big take-aways that I got from the presentation was that someone was able use sharing of information as an aspect of their career. Color me naive, but the idea of writing serious articles, or posts, hadn't occurred to me prior to that point. Afterwards, I started putting a little more effort and aim into the posts that I was writing. Because an with audience for a fragmentation video, there was surely an audience for something I could write.

2. We all have influencers that affect our trajectory as a writer. It may be a teacher who told you that you had great potential, or another writer who impressed you that you wanted to be like? Or perhaps on the other end of the spectrum it was a teacher who told you that you were too stupid to write well enough to spell your own name, much less have people one day impressed with your writing? Who were your influences that stand out as essential parts of your journey to the level of writer you have become?

I wish I had a really good story here. There is no oppression from teachers or inspiration that bestowed on me, I basically kept my head down while serving time in the educational system. The only impression that school left me with was that writing wasn't important in life and if you made a career of it, you better be prepared to poor for a long time. So uplifting, but it would be no surprise that from an early age I didn't see the value in writing.

Now, I did have an influencer in my 20s that did get me started on the path of self-improvement that has to be noted. And while it isn't specifically a writing influencer, he did get the mud moving to help me re-envision what was possible. This was my friend Steve Coyle, for most of my 20s he was a constant friend that was always there to talk about how we could help motivate each other to move forward. He was the first person I met that explained to me the value in networking.

As I mentioned, my original inspiration was from Kimberly Tripp. She was also an influencer, along with a lot of people that readers already know. These include Louis Davidson (editor note: who?), Kevin Kline, Denny Cherry, Thomas LaRock, Brent Ozar, Paul Randal, Grant Fritchey and Jonathan Kehayias. As I've grown in my writing, I've watched how they write and looked to ideas on how to improve how I write.

In the past couple years, I've started looking outside the SQL Server community to find new influencers. This has brought in a few new names. One is Darren Rowse, who wrote the ProBlogger books, he's has had a lot of influence on how I put topics together. It's helped me find not just ideas to write about but ways to package them to attract readers. There's also Tim Ferris and Leo Babuata - who are fairly opposite self-help authors. One thing I've started to realize is the need to be influenced and seek improvement across my entire spectrum of interests, because it helps raise the level of everything and raising the heights that I can take my writing and life.

3. As the years pass, how has your writing changed? Do you feel like it is becoming a more natural process? Or perhaps you get more critical of your own writing to the point that it takes you longer?

There are a few ways my writing has changed over the years. One of the first big changes was transitioning from just posting code and links to explaining the value and purpose for that content. This led to an increase in the length of posts and the depth of the topics. Ever since I wrote the indexing book, my writing has really changed. I've become a lot better at drawing connections between what I write and the images and scripts included in posts. I try to explain everything, which makes for some really long posts. But that problem has been solved with the idea of breaking posts into multiple topics.

I am probably more critical of my posts that I used to be, but not overly critical. I really like to make certain that in every post, from the question or idea proposed to the conclusion, that there is a clear linear path of logic. I often use Sarah, my wife, as a reviewer for posts to be sure that, while she may not understand the content, does the logic of the conversation flow from beginning to end. She likes to point out that I don't use enough commas.

4. Assume a time machine has been created, and you are allowed to go back in time to speak to a group of potential writers, in which you and I are in attendance. What would you tell "past us", and do you think that your advice would change where you and I are in our careers now? Like would you tell yourself that one day you would be sitting here for a rather long period of time answering interview questions and not getting paid for it, instead of doing something else?

Given the chance, I would like there are a few things I would have impressed upon an early group of writers. First, make sure you are writing under some form of branding from the start. I've been blogging on www.jasonstrate.com for only about three years. Everything before that had moved from time to time between probably five or six different hosts and platforms. Often, I'd build and then abandon my audience without knowing it.

Next, spend some time really developing the blog posts. They don't need to be masters of art. But they need to have an opening, body, and closing. It was years before I got to that point - which had been hammered in while in school. It was a long time before I realized, that it made a difference in blogging.

And since you're working on developing your writing, use the blog to explain something, not just share things you find. Got a cool script - fine, post it - but also write down why it is cool and should be used. When I started explaining things, more people started to care about what I was writing down.

Finally, figure out how to write on a regular basis. At least once a week. If you're writing on a blog, its meant for an audience. If you aren't writing weekly or at least a few times a week, what is going to motivate an audience to stick around or come back. There are so many voices in the world today, that yours needs to stick around if you want it heard.

I'm not sure I would have listened, but it would have been cool to have gotten that advice. I'd like to think that had that happened, I'd probably have shaved 3-5 years off the progress it took to get to where I am now.

5. Finally, beyond the "how" questions, now the big one that defines the interview series. Why do you do write?

There are a few driving forces behind why I write. First, I'm naturally curious. When I was a kid, picking up an encyclopedia for a single topic always meant I would read a few others. Writing about SQL Server to me is part of that curiosity, when I hear a best practice, I want to check it and verify it. I want to see that it actually happens and understand what's going on. Along with that, writing helps me organize my curious endeavors.

I also write for other people. Those that read what I write about and gain something, that's a big motivator. I'm often astounded when people are excited to hear my thoughts on something or happy that I get to come out to their company and provide mentoring. Because to me, I'm the guy who licked a telephone line once to see if it gave off more or less of a jolt that a 9-volt battery (the answer is more) - and me giving advice is an often humorous turn of events. But, back to the other people, that I write for...

Probably the best answer is a quote from the movie Groove:

Guy: Why do you do this to yourself? Don't even get paid, risk getting arrested, for what?

Ernie: You don't know?

Guy: No.

Ernie: The Nod.

Guy: The Nod?

Ernie: Happens to me at least once every party. Some guy comes up to me and says "Thank you for making this happen... I needed this. This really meant something to me." And they nod... and I nod back.

Guy: [scoffs] ... That's it?

Ernie: That's it.

Bonus Question: Are there any projects coming up that you would like to tell people about?

The most exciting upcoming project I have has to do with where I want to take my blog. I've got a number of posts that people really like. But writing isn't always the best platform for everyone that may be interested in those topics. My plan is to start recording webcasts in the 5 to 10 minute range that encapsulate those posts and deliver them in a new manner. I'm hoping this will help me expand my audience. Also, I'm hoping it'll help me write better since it will force me to evaluate a lot of old posts - and possibly re-write a few of them.

---------------------------------------------

Excellent…simply excellent. I love the answer to the why question. I am personally very shy, so I would have NEVER have met any of the people I have if I had never started writing, blogging and speaking, so I identify with that a bit.

As for my question for “the” answer to the time machine question that will trigger me writing my own interview answers, Jason was way off that mark, with much more interesting answers. Branding is a great idea, but even if you don’t feel like that is for you, stick with the platform you have where-ever, and probably only move once and for a good reason. That is why I have my blog still on sqlblog.com. It is a good group of bloggers, I really like Adam Machanic and Peter DeBetta (though I haven’t seen him since he drank the blue Kool Aid a few years back), and I get more hits than I could on my own. Same with some of my simple-talk work, Tony Davis and Andrew Clarke edit my work and gives it a professional air that I could never.

The note about working on the blogs for a while is great too. For my What Counts For a DBA series of blogs on simple-talk, I try to treat that a bit like art, and really work for hours to hone them. For my technical posts, I am a lot freer with the text, but spend as much time as I can testing the code I put out, doing my best to make sure that the query I post works not only for my server usage, but for any server usage I can think of. Writing only what you have used in production is a great disservice to your readers because you don’t do everything. You might present an idea, but if you want to state definitively that solution X is the the best solution, you had better have tried A-W and Y and Z too.

Anyhow, next up is another friend of mine who has been influential in many of the members of the SQL Server Community. Kevin Kline. Till next time, I hope these posts inspire you to become my 100th subject in a few years (and will answer the inspiration in just that way, naturally!)

SQL Saturday #220 (Atlanta): Demos

Adam Machanic — Sat, 18 May 2013 18:33:00 GMT

Today at SQL Saturday #220 in Atlanta I presented a new brand new session, "SQL Server Query Plan Analysis: The 5 Culprits That Cause 95% of Your Performance Headaches."

This session is designed to help people quickly analyze query plans and find likely culprits without being query tuning experts; I find that in a huge number of cases the root cause of problems is one of just a few potential situations.

Thanks to everyone who joined me today for the deliveries! In addition to it being a new session this was also the first time that I've ever been asked to present the same session twice in a single day. So it was quite an experience.

The demo script is attached. As always, let me know if you have any questions or comments.

Enjoy!

Speaking about Relational DB Design the next two weeks (Knoxville, then Atlanta)

drsql — Mon, 06 May 2013 01:57:54 GMT

On Friday, May 10 I will be speaking for the Knoxville SQL Server User Group, and on May 18, I will be speaking at SQL Saturday in Atlanta. Both days, my session is my old chestnut “Database Design Fundamentals”. It is my favorite session to do because of two things. 1. I love to talk about database design 2. No demos :). The abstract is:

In this session I will give an overview of how to design a database, including the common normal forms and why they should matter to you if you are creating or modifying SQL Server databases. Data should be easy to work with in SQL Server if the database has been organized as close as possible to the standards of normalization that have been proven for many years. Many common T-SQL programming "difficulties" are the result of struggling against the way data should be structured and can be avoided by applying the basic normalization techniques and are obvious things that you find yourself struggling with time and again (i.e. using the SUBSTRING function in a WHERE clause meaning you can't use an index efficiently).

It is a session that I haven’t done in short form since PASS 2011, and submitting this as a session was one of my resolutions this year, because it is truly my favorite regular session (my second favorite session is the precon version, because we get to spend a good amount of time on the subject.)

Additionally, at SQL Saturday Atlanta, I will be doing a lunch session for Red-Gate called: What Counts For a DBA: Observant. It is a session that is 33% professional development, 33% about where to find info about your server, 33% about monitoring your server and 11% demo of the SQL Monitor (and a lack of math skills is part of the show.) This is not the normal advertisement session, I wrote it myself, but is intended to be useful to anyone immediately without buying their tools, and to show you how Red-Gate’s tools can assist in observing your server’s behavior

T-SQL Tuesday #41 - Presenting and Loving it!

AllenMWhite — Tue, 09 Apr 2013 15:56:00 GMT

For this T-SQL Tuesday Bob Pusateri asked us to share how we came to love presenting.

Before I ever got involved in computing technology I had (and still have) a love for the theatre, specifically musical theatre. When I was little the majority of albums (this was the 1950s, kids) we had were cast albums from Broadway shows my parents had seen at Musicarnival. I performed in shows all through school, and was a Theatre Major at Kent State University before I realized I needed to make a living.

It was this love of "performing" that had employers sending me to the trade shows to talk with customers. I wasn't the typical programmer, I could talk with people, even people I didn't know! One company was so impressed in my performance when I'd played Harold Hill in the show The Music Man that they made me a salesman. That failed miserably.

About eight years ago I started attending meetings of the Cleveland SQL Server group, at the Microsoft office in Independence, Ohio. As people had questions I'd pipe up and answer when I could, and as they needed someone to present I offered to put together my materials as a presentation. The first few times were a bit rough - ok, they were very rough - but the group was gracious and I learned to organize the material better. In addition to the user group presentations I'd been giving training presentations to the staff at work, getting them to understand SQL Server better to make my job as the DBA easier. This helped me develop my skills a lot.

I was first selected to speak at the PASS Summit in 2006, and I presented a session on SMO (Server Management Objects) and my demos all used Visual Basic. After the presentation a number of people came up to me and said they were administrators and weren't allowed to have Visual Studio on their desktop. PowerShell had just been introduced and I adjusted my material to use PowerShell.

Also in 2006 I became a Microsoft Certified Trainer (MCT). In teaching the official Microsoft courses I learned how to work with material I hadn't created myself, which then helped me build better presentations of my own material. I also learned that having to teach material forced me to learn it better myself. Someone will always ask questions about an aspect of the topic I'd never encountered. I found the best way to learn any topic is to teach it.

In the course of events I became the leader of the Ohio North SQL Server Users Group and at each meeting I ask everyone there to think about putting together a presentation for the group, so we can learn from them, and they can learn it better. We've got a great group of people who now present not just at our group but at others in the area and at SQL Saturdays and even the PASS Summit as well! I can't tell you how pleased I am at how many from our group are regular presenters in the SQL Server community now. These people include Erin Stellato ( b | t ), Sarah Dutkiewicz ( b | t ), Brian Davis ( b | t ), Adam Belebczuk ( b | t ), Craig Purnell ( b | t ), and Colleen Morrow ( b | t ), but more are stepping up regularly, and for that I thank each one of them.

Presenting is one of those magic activities in which everyone benefits. I'm fortunate that I have a natural inclination towards it, but love to see new people stepping up and sharing their experience and knowledge with the rest of the community.

See you at the next event!

Allen

SQLintersection!

KKline — Wed, 27 Mar 2013 13:47:00 GMT

The best emotion to describe how I'm feeling is 'astounded'. I'm astounded that I'm in such august company to be speaking the SQLIntersection (#iSQL) conference. Read the blog post from my first SQL Server mentor, Kimberly Tripp, which tells you all about SQLintersection.

Check out this list of speakers:

Aaron Bertrand, Sr. Consultant, SQL Sentry, Inc. [blog | twitter]
Andrew J. Kelly, Mentor, SolidQ [blog | twitter]
Bob Ward, Principal Architect Escalation Engineer, Microsoft [blog | twitter]
Brent Ozar, Brent Ozar Unlimited [blog | twitter]
Conor Cunningham, Principal Architect, SQL Server, Microsoft [blog]
Grant Fritchey, Product Evangelist, Red Gate Software [blog | twitter]
Jeremiah Peschka, Brent Ozar Unlimited [blog | twitter]
Joseph Sack, Principal Consultant, SQLskills.com [blog | twitter]
Kendra Little, Managing Director, Brent Ozar Unlimited [blog | twitter]
Kevin Kline, Director of Engineering Services, SQL Sentry, Inc. [blog | twitter]
Kimberly L. Tripp, President/Founder, SQLskills.com [blog | twitter]
Mat Young, Senior Director of Products, Fusion-io [blog | twitter]
Paul S. Randal, CEO / Owner, SQLskills.com [blog | twitter]
Paul White, SQL Kiwi Limited [blog | twitter]
Steve Jones, Editor, SQLServerCentral.com [blog | twitter]
Sumeet Bansal, Principal Solutions Architect, Fusion-io [blog | twitter]

Read the list of SQL Server sessions here. On top of the list of outstanding sessions to attend, I'll be giving a keynote on Tuesday afternoon. Witness:

So the only thing between the attendees and the booze in the reception hall is our keynote address?!? Oh yeah, that's going to go down real smooth, isn't it? I'll last about as long as a puny henchman between James Bond and the villain of the movie. Sumeet Bansal, from Fusion-IO, will have to survive until the credits roll. We'll be talking about high performance computing on SQL Server 2012 with an eye towards high availability, AlwaysOn, and Availability Groups.

If you're in Las Vegas, I hope to see you there! If not, you should consider coming to this excellent conference.

-Kevin

-Follow me on Twitter!

Capturing Attention: Writing Great Session Descriptions

Adam Machanic — Fri, 22 Feb 2013 14:00:00 GMT

One of the best ways we can differentiate ourselves and further our careers is to get out of the office… and onto a stage. Presenting can give you name recognition; open doors to new opportunities; help you gain a deeper understanding of technology (teaching a topic often forces you to learn it at a much deeper level); and for many people it's simply a fun and satisfying pastime. Each year there are dozens of speaking opportunities available to you: brown bag talks at your workplace, local user groups, online (virtual) user groups, community events, and conferences, just to name a few.

Virtually every speaking engagement, no matter how large or small, has something in common: attendees want to know, in advance, what is you're going to be talking about. They want to know whether they should spend their valuable time watching you, watching some other presenter, or perhaps staying at home and catching up on some sleep. And attendees will make this decision based upon an all-important document, the session description.

I've been speaking publicly and running events for just shy of 10 years now, and in that time I've read thousands of session descriptions. Some were decent, some good or even excellent, and most were very, very bad. I've also seen a lot of potential speakers--many of whom had extremely interesting topics and content--get rejected by events because they made basic mistakes in their session descriptions.

Writing a great session description is hard work. There's no way around it. But it's work that you need to do if you want to become an accomplished public speaker, especially at competitive events like large conferences. I like to think that I've done pretty well in this area, so in the interest of reading much better descriptions at upcoming shows, I'd like to share what I've learned over time: what matters, and what doesn't, when it comes to describing your sessions.

Overview

To begin with, what is a session description? I struggled with this one a bit; I wanted to talk about abstracts, titles, and levels all in one go. I decided to group them together under the umbrella name "session description." For the rest of this post, when I refer to that term I'm talking about all three parts. When I want to talk about only one of the components, I'll refer to it separately. Let's do that now.

An abstract is a paragraph that is supposed to describe what you're going to talk about in your session.

A title is a small number of words that are supposed to describe what you're going to talk about in your session.

A level is a number that's supposed to help guide who should (and should not) attend your session.

Another definition is also in order, and that's for the word great, which I've used in the title of this post. Greatness is, naturally, highly subjective. So for the purposes of this post I'll define a great session description as one that, for the correct people, captures their attention, whets their appetite, and makes them actually want to see you talk. That's kind of the point of the whole thing, right?

Your Audience and The Real Goal

Before you begin working on your session description, it is important to realize what it's going to be used for. Your session description is for attendees. It's for the event organizers. And it's also for you. It has three purposes in life! These are not necessarily conflicting purposes, but you should weigh each of them carefully before writing.

Attendees will use your session description to decide whether they want to attend your session.

The organizers will use your session description to decide whether to give you a speaking slot.

And you can use your session description to set expectations and keep yourself constrained.

Your session description is, first and foremost, a piece of marketing collateral. You are selling a product: your session. You must first sell it to the organizers. Then you must sell it to attendees. Then you must deliver what you sold. If your text underwhelms you will fail to get the chance to deliver or fail to attract an audience. And if you oversell you will end up creating promises that you can't keep or risk attracting an audience that may not appreciate your work.

Sales is all about understanding the needs of the people you're selling to, and solving their problem. To sell to the organizers, try to understand the mission of the event and fill appropriate gaps. To sell to attendees, try to understand the audience you're targeting, and write a session description that will help them. These two things are not at all independent of one another. Submit sessions to events that appeal to the attendees you hope to speak to; there is no real benefit in attempting to get yourself booked for inappropriate venues.

You Are Not Your Audience

Remember this always: most normal people attend technology events on the premise that doing so will make their lives easier by helping them learn to do their jobs better. Most people who work for a living do not care about technology for the sake of technology. They want to solve problems at work so that they can collect a nice paycheck and enjoy life outside of work. Most people are not at the event because they're ubergeeks. Most speakers are ubergeeks and forget this. If you're reading this you are probably not normal.

What does this mean for your session? As a presenter, you're much more likely to have a successful run of things if you target the majority of the potential audience, rather than a small niche group. This means helping all of the "normal" people. Don't get me wrong; these may be very technical people who are advanced technology users. But you won't attract them with pure geekery. They don't want to check out your cool technology, no matter how cool it is, just because it's cool. You need to appeal to their sense of purpose.

Tell a Story

How do you appeal to your target audience? Easy:

Figure out who they are
Figure out what problems they need to solve
Help them understand that you know who they are
Help them understand that you appreciate their problems
Help them understand that you can help them solve their problems

In other words, relate to your audience, and let your audience know that you relate to them. People like hearing from other people who share similar backgrounds and experiences. And people like hearing stories. Humans have been listening to stories for tens of thousands of years. It's how we're wired. Weave a compelling story and people will want to come and listen to it.

A great session description is a small story. It's a prelude to the larger story that you'll tell later in your presentation. It's the dust jacket on a great book, or the trailer for a new movie. Each of the three component parts should work together to draw the audience in, get them interested enough to want to keep going, and leave them wondering how the main character is going to escape the fire breathing dragon. A truly great session description will leave each member of your target audience with the understanding that he is the main character, and the fire breathing dragon is the problem he faces at work each week. Accomplish that and audiences won't be able to stay away from your presentation.

A common question asked by new speakers is "what should I speak about?" (Alternately phrased, "what should I write a session description about?") The answer, truth be told, is that it really doesn't matter. Or at least it shouldn't matter. Choose topics that you know well, are passionate about, solve a problem for you, and, most of all, about which you can tell your story. Chances are excellent that other people out there feel the same way (or your great session description will compel them to feel the same way), and you'll have no trouble finding an audience.

Your Session Description and the Relative Importance of its Component Parts

Earlier I introduced the three component parts: The title, the abstract, and the level.

In theory each of the component parts would be digested together by your audience (attendees, organizers, and/or you) and considered as a single piece of work. In reality that's not what happens. Each of the component parts has its own relative merit, depending on what stage of the game your session description is at.

Here's how things usually work:

You, if you're like most speakers I know, will spend some time writing the abstract, then throw in the title, and will hastily tack on the level as an afterthought.

The organizers will judge you on the title and level (based on what they need for the event) and if sufficiently interested will take some time to read the abstract. Let's assume that 80% of the abstracts get read at this stage.

The attendees? Depending on the event, many of them will never see your abstract at all, and may not see the level. If you're the only presenter at a user group one evening, most of the attendees will probably at least have the chance to read your abstract. But, you know, TL;DR. People can't be bothered to read a big paragraph full of, like, words.

The bigger the event, the worse it gets. The majority of attendees decide where to go based on the little printout or booklet they receive when they show up. These usually contain a schedule in a grid format, with only room enough for session titles. Usually levels don't make it to that schedule, and some events don't even include the speakers' names. That means that the entire decision is based on those few words in your title. I would estimate, based on interactions I've had, that only 25% of attendees ever bother reading abstracts.

The title is the only thing read by everyone, guaranteed. It is, therefore, the most important piece of your session description. The abstract is the next most important, and the level the least important. That said, you should determine the level first. Why? Because the level drives the language used throughout the rest of the description.

Levels of Confusion

Session levels are, on the best of days: stressful, vexing, misinterpreted, mostly worthless, improperly used, and entirely subjective. Most attendees don't understand what they mean, most speakers don't understand what they mean, and most event organizers don't leverage them very well. The central problem is that a topic that's really difficult for me ("level 500") may be dead simple for you ("level 100"). So what's the point?

Session levels don't have to be completely useless. They can help you figure out who your audience is supposed to be, and help you properly target these people by using appropriate language.

Most events--at least in the Microsoft space--use five levels. 100 is supposed to be for the most basic stuff, and 500 for the most advanced stuff (some events, like Microsoft's TechEd show, max out at level 400). Personally, I compress things down and try to focus on three basic levels:

Level 1: Material for people who don't know much about what I'm talking about (a.k.a. level 200 or so)

Level 2: Material for people who've used what I'm talking about but aren't experts (a.k.a. level 300 or so)

Level 3: Material for people who want in-depth details on what I'm talking about (a.k.a. level 500 or so)

Each level determines not only the content I'm going to present, but also drives the terminology I'll use in how I describe things.

Consider a talk on SQL Server AlwaysOn. Both the session description and the presentation itself should be aligned for the audience target.

At Level 1, the talk would describe the basics, starting with what the terms "high availability" and "disaster recovery" actually mean. Perhaps a brief high-level review of various technologies that solve these problems, and a look at how AlwaysOn tackles some of the key areas. The problem this talk would helping the audience solve is how to make sure that databases and their data are available whenever users need them. The story is a tale about technological advances and how easy it can be to keep the data flowing, even in the face of disaster.

At Level 2, deeper and more in-depth language would be used. How do "availability groups" work, and what general architectural choices should be made? What are the pros and cons of "synchronous" vs. "asynchronous" commit modes? The problem in this case is understanding the complexity of actually using AlwaysOn. The story is about connecting features and options to real-world use cases.

At Level 3, focused and specialized language is applied. Both the session description and the talk could reference "listeners," "quorums," "replicas," and so on, without any need for explanation. At this level we're usually targeting fellow ubergeeks, so there may be no real problem we're helping to solve. But--as always--it's very important to tell a story to help engage your audience.

In each of these cases, the appropriate language should be used in both the title and the abstract as needed. This enables each component part to communicate something about the level to the reader--without the reader ever having to actually read some arbitrary number.

Designing Your Title

So you've decided that you want to do a talk on the brand new, supercool, game changing feature that's going to be released next month. We'll pretend that it's called "Hekaton." (Sorry, but it's not really going to be released next month.)

To recap, the goal of your title is to:

Reflect upon the appropriate audience level
Draw in the correct audience
Create enough excitement to make them want more

The average session title submitted for SQL Saturday events (based on a quick perusal of the archive) is around 5 to 7 words long, and that's probably not enough. One of the biggest mistakes I see new speakers making is thinking that a short and succinct title is great. So they submit sessions with titles like:

"Hekaton in SQL Server v.Next"
"Hekaton for OLTP"
"Using Hekaton for Faster Transactions"

The problems abound...

These titles all use a code word, Hekaton, which only certain—and very specific--attendees will actually know. And they're probably not your target audience, because most normal people don't know the term. (Again, "normal" refers to non-ubergeeks, i.e. people who have a life, i.e. the people you probably want to reach.) At the average conference, attendees can sit through maybe five or six talks each day. So committing to a mystery topic? Think about it this way: If you're looking down at your schedule grid and you see one of these sessions, with a term you don't know, and it's up against a session that appears to solve a problem you do have, which option are you going to take?
These titles feel vague and too general. If someone already knows what Hekaton means, chances are good that he won't bother attending these sessions, because he won't be likely to learn anything new. Furthermore, these session titles don't appear to help anyone solve a problem, with the possible exception of the last one. And that one sounds a bit like it's going to be a sales pitch.
These titles are boring. Seriously. I fell asleep while writing them. If your title bores me, chances are good that your talk is going to bore me. And I don't like being bored. No one does.

So what do we do here?

First of all, since this is a brand-new feature that still uses a code word, this talk can't possibly be advanced. Even if you've been in a special early adopter program and have in-depth knowledge, there probably won't be an audience for you. So this is going to be a beginner-level talk, and the code word has got to go. Hekaton is an in-memory database solution designed to help speed up transactions. Can you pull a something from that description to explain the feature in just a few words?

Second, you need to clearly identify the problem you're going to help attendees solve. Which attendees have problems with transactional latency? Probably those with lots and lots of concurrent database users. And it's probably a good idea to help the audience identify itself as it reads your title.

Third, you need to get these attendees interested enough to either read your abstract or--for the 75% who won't read it--actually show up at your session just on the merits of the title. This means adding a bit of verve: showing some emotion, exposing your excitement, displaying your personality. Something a bit non-technical to indicate that this session isn't going to be nap time.

Putting it all together, we can come up with some pretty decent titles that do a much better job:

"In-Memory Solutions for Massively Concurrent Database Dilemmas"
"100,000 Users and Going Strong: In-Memory Transaction Processing Done Right"
"From Cessna to F1: Moving Your Heavy OLTP Workload to Memory and Beyond"

The code word has been eliminated. The audience can identify itself (those with "massively concurrent" databases, those with lots of users, or those with heavy OLTP workloads; all the same audience, just different ways of addressing them). The titles project a problem and hint at a solution. And each of these titles reads like a human actually put some thought and effort into them. (Well I think so. Nothing like painting a target on my back!)

The key to all of this? Relate to your prospective attendee. Don't bore them. Help them. And don't be afraid to use a few words to get there.

As an aside, there's this thing called title case. It's a set of rules for how to capitalize your title, and you should learn it. Failing to properly case your title makes you look like a total amateur.

Writing Your Abstract

At this point you've identified your attendee target, established a level, and drawn up one or two potential titles. (Write a few of them if possible; don't constrain yourself!) Now it's time to write the biggest portion of the session description: the paragraph-long abstract.

First things first. All of the rules already described apply here. Tell a story. Use appropriate language for your audience target. Don't be dull.

A well written abstract should expand upon, and complete, the narrative that the title started. It's the same message, but you have a lot more room in which to deliver it. When I read an abstract I look for organization, flow, and depth. All things that can help me decide whether the session is worth my time. If your abstract is disorganized, doesn't convey a starting and end point, or isn't at the right level, it's going to translate into the audience thinking the same about your talk.

The biggest sin when creating an abstract? Failure to even try. I've read countless single-sentence abstracts, especially those submitted to small community events. If you can't spend more than 30 seconds writing your abstract, how can I trust you with 75 minutes of my time?

Don't do this:

Attend this talk to learn how to use Integration Services in SQL Server 2012 to help with common ETL tasks.

Did I mock this up? Kind of. I just grabbed a real SQL Saturday abstract (on a different topic) and changed the words around. So yeah, this is essentially real, and every time I see it I cry a little bit, because no one should have so little enthusiasm about his topic and an expectation that he's going to make any audience care. This abstract probably won't fly at SQL Saturday, and it definitely won't fly at a conference. Just don't do it.

So what should you do?

Reflect upon the title. Re-state the problem, but in more words. If possible, refer to the audience. Draw them in.
Describe how what you're going to talk about is going to help address the problem. Give them a hook.
Conclude, re-stating the problem and re-affirming the hypothetical solution. Seal the deal.

A good abstract should, in my opinion, be at least five or six sentences long. Not too long, mind you--you're not trying to write a book--but long enough to thoroughly set expectations.

Start by reaffirming that the reader is the correct reader. For a beginner-level SSIS talk similar to the one indicated above, I might begin by describing a familiar scenario:

You have loads of data sitting in flat files, Access databases, and Excel spreadsheets. How are you going to get it all into one centralized database?

Now, hopefully, some readers are nodding their heads. They're saying, "you're right, I do have loads of data sitting around in various forms. And I really am having a lot of trouble getting it into the database." Now I've drawn in my target audience. I've reminded them of their problem. And I haven't used any jargon; remember, it's a beginner-level talk.

Also notice that I am directly addressing the reader ("you"). This is done very much on purpose: I want to reinforce that my talk is for my target audience, and that I'm thinking about and talking to my target audience. I'm not writing this abstract for some random group of people I don't know and don't understand. And it's certainly not for me (or the "royal we"). I'm writing this abstract for a very specific group of people I want to help.

Next we get into the hook, the section designed to make readers interested in your solution for their problem. The solution, in this case? Integration Services, which, in theory, is a great way to tackle the problem. But why is it great? Tell the reader.

SQL Server Integration Services (SSIS), first introduced in SQL Server 2005, is a comprehensive tool designed to help ease all of your data loading headaches. In this session you will learn the basics around how SSIS is designed and how to manipulate both the logic and flow of data in your load processes. You will see how simple, yet effective, the SSIS user interface can be, and the ease with which even complex problems can be tackled.

Now I've answered several questions for the reader:

"How am I going to solve my problems?" By using Integration Services.
"Well I'm running SQL Server 2008, not 2012. Can I still use it?" Sure you can. It was added to the product way back in 2005.
"What are you going to show me?" How to use the Control Flow and Data Flow. Oh wait, I didn't say that in the abstract. That's because it's an abstract for an audience that hasn't used SSIS, and those are jargon terms. Instead I mentioned that you can control logic and flow of data. I didn't even use the term ETL, because I want to target the absolute beginner. Anyone with a basic understanding of databases will understand what I'm getting at. Anyone who is knowledgeable in SSIS is going to read this abstract and immediately know that this talk isn't for them. And that's the goal.
"Is it difficult to use?" No, it's "simple, yet effective." I said so right in the abstract!

In addition to answering these questions, I've kept most of the tone active. Active voice is one of the keys to a great abstract. It tells the reader that there is value to be had here, that this will actually impact his job and his bottom line, and that he shouldn't expect to attend and sit there, mouth agape, drooling and waiting for the bell to ring.

I could leave the abstract as-is at this point and call it a day. But I like to end on a really positive, upbeat note. I want my reader to walk away excited by the prospect of attending my session. So I seal the deal with a conclusion that restates and ties everything back together.

There is no reason to allow a data mess to ruin your day; after attending this session you'll have the necessary SSIS knowledge to easily extract data from virtually any source, transform it into whatever shape you need, and quickly load it into the database of your choice.

If I've done everything right, the target audience member has finished reading and is saying "wow... that's exactly what I want to do."

What Not To Do in an Abstract

Over time I've noticed a few things that don't quite work:

Bullet points. Bullets are a great way to organize information into small digestible chunks. I've used plenty of them in this post. I'm even using one now to talk about why you shouldn't use bullet points. Oh, the irony. Anyway, the fact is that once you submit your session description for an event, you usually have no control over its formatting. And events botch the formatting all the time. Usually abstracts are compressed down to a single paragraph, so I recommend that you write your abstract as a single paragraph. Bullet points will tend to get rendered into something like this:

This is my abstract about some cool new technology! I'll be covering such issues as - Using the technology - Installing the technology - Making friends with the technology - Harassing enemies with the technology - Formatting and line breaks using the technology This technology will change your life so attend today!

Using your own name in your abstract. Some people like to say things in their abstracts like "In this session Steve will show you why it's great to be a farmer." This works, in very limited cases, but most readers are going to say "Steve? Steve who?" They're going to think you're a deranged egomaniac, and they're not going to want to attend your session. If you've read this far you know that I like to think about the normal people; the ones who aren't plugged in to the community 24x7, because they have something better to do with their time. They probably don't know who you are, even if you include your last name. Sorry.

Insulting the reader. Never, ever, ever assume that you're the smartest person in the room, unless you're alone in the room. And be very careful with assumptions about your target audience. Sometimes I'll see abstracts that say something inflammatory, like "if you're a .NET developer creating a data model, you've no doubt screwed up several key aspects." While this may be true in your mind, and might even be true in reality, what you're doing is alienating the reader. A better way to phrase this would be something like "due to various differences between the platforms, .NET developers attempting to create a SQL Server data model may encounter a number of tricky situations." Now the reader can think back, realize that he has hit one or more of these, and become interested in your content. And that's a win.

The Aftermath

If you've written your session description with only 15 minutes left before the event closes its submission period, you're pretty much in the same boat as everyone else. Oh, and you're doing it totally wrong.

The very first thing you should do after you complete your work? Read it yourself. And then read it again. Read it slowly and carefully, word by word. You will find a typo. You will find a grammatical error, or a phrasing problem. If you don't, you're not looking hard enough. And run it through a spell checker. There is nothing that says "careless" more than a glaring error -- and, again, a glaring error in the session description is indicative of lots of glaring errors in the actual talk.

The next thing you should do is to pass the session description around to some people you trust. Preferably one or two people who are in your target audience, to tell you whether you've created something of interest. Preferably one non-technical person, to screen it for jargon and do a second copy edit. If the non-technical person is just a bit lost, that's okay. If the non-technical person is totally lost, chances are most technical people will be, too. Clean it up.

If you're writing in English and you're not a native writer, find a native writer and have him proof your work. Neither event organizers nor attendees care about why your abstract is full of grammatical errors. You probably write in English a lot better than I can write in your language, and I have massive respect for you, but you're still out of luck if your work can't be properly understood by English language audiences.

After that, paste the abstract into the web form, hit Submit, and ... wait.

Submission for larger events is a painful process. You put your abstract in and sometimes have to endure 90 or more days of wondering before you get your answer. Oftentimes the answer is nothing more than a "yes" or a "no." It's okay to ask for an explanation if you've been rejected, but it's also okay for the event to tell you that they don't have time to provide one. If you're going to start speaking regularly, prep well, build up a nice thick skin, and get ready to endure some rejection. Don't worry. Keep practicing, keep trying, and you'll get there.

Of course you also have to write the presentation. And as you do so you absolutely must use the session description you wrote. You've set attendee expectations; make sure your actual session will live up to them. Your presentation should cover everything you said you were going to cover and, if your session description was properly worded, not much that you didn't mention. Naturally, writing the session is an entirely different topic for an entirely different blog post.

Summary

A great session description is a short yet compelling story designed for a very specific reader. The reader is the protagonist, his problem is the antagonist, and you are the narrator, helping the reader through his quest for glory. Know your target audience, understand its problems, help solve them, and your session description will be wildly successful. Remember that most readers only look at a very small part of the story, the title, so make sure to spend plenty of time there. And remember to always keep things moving and interesting; there is nothing worse than a boring story.

I'm sure many of you have opinions that differ from what I've expressed here. I look forward to hearing from you in the comments section below. Likewise, for those of you who have questions I may not have covered above. Finally, I would like to invite readers to post their own abstracts for public criticism. (Constructive!)

Thank you for reading, and I’ll see you on stage!

Demo Mastery for the Technology Evangelist

KKline — Fri, 15 Feb 2013 17:02:00 GMT

In the same way that the finest presentations involve much more than the simple relaying of information, the finest software demos are much more than just presenting features.

REMEMBER: The goal of a demo is to INSPIRE the audience to use the software/technology, not to teach them every nuance of software/technology.

I've spent the last 10 years learning how to give good presentations and to give good software demonstrations. Here are several tips to take your software demonstration from informative to masterful:

1. Know your audience

Whenever you start a demo, make sure you have a good idea what the audience is interested in. That way you can focus the attention of the audience upon things that actively engage their imagination. You really, really want the audience to be thinking about how they're going to use the software that you are presenting. If it if you're not presenting on something that they're interested in, they'll mentally disengage. In some cases you'll even see them open their laptops and start to answer emails. That's the last thing in the world that you want to happen.

In many cases, I'll begin a presentation by asking my audience to tell me more about themselves. I want to know how much of their time is spent as a developer, as a DBA, as a designer. If nothing else, I can change the sort of examples that I use to be tailored specifically to the audience that are presenting to.

Truly bad software demos have problems. The code doesn't work. The beta software crashes. The screen shows the dreaded blue screen. But that's one thing. What you really want to avoid, is the truly mediocre software demo. The quickest path to a mediocre software demo is to simply show every feature and explain each in as much detail as you can. It's like those games that sit in our closet that no one likes to play. Most all of these games are ones in which one person takes a turn while everyone else waits. No one has any fun except for the three or four minutes in which it relates directly to them.

2. Start, but only start, with an agenda

It's always a good idea to inform your attendees of what you would like to present. What you present the agenda it's a great idea to confirm that this agenda is what the audience is looking for. Before I learned to do this on a regular basis, I found that my presentation might contain two or three lengthy sections of my software demo which were completely uninteresting to the audience. The customer is really numbed by this waste of time. It's far better to tell the audience what you are going to tell them.

Here's my routine when I start a demo. Confirm that your agenda is of interest to them and recheck the time constraints of the meeting. Then, get to what they are interested in. This flexibility also provides you the opportunity to inject other software demonstrations that are much more pertinent to your audience. Audiences love a presenter who can think on their feet and are flexible to the interests of the audience.

3. Skip the lengthy intro

This is a aspect of demonstrations and presentations that I struggle with. I worried a lot that I hadn't demonstrated enough credibility with my audience. And so for many years of my technology evangelism role, I spent a lot of time telling the audience about myself and about the company. What I found over time though, is that audiences actually give you an initial dose of credibility. It's up to you to maintain and even enhance that credibility through a strong demo and a good presentation. Better to have a very short introduction and get straight to the meat of the presentation.

Call out - Mouse Cursor Movement: It's especially important to remember in online demos that there is usually a great deal of latency between what you do on your screen and what your audience sees on their screen. So it's important to remember to MOVE YOUR MOUSE SLOWLY AND THOUGHTFULLY! I've sat in online webcasts, and even in in-person events, where the mouse literally disappeared on one section of the screen and reappeared elsewhere because the presenter was moving their mouse cursor here, there, and everywhere. If you want the audience to see what you're doing with the mouse cursor, keep it slow.

4. Show what is pertinent

One of the most important things a software evangelist can do is to show the most important and pertinent take away of their software. Let's you are trying to teach an audience about the extreme ROI (return on investment) of a particular kind of business intelligence strategy, it's crucial that you figure out in advance what are the key takeaways that you would like your audience to remember. Typically in audience will only remember two or three very salient points about your demo. If the BI presentation spends the first 30 minutes showing how to build a report but never once mentions ROI, what do you think the audience will remember? Once you know what is pertinent to your audience and what you want the key takeaway to be, you should focus the rest of your energies on building an airtight demo that supports those takeaways.

You will see the inverse of this many times in a mediocre or poor demo. At the end of the demo the audience will feel like they have sat through product training, rather than a call to action that inspires them to use the product. I've sat through demos in which the presenter carefully walk through several different menus, tabs, and wizards. And after 30 minutes of that, I now knew HOW to use the software, but I still didn't know WHY I would use the software.

In the worst cases, showing everything that your software can do may leave the audience feeling that it is too complex, too detailed, or too overwhelming for them to use effectively. Remember that a software demo is not design to train the audience. A software demo is designed to inspire the audience to use your products.

5. Don't get sidelined

We usually get sidelined in our demos by two things: questions from the audience and "technical difficulties" a.k.a. bugs.

Questions from the Audience

It's usually a good sign if your demo is provoking questions from the audience. However, you don't want to demo to turn into free consultation to solve one person's problem. Nor do you want to turn into fact-finding for one very narrow set of interests or to become the arbiter of some sort of political dispute between factions in the audience.

When taking questions, remember to repeat the question to the audience. This ensures that you fully understood the question, that the questioner asked for what they meant, and that if there is any recording going on the question will be picked up by the recording system.

But my typical rule of thumb is to only spend a couple minutes on a single question and questioner. Once a single questioner goes beyond a couple minutes, you can usually tell if you're heading for the sidelines. It's at that point that I asked the questioner if we can take the question off-line and come back to it afterwards so that everyone else can benefit from the time that we have set aside right now.

Technical Difficulties

Another form of sidelining are bugs in the software and outright crashes of your demo environment. Many times this simply can't be avoided. This is especially true if you are demoing a beta version of the software. But there are couple important things to remember if you are sidelined by a bug or crash.

First, mention if you're using a beta and that it might not be fully stable. Also, be sure to mention that the software WAS stable when you prepared the demo. Second, test your demo after conducting a full reboot of your demo environment. I've seen many demos crash because the presenter made other changes in the environment but only tested for the software demonstration itself. Third, Don't draw attention to bugs that you encounter during the demo, especially if they're just cosmetic. It's important not to do things like slap your four head and exclaim "what the hell is that?" If it's a bigger bug that hampers or interferes with functionality, you might state that it's normal functionality is… XYZ. Finally, if you experience a major bug or crash, immediately disconnect the projector or the desktop sharing application. There's nothing worse than seeing a presenter struggle with the bug in front of the entire audience.

6. Hit the jackpot

All good jokes have a punchline. All good action movies have a climax. All good newspaper stories have a headline. Your demo needs to have a jackpot, where the audience can clearly and immediately see how your software pays off.

Let's say you're doing a demo of the new columnstore features in SQL Server 2012. You could spend a lot of time showing the conceptual underpinnings of a columnstore index. You could show the state was to create columnstore indexes, to modify them, to drop them. You could admonish the audience and ways to build read-write systems so that they can easily get data into and out of columnstore indexes.

But what's the real payoff of a columnstore index? It is incredible fast for a particular kind of scenario on SQL Server. So in this example, your jackpot is to show how difficult that scenario is under normal circumstances and then immediately show how easy and fast it is with the columnstore index. Bingo! Your audience is hooked. They immediately see why they want this. There inspired to start using it. Now, they want to figure out how to use it and want to know when and under what conditions they should use.

Are you an SC, technology evangelist, or technology presenter? What are your tips for a better demo?

-Kevin

-Follow me on Twitter

Learn More About SQL Server IO and Query Tuning in These Webcasts

KKline — Fri, 14 Dec 2012 18:50:00 GMT

I'm doing two new webcasts next week on Wednesday, December 19th, one in the morning and the other after lunch.

SSDs are a Game Changer for SQL Server Storage

No, session is not exclusively about SSDs. But this is my first session on IO and storage tuning that emphasizes SSDs over hard disks. As Bob Dylan said "Times, they are a'changin'". This session on Wednesday, December 19th at 11:30 AM EST, sponsored by Astute Networks, takes you through all of the basics of storage and IO tuning, regardless of the underlying storage technology. I'll show you how SQL Server handles storage structures, how to identify IO activity on Windows and SQL Server, and best practices for minimizing IO bottlenecks. Register now for: Storage IO Best Practices for SQL Server and a New Approach to Solving Application Performance Issues.

Write Better SQL Queries

The next webcast on Wednesday, December 19th at 2 PM EST, is with me, Aaron Bertrand (Twitter | Blog) and SQLCruise Impresario & Microsoft MVP Tim Ford (Twitter | Blog) as we take you through the query tuning process, discussing important DMVs to use during query tuning, as well as demonstrating several essential query tuning techniques that every SQL developer should know. Not only are we presenting an hour of top quality technical content, we’ll also be giving away some cool prizes, including the grand prize of a paid registration for the upcoming SQLCruise Miami, a $1,395 value! Register now for: SQL Server Query Tuning Best Practices, Hosted by Kevin Kline and Aaron Bertrand with special guest Tim Ford

I hope to see you at both of these sessions next week! Best regards,

-Kev

-Follow me on Twitter!

A wee bit exhausted… time to reenergize

drsql — Tue, 11 Dec 2012 02:26:00 GMT

I admit it. I am tired and I have not blogged nearly enough. This has been a crazy year, with the book I finished writing, the pre-cons I have done (teaching is NOT my primary profession so I do a lot more prep than some others probably do), lots of training on Data Warehousing topics (from Ralph Kimball, Bob Becker, and Stacia Misner, to name three of the great teachers I have had), SQL Rally, SQL PASS, SQL Saturdays and I have gotten a lot more regular with my simple-talk blog as well… Add to this the fact that my daughter added a new grandchild to the family, and my mother has started to get so weak she is starting to fall down quite often (I am writing this blog entry from a spare bedroom at my mother-in-law’s house while my mom is in rehab!) and I am getting exhausted.

Am I whining? Probably, but it is my blog! No, seriously I figure that occasionally you have to poke your head out from under the covers and write something and this is my something until after the New Year (other than posting a few already written and edited simple-talk blogs). I am on vacation from work for 2.5 weeks, and I don’t plan to do much with this laptop of mine for those two weeks unless the spirit hits me with an idea for a blog that I just have to write, but usually most of my blogs that have any technical or artistic merit take weeks to complete. On the second of January, I hope to be back at it, analyzing my resolutions from last year, and making good on a few of them, particularly “Blog about my other (computer) love occasionally” and review some of the gadgets I have acquired as they pertain to doing my job as a writer/data architect. (Hint: My mother-in-law does not have Internet access, so some of the devices I have here are instrumental in my ability to work untethered for weeks on end.)

So until next year, Merry Christmas, Happy Holidays, Happy New Year! I hope your holidays are restful and fun. I know part of mine will be because I intend to replicate this picture at least one or two more times next week, hopefully with a Turkey Leg in the hand that isn’t holding the camera taking the picture (all with my Windows Phone set on Battery Saver Mode, which delightfully turns off all syncing :)