Search results matching tag 'Writing'

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!)

Why We Write #4 - An Interview With Doug Lane

drsql — Wed, 24 Apr 2013 02:56:22 GMT

My next guest is Doug Lane, who has been blogging for the past few years on his website: http://www.douglane.net/. Doug is also a speaker who has spoken at SQL Saturdays as well as the SQL PASS Summit, and as I write these interview questions was on his way to speak at the SQL PASS Business Analytics conference in 2013. I also liked quite a few of the pictures in his photostream here (http://www.flickr.com/photos/58251371@N06/), particularly because I tried the bean bag juggling, though I cannot find the picture anymore.

I have never met Doug personally (so as such have never mistaken him for anyone else), and am only acquainted with him through Thomas LaRock's Rockstar Blogger list, so I am looking forward to finding out more about him from the questions in my interview.

He also once won a SQL Cruise from Idera with this YouTube video:

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

I had a personal blog about 6-7 years ago but I struggled with it. I did two posts: one about music I listen to while running, and one about a camping trip I took. It was horrible and nobody read it. I'm hoping the internet found a way to bury it alongside my MySpace page.

Then, in late 2010, two things really pushed me to get back into blogging: Brent Ozar's blog and Steve Jones' presentation, "The Modern Resume". Steve convinced me that having a blog was important, and Brent convinced me I was capable of doing it. I'm immensely grateful for their influence. There's no way I'd be writing today without it.

I've heard stories from friends about how they had teachers that told them they weren't cut out for writing, science, athletics, music, and so on. It makes me enormously grateful to have never had a teacher like that. I had some uninspiring teachers, sure, but never one that told me I was destined to fail at something. In fact, several of my English teachers encouraged me to write. There's one in particular I'll never forget. Diana Daniels was my 7th and 8th grade English teacher. For one assignment, she gave me a note that said this:

I still have it. I've gradually thinned out the stuff I kept from school but that one always makes the cut. I still feel good when I read it, even though it's from 25 years ago. Sincere encouragement lasts a lifetime.

I would have LOVED writing for Saturday Night Live, Mystery Science Theater 3000, or Archer. I even chose my college, The University of Iowa, based on the fact they offered screenwriting classes and had a heralded creative writing program. While a writing career for film or television didn't come to be, I'm a firm believer in things happening in the right time and place. I can still write blog posts, presentations, and the occasional ultra-low budget screenplay with a sense of humor.

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?

Like all writers do, I think I'm getting better with practice. I'm getting better with tempo and efficiency. I'm also getting better at expressing my personality through writing without it resembling a train of thought. I'm a little faster now than when I first started. I don't struggle as much with how I'm going to say something.

On the other hand, I take more time now to make sure what I'm writing is technically correct. I feel like I need to be more accurate and informed on my subjects. When I first started, I thought, "If I miss this detail or that, it's okay." Now I try to make sure the minor details all check out too. As we all know, there's NOTHING worse than being wrong on the internet.

First, I'd make sure they were all in a room on the ground floor. Then I'd tell them that in 2013, all of the following will be vastly more famous than even the most popular blogger: a monotesticluar man who cheated like crazy in French bike races, a show about unclaimed storage units, an unfinished calendar from an ancient civilization, skinny jeans for men, and a singular picture of a cat who looks unhappy. Many writers will throw themselves out the windows in shock and despair.

Once the glass shard-encrusted writers have been pulled from the shrubs outside the window (we're on the ground floor for a reason), I'd tell them the good news. I'd show them fivethirtyeight.com, lifehacker.com, deadspin.com, and of course some SQL Server-related blogs. I'd tell them there are huge audiences for the things you're interested in. Combine that with the means to self-publish and promote, and no one can prevent you from being a success.

I'd also share the two thoughts really paralyzed me when I was first starting my blog:

Paralyzing Thought #1: "Someone already wrote about this topic."

Louise Hay put it brilliantly. Addressing a crowd at a convention, she said this: "You'll have all these speakers. We're all going to say the same thing, really. But we're going to do it in slightly different ways. And everybody wants to hear things differently. Just because I say something, some of you will get it, some of you will say 'What is that woman talking about?' But another teacher -- or three or six or twelve -- can say the same thing that I'm saying in different words. And you'll go, 'Oh, that's brilliant! Never heard that before.'"

Whatever you're going to write about, someone's almost certainly already covered it. But they haven't written about it your way. People may not understand an idea until they hear you explain it in your words.

Paralyzing Thought #2: "Nobody's reading this."

That's true in the beginning. Unless you're already well known, very few people will be anticipating your first blog post because you have yet to demonstrate quality and consistency. Your blog is like a retail store. If what you have inside is interesting or useful to people, word will spread and more people will come. Be patient.

It's scary putting yourself out there in printed permanence, I know. But nothing gets you past the fear of publishing faster than hitting the "Publish" button again and again. If you need ideas or motivation, pick up Problogger's 31 Days to a Build a Better Blog. You don't have to do all the exercises in 31 days. Just do one whenever you're stuck. (Let's pretend this e-book exists and I'm not violating the space-time continuum by recommending it.) Gradually, your content will get better and your audience will grow.

I'd conclude by saying, "Don't stress over it. Nothing about your blog is as big a deal as you think it is."

If I told Historical Me that he'd be interviewed about writing and it wasn't conducted from prison, I think he'd be excited.

5. Do you have any assistance from an editor, either formally or informally. And in either case, do you like your set up do you sometimes wish you had it different?

I don't have an editor, and I'm not really worried about having one until I start writing detailed technical posts. That day is still a ways off since I'm really enjoying the topics and level of complexity I'm covering now. I do like to bounce ideas off people, but I don't usually have finished posts proofread by someone else.

A bad habit of mine is proofreading after I've published. (Don't get me wrong, I proofread beforehand too.) I think every post I've done in the last year or so, I went back and updated at least twice after it'd been published. George Lucas admires my inability to leave perfectly good work alone.

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

