Are you interested in speaking at the Professional Association for SQL Server’s annual Summit conference? The call for speakers is now open, and you may submit up to three sessions between now and March 31, 2019.
I’m currently in the process of sketching out my ideas for what sessions that I’d like to submit, and I thought I’d share my process here.
Generating ideas: what am I interested in spending six months thinking about?
I’m a bit selfish when it comes to topic selection, and I think that’s fine: it needs to be something that I’m interested in thinking about for more than half a year.
That does NOT mean that it needs to be super-advanced rocket science content. Figuring out how to present introductory level content clearly, in an easy-to-understand way takes a lot of time. The topic simply needs to compelling enough for me to stay interested.
A filter: is the topic relevant to enough people?
When I first began speaking, I thought I needed to speak on topics that were unique to me, which other people in the community didn’t already “have covered.” This led me to somewhat esoteric concepts. There’s a big downside to that: your talks simply won’t be relevant to many people.
Now, I encourage myself (and you) to use the opposite filter: think about talks that will be be helpful to a lot of people. That means you probably won’t be the first one in the world to deliver a talk on the topic, and that’s perfectly fine: your perspective is valuable!
There is definitely a “three bears” aspect to this filter. Your talk doesn’t need to be useful to everyone at the event. But do think about your intended audience, and whether you’ll help a significant portion of the audience at the event.
Sketching out ideas and audiences
For this year’s PASS Summit talks, I currently have two topics I’m quite passionate about, which I’d love to share.
Right now I don’t have abstracts. I’ve started by creating notes on:
- Subject matter area / rough title
- What the talk would include – a problem summary (which I write as quickly as possible, just throwing out ideas) and a bulleted list of content ideas
- Who would care (audience) and why they would care
Here’s where I’m at with my two topics.
Topic 1: Source Controlling Index Code in a Changing World
Alternate title: I prefer, “How to Standardize Index Code in a Changing World.” Not everyone may get that Standardize = Source Control, however — not sure if that’s simply how I think of it.
Problem summary: It’s critical to get database code standardized into source control to manage collaboration, store and version your organization’s intellectual property, and to track and audit what has happened in your database code. The database code for indexes, however, is increasingly difficult to standardize: new features in Azure SQL DB automate the process of tuning index schema. Single-tenant database architectures often standardize table schemas, but require customizations of indexes for performance in individual databases. And index schema often needs to “drift” in production as operations teams respond to critical performance problems. How do you adapt successfully to this chaos, yet still maintain your sanity by managing your database code in source control?
Topics to include:
- Differences in source controlling indexes with state vs migrations approaches to database code
- Strategies for working around limitations on advanced index features with a state approach
- How to manage drift that occurs with automatic indexing in Azure SQL Database
- How to manage incidents where indexes are manually changed/drifted in production due to a critical need without going through a full release cycle
- How to manage single-tenant environments where the indexes are customized in individual databases
Audience / who would care:
- Developers and DBAs who have their databases in source control, but who struggle with “drift” in some areas
- Developers and DBAs interested in getting databases into source control — sometimes thinking ahead about these more advanced issues at the beginning can help you learn fast
- Architects thinking about using single-tenant designs
Topic 2: Best Practices for Branching Database Code in Git
Problem summary: There are quite a few discussions and patterns available online for branching application code, but special considerations apply when it comes to database code — and hardly anyone has written about this! This talk helps DBAs and developers design the simplest branching strategy that meets the needs of their organization. I will share key considerations for designing a branching strategy for database code, and we will discuss multiple popular branching models along with “fit notes” describing the strengths and weaknesses of each model.
Topics to include:
- The overarching rule of “keep it simple”, but why this leads to different practices for small teams (1-2 devs checking in code) vs larger teams
- State-first vs migrations-first and explain what that means for branching – a migrations approach that doesn’t include a state component will SUCK for merging … maybe don’t use the word SUCK in all caps in the final abstract tho
- Why shared vs dedicated development databases is important when considering branching – why object locking is a necessarily evil of a shared model, so don’t do shared if you can avoid it (esp considering that Dev Edition is free for SQL Server, side-eye at Oracle)
- What feature branches are and how to tell if you need them
- What release branches are and how to tell if you need them
- Pull requests
- Rebasing
- Branching diagrams for multiple popular models, and “fit notes” for the teams using them
Audience / who would care:
- Me!!! Hahahaha, I find this topic fascinating, even if there were five people in the room I’d be thrilled (but I do think this would be quite popular with dev-minded folks, I don’t think it’s just me)
- Developers and DBAs who want to get database code into source control
- Developers and DBAs who have code in source control, and who struggle with:
- Managing concurrent changes to objects
- Building the codebase from scratch to a specific release / version
- Managing drift in different environments / comparing database versions to source versions
Next steps: mulling these over
I feel pretty good about these topics so far: I think that I care enough about them to want to spend a good amount of time with them, and I think that enough people at the conference care about the problems discussed to make them worthwhile.
These two talks are a bit more focused than talks I’ve done in the past, in that they’re specific to managing code in source control. I’m strongly of the opinion that everyone should be managing their database code in source control, though, so I’m fine with the level of focus — source control should be the norm!
I am presently waiting a few days before writing and revising “real” abstracts. I’ve got some time before the deadline, and I find it’s good that I sit with a topic for a few days to see if a bright new idea occurs to me, or to see if I may want to go in a different direction.
First time speaker? Go ahead and submit!
Writing an abstract and choosing a title for a talk can be daunting. I personally find it easier to start with making notes about a potential talk like I’ve shown here, and then refining those notes. I am hoping that helps some potential speakers out there to get started.
Here’s that link to the call of speakers again — submit by March 31, 2019.