SQLSaturday #162 : Cambridge, England

AaronBertrand — Sun, 09 Sep 2012 21:08:00 GMT

Yesterday I presented at SQL Saturday #162. My slide deck and samples are here:

Slide Deck & Samples: Bertrand - T-SQL Bad Habits & Best Practices

I also wanted to answer a question from an audience member after the session about how to generate YYYYMMDD strings to represent yesterday's date in order to append to a backup file name. In this case because we're probably not worried about performance (you're performing this calculation once), we can just use string conversion (see this blog post for a more detailed discussion about doing things like stripping time from datetime at high volume).

-- In SQL Server 2005, 2008 or 2008 R2, you can say:

SELECT [filename] = 'Backup' + CONVERT(CHAR(8), DATEADD(DAY, -1, GETDATE()), 112);

-- In SQL Server 2012, you can use a slightly more self-documenting method:

SELECT [filename] = 'Backup' + FORMAT(DATEADD(DAY, -1, GETDATE()), 'yyyyMMdd');

I was really impressed with how this event was run - it was super organized and I had a great time, so kudos to Mark and Lorraine Broadbent and everyone else who helped by speaking, volunteering and sponsoring.

Today I was able to take a walk around "The Backs" (the walkways along the river behind all the famous colleges here), then went to Castle Mound with Buck Woody & family, then Scott and I took a train to Ely to see the 4th largest cathedral in Europe. A good day. Pictures here:

Cambridge | Ely

How SQL Saturday could be better

AaronBertrand — Tue, 15 May 2012 12:58:00 GMT

I've been to a lot of SQL Saturdays. They are great events to attend - from a community standpoint, from a learning standpoint, and from a speaker growth standpoint. Who could ask for more, right? Great sessions, from passionate speakers willing to both teach and learn, fantastic networking opportunities and lunch. All for free, or at a very low cost - some events need to recover costs and charge $10 for lunch. Still a phenomenal bargain IMHO.

But we all know that these events aren't perfect... there are sometimes failures in process or communication that lead to frustration for attendees, speakers, organizers and volunteers. And most of these failures occur during the period leading up to the event, not on the actual Saturday.

So I have just a few minor suggestions that might help.

Speakers: don't overwhelm the organizers.

I know some of you think you have 10-15 sessions that you could deliver equally well, but all you're doing is making their job harder, and I don't think it benefits anyone. I find it hard to believe that the quality of all 15 would be similar, regardless of how experienced a speaker you may be. Pick your top three or four, and cap your submissions there. If you can't narrow it down because you think all 15 of your sessions are completely awesome, check the list of existing submissions, or contact the organizers to find out the areas where they need more coverage (they are listening at SQLSaturdayN@sqlsaturday.com, where N is the SQL Saturday number, e.g. SQLSaturday146@sqlsaturday.com). If it's too early in the submission process, then either wait, or be sure to cull your list closer to (but before) the submission deadline. I'm not in favor of the latter, though, because if you submit 15 sessions but only want to seriously consider 3 or 4, you may have prevented other speakers from submitting their session on a topic too similar to one you didn't intend to present in the first place.

Speakers: don't double book.

While you might like to have a back-up plan, this almost guarantees that you'll have to cancel on one of the events. Since you don't know which event will finalize their list of speakers first, I don't think it's fair to invite two or three girls to the prom, and end up going with the prettiest one who says yes. I suggest you pick the event you're most likely going to be able to attend, and leave your second- and third-place choices for the next time they have an event. Or pick the one with the earliest submission deadline, so that if you don't get selected, you will still have time to submit to your second choice. As above, if you wait instead of submitting five minutes after an event is announced, you can get a good sense of how many sessions and what topics and speakers you're up against (these aren't kept secret, on purpose).

Speakers: cancel promptly.

Even if you don't follow the above two suggestions, have the courtesy to cancel the minute you learn or decide that you won't be able to make the event. The longer the organizers are fooled into believing you're going to make it, the harder it's going to be for them to fill your slot(s). This goes for cancelling your regular attendee registration as well: since you are automatically registered when you submit to speak, if you're not going to be there, you're potentially preventing someone else from attending. I've heard of several cases where speakers cancelled the day of the event, or shortly before, or didn't bother letting the event know at all. Having attendees show up to an empty room with no speaker just downright sucks for everyone. I realize that some cancellations are unavoidable, and I'm not suggesting you should skip a funeral to honor your speaking commitment - but as soon as you know, let them know.