I write because I enjoy it and I want to make people's lives better, whether it's getting people unstuck from a technical problem or just making them chuckle. The work I do is immensely enjoyable. I want to share some of that joy. I don't care if I'm paid for it or not -- that doesn't enter into my thought process.

Another reason I write is to establish myself as a resource people can come to when they need a problem solved. I'm not trying to come across as a technical expert (because I'm really not -- not by a long shot), but rather someone who's had to solve the same problems my readers are having. It's funny that 48% of my page views come from a post about connecting a MacBook to a projector. I had no idea that post would be so useful.

While I don't set out to write life-altering material. I have a powerful story coming that I hope will re-orient people. I'm waiting for the right time to publish it -- probably early summer.

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

One project I've had on the back burner for FAR too long: SQL Server Murder Mystery Hour. Like one of those murder mystery dinner parties, except done at a SQL Saturday or maybe one of the nights of PASS Summit. I've let this idea percolate for two years now (like I said, FAR too long). Here are a few ticklers:

Think Murder on the Orient Express, except it's a database or server that's killed.
Attendees form teams to solve the crime.
Names of the suspects are a gag, e.g., Bill Freeley is a consultant.
Slightly over-the-top, Poirot-style interrogations will reveal clues.

Okay, writing about it really has me excited to get moving on it again.

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

Wow, this has been a fantastic read. Doug has given a lot of great and interesting answers to my questions. Some notes:

I too loved Steve Jones' presentation, "The Modern Resume". Chock full of fantastic information about how to enhance your career and behave yourself (Brent’s blog is great too :)
I have always wanted to be a sitcom writer too. I took some advice from the early Simpson’s writers. The goal is something that is funny over and over again, not just once. I know I still laugh at the Simpson’s after 15-20 viewings of many episodes.
The George Lucas comment about not leaving well enough alone is a problem I have too.
I feel a good bit of kinship with his “why” answers too (other than the MacBook thing, I considered editing Mac references out…)

I am sad a bit that he didn’t hit on my answer to past me, but it will come one day. Like I have said before, when I get the same answer, I will interview myself…

I love the idea for the murder mystery, and am hereby invited to SQL Saturday Nashville .Next to do the SQL Server Murder Mystery at least as a session, or perhaps some other time.. (you will still have to provide your own transportation :).

Next up is Jason Strate (@stratesql), someone I have known for quite a long time (and have worked with several times), and am certainly looking forward to see what he comes up with. I have really enjoyed these interviews so far, and I hope you have too.

Why We Write #3 - An Interview With Rob Farley

drsql — Mon, 08 Apr 2013 17:04:14 GMT

In the third entry in this series, we take a turn south, not in quality, but in the geography of our next entrant. Rather our interview target is Rob Farley, who is from (well lives in) Australia.

