The PASS Summit is like the World Cup of the SQL Server community, only with less head injuries and more of a chance of you getting up onstage.
Every year, people just like you submit sessions, and believe it or not, some of them get accepted. You get free entry to the conference, a seriously cool entry on your resume, and an itchy polyester shirt that fits horribly, but you’re gonna wear it anyway because you’ll be so doggone proud of your achievement.
Let’s do this. I want to help – and seriously, everybody up on stage wants to help you get up there, too. Go read my 2010 post Rock Stars, Normal People, and You.
Yeah. All that is still true.
Here’s how the schedule works.
The Call for Speakers will be open February 28-March 21, so here’s what our timeline needs to look like – and yes, dear reader, I’m gonna be doing this in public this year too:
- Feb 12-18: Pick 1-3 pains you’ve relieved. Look back at your project folders, meeting schedules, and really big email chains from the last year. Think about a few problems you had at work. They’re not gonna seem hard to you now, but that’s why you’re the perfect person to present them. On Sunday night, February 18th, you owe me the 1-3 pains you relieved.
- Feb 19-25: Write a recap slide. For each pain, write a recap slide with 5-6 bullet points. These are the things you want the attendee to walk out of the session understanding.
- Feb 26-March 4: Write the purely technical body of the abstract. It’s tempting to start with the title and the humorous theme, but set that aside for a second. Given what you want to teach for the recap slide, who’s the target audience? What do they already know? Think just about the bones of the session. The catchy theme will come later, but it’s gonna have good bones first.
- March 5-11: Gather feedback. The single toughest part of the Summit abstract submission process is that you get no second chances. This means you absolutely have to get feedback from other people before you hit the submit button. Post your session as an abstract at GroupBy – you don’t actually have to present it if you don’t want to – just use it as a framework to let other people leave comments and questions. Then, ask your own questions about the abstract.
- March 12-18: Write the title and then, then submit. By now, you’ve got a really good feel for the technical part of the abstract and you can start to add some humor or a catchy title. You’ll even have several good (and not-so-good) ideas for those from other community members and speakers. Do a final cleanup pass. You’ll submit it and skid in sideways just before the deadline.
It might sound counterintuitive, but there’s a lot you don’t have to think about before your presentation is actually accepted, like whether you’ll use handouts or slides, whether you need demos, or how you’re gonna rehearse. We’ll cover those later.
I’m doing it too. Here’s my first week’s homework.
I’m going to be doing this process too. I wanna set an example, and that means I need to turn in my homework one week early so you can see how I’m doing it.
Our homework for this week is to pick a few pains we’ve relieved. Looking back at 2017, here’s the stuff I’m most interested in sharing:
- How often should you take backups and run CHECKDB – I know, you probably think that sounds really dumb, but here’s the deal: I regularly interview “senior” DBA candidates who give really, really, spectacularly bad answers to that question.
- What to do when SQL Server is unusually slow – consistently a top request from training class students & clients. I have a checklist where I work through sp_WhoIsActive, sp_BlitzFirst, sp_BlitzCache, etc, showing how to interpret the results. I’ve been honing this session for a couple of years, but I need a new abstract for it.
- Analyzing parallelism – this sounds incredibly un-sexy, but clients & training students often get fuzzy looks when the concepts of CXPACKET, Cost Threshold for Parallelism, MAXDOP, CXCONSUMER, etc. It’s made more challenging by the fact that most monitoring & troubleshooting tools don’t show you which queries are currently hamstrung by this stuff, or give you good numbers for settings. I don’t have a good session to tell this story yet, either.
- Demystifying cardinality estimates – quite the range of levels here, right? When I’m working with folks on query tuning problems, they often point at a part of the query plan and go, “Why the hell is it estimating 1.30753816 rows?!?” In 75 minutes, I can’t explain how the whole query plan is built from scratch, but I bet I could give people a good roadmap that picks up where How to Think Like the Engine stops.
So there’s my first round of homework. Whew.
Let’s get started and get you an itchy, ill-fitting presenter’s shirt.