Organizers: don't delay notifications.

Speaker selection should happen as close to the submission deadline as possible. I know of at least one event where speakers changed their travel plans to be sure they would be in a certain city on a Saturday, only to find out much later that they weren't being selected to speak. Letting them know earlier will allow them to change their plans appropriately, whether that means staying home, attending a different SQL Saturday, or maybe even just spending one less night in the hotel because they won't need to be there Friday night for the speaker dinner. Now again, I realize that sometimes you can't control how early all of your speakers will want to book their travel, or exactly when you can get together with the other volunteers to make the final selections. But as much as possible this should be part of the planning process when picking the submission deadline in the first place. I think the selection should have to occur at least one month prior to the event, and in a lot of cases two months would be ideal. This would allow remote speakers that are chosen to book flights and hotel without paying last-minute premiums, and for speakers that are not chosen to make alternate plans.

Organizers: have a healthy balance of local and remote speakers.

Obviously you want to have top-notch speakers for your audience, but at the same time, you want to help groom local talent and propel them in the community (one of the founding goals of SQL Saturday). I don't think there's a way to apply a blanket rule or percentage for this, as different locations have different pools of local talent, but organizers should have some familiarity with their local speaker pool and should be able to ensure that an appropriate mix is selected. In some cases this may mean that you have to decline a better remote speaker, and I'm not suggesting in any way that this job is easy (or that you should always pick lesser experienced speakers with bad abstracts just because they're local), but I think there could be some better effort here.

PASS: minimize the number of events on a single day.

I realize it's impossible to give every event their own dedicated Saturday, but keep in mind that in addition to encouraging double booking by some speakers, and precluding others from attending one city in favor of another, you're also spreading sponsor dollars thin and making it less likely for a sponsor to step up to the level that gets a table and allows them to send a representative or two. If a SQL Saturday doesn't succeed here, the organizers and volunteers might be a little gun-shy about trying next time, and everybody loses. As with a couple of other suggestions here, it is difficult to set a hard and fast rule here - one proposal I heard was to allow only one SQL Saturday within a 350 mile radius, but geography alone is more of an issue for the local speakers and less of an issue for remote speakers and sponsors.

[Edit: In other words, I'm not convinced that a hard-coded mile radius rule, be it 350 or 400 or however many miles, is valid. 350 miles in Massachusetts or D.C. is very different from 350 miles in New Mexico or Montana. I also don't even dream of considering imposing a "no two events shall happen on the same Saturday" rule - even though I tried to make that clear above, it seems my suggestion is still being misinterpreted. I am not trying to indicate that there is some perfect rule that everyone is overlooking. I'm just suggesting that we shouldn't want to see another 5-event SQL Saturday, and should do whatever we can to prevent it from happening.]

PASS: put some policies in writing.

While some of these suggestions could be enforced through code on the SQL Saturday site, I realize that you can't just wave your hands, snap your fingers, and have the code in place. But in the meantime I don't think this should be a barrier to formalizing policies that could eliminate some of these problems. I think most are common courtesy / common sense items that don't need to be technically enforced, but posting some of these policies on the specific event site (or on the main SQL Saturday site) should be enough to help the community police this behavior. If you state, for example, that there is a cap of four sessions per speaker, there is no excuse for speakers to submit more than four, even if the site would still allow them to do so. This can also place some onus on the individual organizers to respond to those speakers and tell them to whittle down their list, or you'll remove all of them. It's a little tougher for organizers to discover that a speaker has submitted to other events as well, but I think both of these examples are things the speaker should be more responsible for anyway. You don't always have to actively *prevent* a behavior to curb it - sometimes people just need to be told how to do something right rather than get slapped every time they do it wrong.

Once again, I will stress that these are not perfect or even directly implementable answers, and I don't have any illusions that these will make SQL Saturday perfect. But I do believe they are areas that have caused some frustration in the past and that deserve further consideration - the sooner, the better.

Search results matching tags 'volunteering' and 'SQL Saturday'

SQLSaturday #162 : Cambridge, England

How SQL Saturday could be better