Rob Farley is a SQL Server MVP, and is quite a busy fellow. He is the owner of a consulting company named LobsterPot Solutions, located in Adelaide, and is a current member of the PASS Board of Directors. His blog is located at SQL Blog, where I also blog, and he tweets under the extremely unobvious handle of @rob_farley. He speaks regularly at SQL PASS conference, and sang during the keynote with the one and only Buck Woody (http://blog.datainspirations.com/2011/10/14/pass-summit-2011-day-3-keynote/).

Rob has been a friend for quite a few years now, starting (in my mind) when I introduced myself to him at a conference thinking he was Arnie Rowland (yet another wonderful member of the SQL community, whom you might mistake for Rob from a hard working standpoint, but Arnie doesn't wear glasses regularly :). As I remember the story, neither were offended, much like when people mistake me for Orson Welles, I am honored because he was such a great writer. I will note too that Rob remembered it differently, but my version makes me sound far more intelligent. Rob is a tough one too, as I once worked with him on a Microsoft Learning contract in Seattle where he had recently had his appendix out (remember where he is from… and I get kind of sore from a 4 hour flight!)

So, now that we have gotten past the silliest parts of the interview from my contributions, on to the interview questions.

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

1. Think back to the moment you hit the first key, starting to write a blog, an article, a book, or whatever. What made you do it? Or perhaps, what were you expecting to achieve that was better than your previous use of free time. Have you gotten the benefit you were shooting for back then?

It was April 2005. I had been getting more and more involved in the community, attending the occasional user group, both .Net and SQL Server, and there was an all-afternoon event about SQL Server 2005 that I went along to. I’d already been thinking about getting into blogging, and a conversation with one of the evangelists from Microsoft who was at this event meant that I wrote my first blog post the next day. At the time, I just figured that it might be helpful for someone, but didn’t know who that might be. At the time, I was feeling like I needed to be stretched, and blogging gave me the chance to write about the things that I knew, and to go a little further with things than I had before. When you write things down, you find yourself wanting to make sure that it’s right – blogging gave me that then, and still does. Unfortunately, I cringe at old blog posts, as I think we all do [ed; I know I certainly do!], but I still enjoy the experience of getting content into a blog-worthy condition and publishing it for other people to read.

In school I had teachers that liked my writing, and teachers that thought it was awful. From that, I managed to discover that my writing had a particular style, a ‘voice’ (accent?) that could be heard. Today I value that in my writing, and try not to let it go. The times I’ve written book chapters I’ve worried a lot about losing that style, as editors often try to avoid having that kind of thing come through. It’s probably like how I’ve a tendency to use contractions. If I couldn’t’ve ever used them, I think I’d’ve struggled to write much, as people wouldn’t hear me in what I wrote. Perhaps JD Salinger had an effect on me, as Holden Caulfield’s voice came through so much in that book.

3. Can you describe the process you go through to write (including any tools you find indispensable), from inception of an idea until it gets put out for consumption?

This depends on what kind of thing I’m writing. :)

I’m very big on just opening Live Writer and pouring text onto the screen. Of course I’ll need to spend time in SSMS, getting the queries right to demonstrate the technical aspects, but I like to just get the text flowing. I’m very self-critical, which means that I don’t try to think how to phrase every sentence, or use just the right simile, but rather, I try to bring the reader into what I’m writing and explain things to them. I’m currently trying to get online training sorted which I call “Train-the-Explainer”, because I want to be able to teach people things in a way that helps them really understand the concepts of what’s going on, and I try to have that same idea come out in my writing. I’m likely to end up using phrases like “You know how…, well it’s like that,” in my writing, but when it comes down to it, I want people to read it as if I’m sitting next to them, explaining things to them.

What I find really hard is writing songs or jokes. I realise that I tell jokes, even during presentations, and I wrote a comedy set for the PASS Summit in 2010 and a song for 2011, but as much as I’d like to do much more of that, I really struggle. I really want to write both, but find myself crossing things out, or finding that things really aren’t as funny (or poignant or whatever) as I’d like. A co-writer would be good – someone I could bounce things off so that they can tell me when an idea is worth pursuing, and when my ranting should be converted into an actual joke.

4. Assume a time machine has been created, and you are scheduled to speak to a group of potential writers, in which you and I are in attendance. Without concern for the temporal physics that might cause the universe to implode making the answer moot, 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 to get excited for the day you will be sitting here for a rather long period of time answering interview questions and not getting paid for it, instead of feeling the warm sun on your forehead?)

Don’t get me started on the time travel thing. I have conversations with my kids about that kind of thing, like ideas around how paradoxes could get resolved… but back to the question!

If I could choose when to go back to, I’d go back much further… to a time when I thought I wasn’t any good at writing (ok, that’s typically still the case – did I mention I’m self-deprecating?), and was choosing to pursue a computer-focused degree. I’d tell myself to really explore the things that I enjoyed, including writing, and to just get started. I could put so many things in that bracket – comedy, writing and music are some that I’ve already mentioned – but I keep finding myself way more interested in people than in technology. I enjoy teaching (adults, not kids), I enjoy ministry, I enjoy community, but my career has largely been focused on technology. I’d tell those potential writers to start doing those things which define them. Solving puzzles can be fun, but unless those puzzles are allowing you to be creative, then they may not be completely satisfying. Of course, I doubt it would make a difference. Someone who’s good at maths will see the creativity in that and still end up in IT.

5.Finally, beyond the "how" questions, now the big on. There are no doubt tremendous pulls on your time. Why do you do write?

This comes down to that last question. I write because it’s something which lets me be slightly closer to what I want to spend my time on. I’d like to be completely financially independent, and be able to spend my days helping other people with things. My career as a consultant lets me do some of that, but not in the way that I really want. Those people who ask me for help with things probably know that I quite willingly invest myself into their particular problem, and I honestly do it completely for them, because I enjoy it. Writing lets me do that in a way that means they don’t have to ask – for those people that go looking for something and stumble across it.

Finally, a bonus question I provide to let the person stretch the topic and talk about anything they want to:

1. Is there any project you would like to tell people about that we haven't yet mentioned?

I should be better at marketing, but I’m really bad at it. I should write some stuff about how LobsterPot is a great company that you should all use to improve your data story. We can help you write better T-SQL, tune your system, get your data into a data warehouse, even present it in the amazing PivotViewer platform that we ported to HTML5 so that it runs on iPads. I should write about the Train-the-Explainer thing that I want to do, where I’ll charge people a small amount to attend an online classroom (limited sizes) to have me explain SQL stuff to them in a way that hopefully means that they can not only implement the ideas, but can actually explain it to other people. I should write about how I’m available to teach Advanced T-SQL courses, and will happily come to just about anywhere in the world to do so (although it’ll be at your expense, and it’ll have to fit into my course schedule). But I’m not good at self-promotion, so if your readers want to ask me about these things, they should probably just drop me a line and start a conversation.

…I’m always happy to talk. [ed. @rob_farley is his twitter if all else fails]

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

I definitely want to thank Rob Farley for taking the time to answer my interview today. I got a bit more insight into how yet a third person thinks about the process and value of the writing process. His why answer reminds me of some of the reason I got started answering forum posts. I don’t always love helping individuals directly because usually when you have gone out and asked a question, you are lost and just need that straightforward how do I get out of this jam, answers. Kind of like when you go to the gas (petrol?) station and ask for directions. If they start telling you how you should have planned ahead, while it is good advice, it can tick you off. The only person who is apt to learn a lesson there is a bystander who hears the answer. Since they aren’t lost, hearing how to ever avoid being lost may be useful. When writing. I always try to help with the immediate need first: “the bakery is a block that way”, and then “the app you have on that phone I see will tell you how to get there if you are ever lost again”. They might not care, but the next reader might.

Still not the answer I would give to the time machine question (other than the paradox stuff!), but I love Rob’s answer.

The next entry will be Doug Lane, who works in BI. He will be speaking at the PASS BA Conference this week (4/10-12, 2013; so don’t go there if this is 2020 when you are reading this and blame me), so feel free to suggest answers for him if you see him there!

Why We Write #2 - An Interview With Mark Vaillancourt

drsql — Thu, 28 Mar 2013 17:30:12 GMT

My second guest is Mark Vaillancourt (whose last name makes me very happy for the copy and paste feature), who is an Information Management consultant working for Digineer, and is a Regional Mentor for PASS in Canada. Mark is also a speaker at SQL Saturday events, as well as the SQL PASS Business Analytics conference in 2013.

Mark has been blogging regularly since early 2009 on his website (http://markvsql.com/), and interestingly, has degrees in English and Theater, two degrees that almost always lead one into a career in technology. His twitter account, @markvsql, is also quite active with over 6400 tweets to date. To be honest, I don't enter into this interview knowing nearly as much about Mark Vaillancourt as I did about Thomas LaRock in entry #1, as Mark is more involved in Business Intelligence while I spend most of my conference and blogging time in the OLTP/Relational Engine side of things. I am looking forward to learning more about his writing process and his career in his answers to the following five questions.

Mark is currently working on his first white paper to be published via Digineer’s website. He wouldn’t reveal the topic, but describes it as a topic that he feels is under-served and will help a lot of people. I hope he will give me the link to include in this interview when he gets it finished.

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

1. Every superhero has an origin story, and in many cases it wasn't because they specifically were planning to go into the field of superhero-ness. I mean, clearly Peter Parker didn't really want to get bitten by a radioactive spider. So what is your story that led you to spend part of your free time writing about SQL?

In my early days at Digineer, Lara Rubbelke, who actually hired me during her tenure there, encouraged me to blog about my experiences learning SQL Server. Since I was hired there having never worked with SQL Server before, there were sure to be many learning opportunities. Whenever we would talk about the obstacles I was encountering and what I was doing to overcome them, she would always end the conversation with, “Blog about it.” I finally took her advice and got a blog connected to the old Digineer website. It was some time later that I ended up heading out on my own for my blog, including getting my own domain, with a lot of great advice from Jason Strate. Jason pointed me to, among other things, Brent Ozar’s series about blogging. That was really helpful in getting going. (Editor note: here is a link to his advice on his blog a few years back http://www.brentozar.com/archive/2008/12/how-start-blog/)

I had a teacher in high school for English, and also for Creative Writing, named Richard White. He taught me the power of verbs, the importance of dialog, and reinforced the old writing axiom, “Show; don’t tell.” While these three lessons were aimed at fiction, I try to keep them in mind in my technical writing, as well. I try to make my writing sound like I am just speaking. To me, in essence, a blog post is a presentation I only have to give once; a presentation that keeps on presenting, if you will.

I have also been fortunate enough to have an unofficial blogging mentor: Jason Strate. While he was working to take his own blogging to the next level, he was constantly sharing lessons learned with me. Whether it be a new tool he had tried or just even a bit of blogging philosophy, he set a great example. Many thanks to Jason.

3. Can you describe the process you go through to write (including any tools you find indispensable), from inception of an idea until it gets put out for consumption?

As far as tools go, Snag-It is the best thing ever. I love that application, and not just because my laptop lacks a “Prt Scn” key. It is so easy to capture screen shots of just about anything and apply highlighting, arrows, shapes, just about anything. I rely on it heavily for images I use in my posts, and sometimes presentations as well.

Although it is not really a tool, I have to say the Flickr is an AWESOME place to get images for blogs and presentations. Jason Strate showed me that one several years ago. Just filter your search for Creative Commons content and provide links to the source for the images you use and you are off to the races. I have found so many great images out there.

As far as process, I don’t know that I have one. But I think I can nail down some actions that I tend to take during the creation of many of my posts.

Find/Create a fun dataset.
- The people that created the AdventureWorks database worked very hard to do so and provided examples of a lot of different things in the process. They deserve our gratitude. However, I try very hard to avoid having my blog posts and presentations be about selling bikes and accessories. If you look over my posts, you will see data examples relating to Super Heroes, The Smurfs, Romeo and Juliet… Keeping the datasets fun is part of what makes it fun for me.
If I am demonstrating how to perform some set of actions, I make sure to number the steps as well as the Figures (screenshots, etc) used. Then, I truly document every step along with the expected outcome of each. That takes time. And I am OK with that. When one considers how long a blog post will be “out there” after it is posted, taking the time to make it solid and clear is well worth it. It drives me nuts when documentation skips some steps in the middle of a process while assuming you just “know” to do them.
When screenshots are not appropriate to the topic, I make sure to find some fun pictures from Flickr to use. I make sure to choose images that are loosely related in some way to what I am writing about, but a bit entertaining as well. A picture of Devil’s Tower makes perfect sense in a post about ones experiences at a SQL Saturday in Chicago. And a 1960s era Ladies restroom sign is the ultimate homage to the Women in Technology Luncheon at the PASS Summit.

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…?>

The best advice I could give “past us” is the same advice I give people who tell me they want to blog but are apprehensive.

Don’t be afraid to blog because you feel you don’t know enough. If everyone waited until they knew everything before blogging or presenting, we would have ZERO bloggers and presenters. Blog now; learn while you do it.
Don’t be afraid to blog about topics that others have already covered. People learn in different ways. While the topic may be the same, YOUR way of explaining may be exactly what someone needs for that AHA moment that has been eluding them.
Don’t be afraid of making a factually incorrect statement and getting called out on it. Mistakes happen. Do your best to verify what you are writing (you will learn a lot during this activity) and you will be fine. If you think a particular statement is true, but are unsure, say so and indicate why. Be honest about what you are writing and people will respect that.

5. Finally, beyond the "how" questions, now the big one. There are no doubt tremendous pulls on your time. Why do you do write?

I have a few different answers to this one.

Before joining Digineer, I worked in general IT. Our department had a purple binder entitled, “Learned the Hard Way – or I don’t EVER want to have to figure this out again.” In that binder we placed really obscure problems we encountered along with their solutions. These were issues that happened so infrequently that remembering the details between occurrences was just not going to happen. Sometime I use my blog as my purple binder.

I went to college with the intention of becoming a high school English Teacher. I got as far as student-teaching in a local middle school and even substituted a few times. When I discovered Theater, I ended up putting my main focus into acting. Even so, I am still a teacher at heart and LOVE sharing knowledge with other people. Blogging and presenting are an extension of teaching, as far as I am concerned.

There is a poem commonly attributed to Ralph Waldo Emerson (although there is a bit of controversy about that) that really sums up why I do most things. I have loved this poem since high school and try to keep true to its meaning.

Success

To laugh often and much;
to win the respect of intelligent people
   and the affection of children;
to earn the appreciation of honest critics
   and endure the betrayal of false friends;
to appreciate beauty; to find the best in others;
to leave the world a bit better,
   whether by a healthy child,
   a garden patch
   or a redeemed social condition;
to know even one life has breathed easier
   because you have lived.
This is to have succeeded.

Blogging is one of the ways that I work toward achieving Success.

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

Wow, that was quite an interview, chocked full of good advice, and something most blogs about technical writing will not have…controversially attributed poetry. Some of my favorite bits include noting that blogging/writing is a great way to learn, and you don’t need to be perfect to start. I find that the research I do to try to avoid being wrong makes working hours on a seemingly simple topic often well worth it when I am working during the day (during the getting paid part of the day!). And you don’t have to be perfect, as long as you try to get it right, are somewhat interesting and provide something for readers to learn (and remember, there are many levels of readers out there). When you are wrong, a reader or two will tell you… I promise. (Thick skin is very helpful for public writing!)

So far, my biggest surprise has been that I haven’t gotten a particular answer to the time machine question. Stay tuned, someone soon is bound to answer what I have expected (and then I will add a supplementary entry to admit to the answers to the questions I would give myself!)

To the focus of the series, I now have three reasons why my first two interviewees write:

1. Because there are words that have to be written

2. Keep up with stuff I know

3. Working towards success

The second answer is definitely high on my list, but it certainly isn’t quite enough to keep me typing on this keyboard week in and week out in my free time (when minimally I could be building something with my Legos and preserving the springiness of the keys on my keyboard.) So the quest continues, with my next subject Rob Farley, who will hopefully get us one step closer to the answer to the question of why we write.

Why We Write #1 - An Interview With Thomas LaRock

drsql — Fri, 22 Mar 2013 00:03:00 GMT

I 've been a writer of trade level technical materials for over 13 years now, writing books, articles, blogs, and even tweets for a variety of outlets, almost exclusively about Microsoft SQL Server. While I won't claim to be the best writer in the world, I feel like I have the process of writing down fairly well, yet, for the life of me, there is still the question of "why do I do this?" stuck in the back of my mind that I have yet to appease.

Note that my quest specifically deals with non-verbal communication, because it seems to me that presentations are a completely different sort of "why" altogether.

So I have decided to survey as many of my technical writing colleagues and find out their answer to the "why" question. The only criteria for being included in this set is that you write about a subject like programming, gadgets, computer administration, etc.; and that you don't make your most of your living from writing (in other words, if you stopped writing today, tomorrow you would not be in fear of sleeping in the gutter.)

To get the process started, I have asked Thomas LaRock to be my first survey participant. Tom is a SQL Server MVP, has written a very popular book called DBA Survivor for Apress, frequently tweets as @sqlrockstar, and blogs at www.thomaslarock.com where he maintains a popular ranked list of SQL bloggers (of which I am listed in the tempdb category). He is a member of the executive committee of SQL PASS, and is very active in the SQL community as a speaker. He currently works for Confio as a Technical Evangelist. Tom is also quite well known in our SQL communitiy as a lover of the delightful cured porcine meat known as bacon.

If you want to see Tom in person, he will be doing a pre-conference seminar with Grant Fritchey and Dandy Weyn this year at Tech-Ed North America in early June in New Orleans entitled How to Be a Successful DBA in the Changing World of Cloud and On-Premise Data.

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

1. Every good superhero (or in your case, SQL Rockstar) has an origin story. What got you involved in writing?

Tom: The birth of my daughter. I wanted to record as many details as possible and since I had 10MB of available space for a website as part of my cable package (yeah...10 MEGABYTES BABY!) it was easy enough to get a website up quickly and easily. The writing came easily, too, since I was writing about something so close to my heart, something I remain passionate about to this day.

2. We all have influencers that have advanced our careers as writers. It may be a teacher who told you that you had great potential? 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?

Tom: I never try to be exactly like someone else. If I did then I would always be second best. Instead I've learned to take bits and pieces of different people and shape them into who I am today. The writer I admire most these days is Bill Simmons followed by Gregg Easterbrook. Both are known more for their sports writing but their style of writing is one that I try my best to emulate: it's human. I do not enjoy the dryness of technical writing, I prefer to write from my heart about things that I enjoy. That makes it less of a chore.

3. My writing process is pretty drawn out, often starting on my phone in OneNote, sometimes finishing in 10 minutes, but often taking a year (or years) to finish an idea. Can you describe the process you go through to write, from inception of an idea until it gets put out for consumption?

Tom: I used to start a draft inside of WordPress but lately I have been using EverNote to track my ideas and take notes. From there I just decide to go and get it done. I do my best to follow a very loose format: describe a problem, explain why it's an issue, help readers understand any and all tradeoff (cost, benefits, risks), and a few action items for them to use as a take away. Once I have that framework in my head it doesn't take long to get to a finished product. I think I may spend more time on finding a decent image to use with my post than the actual writing itself.

Tom: Write for yourself first. Feed your own soul. Don't worry about what your readers want. You can't write for others, they will never be happy with what you have done. The only person that needs to be happy with your words is you. When you write and share yourself then your readership will grow with people who are naturally drawn to you, and it makes it easier for you to keep sharing your words with people that want to hear them. And no, this advice wouldn't change. Ever.

5. Finally, beyond the "how" questions, now the big one. There are only 24 hours in a day, and there are no doubt tremendous pulls on your time from family, friends, and pork products, yet, even considering just your blog output, you obviously sit down at a keyboard very often to write. Why?

Tom: Most of the time I just feel that I have words that need to be written. Doing so helps to feed my soul. I'm at a keyboard a lot because my job requires it, and I am able to spend a lot of my day just writing as a way to communicate with others. Sometimes it's an email, sometimes it's a support ticket, other times it's a blog post.

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

I want to thank Tom for being my first participant in my experiment. I find his answer to the “why” question very similar to mine, in that he doesn’t so much offer a tangible reason, but more that he feels compelled to do so. I have to say that the question of how he got started is really quite unexpected, and very interesting, and is going to affect my future questions I ask because more than just the origin story, it will be interesting to see whether people started writing technically first, or for some other reason. I know that before I wrote my first book, I had never written 2 pages of material that wasn’t graded rather harshly by someone with PhD behind their name (or at least one of their low paid minions.)

Unfortunately (or fortunately if you enjoyed this first entry) Tom certainly did not resolve any of my questions to any level of satisfaction so I am going to have to continue to ask more of my technical writer colleagues for their opinion as well.

To that end, my next interviewee will be Mark Vaillancourt, whose website is http://markvsql.com/ and whom has a degree in English and Theatre (so he will know if it should have been whom or who earlier in this probably run on sentence), so that could make for quite an interesting interview. Perhaps he may resolve my curiosity about how one can go from the seemingly non-technical to spending his time working on SQL Server Business Intelligence. I don’t know but I look forward to finding out.

Geek City: A Grammar Geek in the Cloud

Kalen Delaney — Thu, 28 Feb 2013 06:25:00 GMT

Those of you who know me well know that I am usually a stickler for spelling, grammar and proper word usage. I may have even lost a few friends because of what some people see as obsession. I am not infallible, and I do make typos, but I like to try to correct them if possible as soon as I discover them (or as soon as they are brought to my attention.)

So now I will admit that I made a mistake in my usage of of the word ‘premise’, when talking about Cloud vs. non-Cloud databases. I was using the term on-premise as the opposite of ‘in the Cloud’, and my friend Cindy corrected me last week in no uncertain terms. So I went online and quickly found this post that proved she was right and I was wrong:

http://fbhalper.wordpress.com/2009/06/11/premise-vs-premises-in-the-cloud/

I did a bit more searching and found that I am not the only one making this mistake. A Research VP at Gartner actually makes the same mistake in a published post:

http://blogs.gartner.com/chris-wolf/2010/07/14/on-premise-microsoft-azure-an-inevitable-milestone-in-azure%e2%80%99s-evolution/

I will admit that I find the word ‘on-premises’ awkward to say, so when I’m talking casually I might end up leaving off the last syllable.

But anytime I’m writing, I promise to use premise vs. premises appropriately.

And I expect the same from everyone else.

~Kalen

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!

Pro SQL Server 2012 Practices Chapter 8: Release Management Review

drsql — Fri, 18 Jan 2013 21:06:14 GMT

This past year, I contributed a chapter to an anthology book of best practices for working with SQL Server 2012 entitled Pro SQL Server 2012 Practices (http://www.apress.com/9781430247708). As authors, for publicity we decided to do summary reviews one another's chapters. There are lots of great technical sounding chapters, but when I picked, I picked a chapter that I hoped to help me learn more about a process that is not in my favorite normal design or coding techniques area. Of the parts of the software development process I despise, release management is definitely one of them. As an architect, my primary love in software development starts with design, and starts to really drop off during testing. And I certainly did learn more about the process… TJay Belt (https://twitter.com/tjaybelt) wrote his chapter on release management. (I should also divulge that I have been friends with TJay through SQL PASS for quite some time, along with many of the authors of the book too.)

TJay does a great job of describing the process of release management, talking about the process he uses and even admitting mistakes he and his teams have made along the way as well. The focus of the chapter is very much from the point of view of the releasing DBA role in the process (most of the book is very DBA centric topics) and contains a lot of tremendously good advice about getting release management right starting with having great documentation and a rollback plan be able to restart or put a release on hold if things go awry. In addition, he covers many of the the topics around the entire process of coding/releasing software, including version control, proper (and quite reasonable) documentation, coding standards, and most of all a set of well-defined processes that all of the varied players in the process have agreed to and work on as a team.

My favorite part of the chapter was the approximately four pages of thought provoking questions that should be covered when doing a release, ranging from understanding the databases that will be affected, capacity planning, tuning, standards, code, jobs, etc. etc. Great food for thought for defining or refining your own release process.

Of course, one of the concerns of a book with lots of different topics is that you don't get tremendously deep coverage of any subject (and this is also true in my chapter on database design.) However, in some ways this liberates the writer from having to cover every detail and instead provide a thoughtful discussion of the overall release management process. This is very much a blessing, because every organization is different and already has some process in place already. Maybe your defined process is awesome or awful, but this chapter can help you think of ways to refine your process. You are left to find your own tools and processes to meet your company's needs, but what you get is quite thought provoking and will likely be useful whether this is your first time doing a release, or if it your hundredth.

The Year That Was - 2012

KKline — Mon, 31 Dec 2012 19:31:00 GMT

2012 was, simply stated, a year that kicked my butt. When I wasn't struggling professionally, I was struggling personally. Health issues, culminating in a diagnosis of Type II diabetes, and the passing of my father soon after Thanksgiving marked my biggest struggles. I apologize to those of you who are normally on my Christmas card list for not sending any this year. The wind was not in my sails. On the positive side of the ledger, I made a scary but exciting leap to SQL Sentry midyear. This was a huge shake-up after 10 years with my previous employer, but one which has been met with unbridled enthusiasm everywhere I've gone. Thank you for the handshakes, high-fives, and hugs! We're doing some really exciting things at SQL Sentry (such as SQLPerformance.com and Plan Explorer Pro) and I hope to engage with you more than ever in 2013.

Blogging Activity, Plus Leadership Skills & Professionalism

2012 marked a bit of a shift in my content creation direction. I've seen an uptick in struggles in the non-IT part of our career - communications, leadership, motivation, goal-keeping, all of those sort of things. I feel like I have some wisdom to contribute in that space. So, in addition to technical blog posts, I been putting down more of my experiences and lessons learned on the interpersonal side of the IT career path. My top ten blog posts for the year reflect some of that new direction:

Do You Have One of "the Three W’s" to Sit on a Board of Directors? -- Important tips for any IT pro considering a role in strategy and executive leadership.
Timewarp: What Is a Relational Database? -- With all the talk about NoSQL databases, let's go back to the fundamentals.
Want Another Reason to Hate iTunes? -- A throw-away article that precipitated a maelstrom of comments. Them Apple fanboys are passionate!
Why Do IT Pros Make Awful Managers? -- Not all IT pros make awful managers, but when they're awful it's often for similar reasons.
High-Availability White Papers and Resources for SQL Server -- Read the latest about AlwaysOn Availability Groups, and more.
New White Paper: SQL Server Extended Events and Notifications -- SQL Server 2012 great augments the Extended Events feature set. Find out how.
Build Your Own Microsoft Operations Management Pack -- Resources to build out your own SCOM management pack.
Help Me Update the History of SQL Server -- I started with SQL Server when it was still an OS/2 product. Jeesh! Lots of versions have come out since then.
TIE: Recorded Webcast Available: Extend SCOM to Optimize SQL Server Performance Management and The Expert's Conference (TEC) - For AD, SharePoint, Exchange, PowerShell and Other Admins -- Pointers to a webcast about extending SCOM and the TEC conference.
A Fond Farewell to Quest Software -- I learned so much in 10 years at Quest Software.

As I mentioned in the opening paragraph about blogging, I'm putting more energy into best practices for professional growth among IT pros. Along those lines of thought, I started a website called ForITPros.com with my long-time friend Joe Webb (Twitter | Blog) and, in partnership with SSWUG, developed a 2-DVD set and streaming media class called Leadership Skills for IT Professionals containing 14 hours of leadership and soft skills training specifically crafted for IT teams.

I've also been working with PASS on the Professional Development Virtual Chapter (VC), led by Mark Caldwell (Twitter). We've already got a full year of content schedule and are trying to figure out how fit in more sessions. Maybe moving to more than one webcast per month? The PASS Professional Development VC archive has lots of great content for you to review and future sessions are detailed at the PASS Professional Development VC homepage.

In-Person Activity

2012 was busy where I actually appeared in person or put in a big effort to write or create content. Here's a run-down: Articles (2), Conference Spoken (12), Customer Calls (88), Customer Visits (4), Magazine Columns (14) at SQLMag.com and DBTA.com, New Books (1) with Ross Mistry, PASS Chapter Presentations (12), Pre-cons/Full-day Seminars (4), SQL Saturdays (4), SSWUG Sessions (4), TechNet Radio Broadcasts (2), Technical Book Reviews (3), and Webcasts (10).

In 2013, I expect to travel a bit less. But I also expect to do many more webcasts. Let me know if you have some ideas about what you'd like to learn! One business trip that I refuse to give up, though, is SQLCruise. (Register!) I know it sounds like the worst possible way to learn. I mean who'd want to learn on a cruise ship in the Caribbean?!? (I hope you could detect the sarcasm dripping from those two sentences.) But here are two favorite aspects of of SQLCruise that are totally ferreals - 1) You simultaneously can relax and focus on learning. You are disconnected from the mainland. You don't have to worry about the mobile phone going off. 2) You get extended ours in a intimate setting with the top talent in the SQL Server world. It's always a pleasure to attend a conference session from the best in the industry. But you'll get hours of time to talk with these veterans of the industry about your specific problems and situations. It just doesn't get better than that.

Social Media

It's hard to believe that only a year ago, 2011, was my first year on Twitter. By years end, here's where my stats had moved: 5,507 tweets (up from 3,452 tweets), 661 following (up from 531), and 3,720 followers (up from 2,656) . I didn't check my social media numbers last year, so I've got no point of comparison. But I'm currently sitting at 2,327 LinkedIn connections and 1,157 Facebook friends. One of my standing policies on Facebook is that I don't "friend" someone who I haven't personally met. That doesn't help detangle the hopeless mess I've created by having only one identify on Facebook, both personal and public. So, on the one hand, I owe all of my longtime friends a big apology for all of the SQL talk and, on the other hand, a big apology to all of my professional friends for not posting enough news and advice while dilute my status updates with personal minutia. Oh well - it is what it is.

My blogging activity for 2012 was the lowest it's been in many years, down to 44 entries, down from 77 in 2011 and well into the hundreds in 2010. My answer to that sort of doldrums for 2013 is to get sloppy! And by that, I mean less of a perfectionist and more of a content machine that just cranks it out! Most of you, as my readers, have been very forgiving of a misplaced verb, a missing punctuation, or -heck- a totally malformed sentence that makes no sense at all. So I'm going to try much harder to churn through the 700+ nascent blog posts in my notes folder and get those ideas out there!

I hope to see you following me on Twitter soon! Thanks,

-Kevin

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 :)