My thoughts on session levels
Almost every conference I go to, either as speaker or as an attendee, indicates the level of sessions. Sometimes this is done with a description (beginner / intermediate / advanced), more often with a number (typically 100 – 200 – 300 – 400 – 500, though I have seen other scales as well).
This is obviously a good thing to do. If you are just new in the field, attending a highly advanced session would be a waste of time. And if you have many years of experience then you will probably not learn much from a beginner-level session.
But there are some issues with these level indicators. I do not pretend that I have the answers – in fact, I am sure I don’t. But I do wish to share my thoughts.
As mentioned above, session levels are typically represented with either a description or with a number. Descriptions are typically given as “beginner / intermediate / advanced”. While that sounds pretty clear, there is still a lot of room for interpretation. When exactly does one make the transition from beginner to intermediate, and from intermediate to advanced? Some people think the beginner tag only applies for a few months, others use it for a few years. Some people will never label themselves as advanced, no matter how much experience they have.
The numerical labels are even worse. I hear people utter phrases as “that is level 300 session”, but what exactly is “level 300”? PASS has made an attempt to clarify this here, with a one-word description, an indication of experience, and a short explanation. Here are the levels with their description and experience indication (follow the link above to read the longer explanations):
- 100 = novice, up to 1 year
- 200 = intermediate, 1 – 3 years
- 300 = advanced, 4 – 6 years
- 400 = expert, 6+ years
- 500 = advanced level, 8+ years
The combination of the number and the explanation makes this actually better than the single-word description some other conferences use. But unfortunately, it is limited to just the PASS Summit. Other conferences use other definitions for the same 3-digit numbers. I have seen conferences where level 100 is defined as “management-level overview, please do not use this level for technical content”. I have seen conferences that use level 400 as the highest level.
In other words, in most cases the three-digit level indicator is even worse than the one-word descriptions.
It’s all relative
Another problem is that experience is not measured in just years. There is a huge difference between having five years of experience in a single job at a single department of the same company, doing the same thing over and over; or having five years of experience in various roles within the same or different companies. There can also be a significant difference between two persons in the exact same job if one of them is so eager to learn more that she spends lots of her free time at conferences, reading blogs, or playing with new feature on her own laptop and the other one closes off at five and spends his spare time doing things not related to his job at all. Plus we are all different, even when doing the exact same thing for the exact same time, one person learns quicker than the other.
That’s why the amount of experience that PASS (and probably other events as well) lists for each level should be taken as a guideline, not as a strict rule. Some people with only 4 years of experience will still be comfortable in a level 400 session. Others may have 9 years of experience but struggle to keep up in that same session.
Speaker and attendee may well have a different interpretation of what does and doesn’t count as experience. Let’s look at a level 200 session on log shipping. According to PASS, this assumes 1 – 3 years of experience. But experience with what? Do you start counting when you first touched a database? When you started your first job as SQL Server DBA? Or when you first started using the specific technology covered (log shipping in this case).
Perhaps the speaker has created a session that targets people who have never used log shipping but are interested in the feature. But they didn’t want to spend valuable session time on explaining how full recovery works and what log backups are, so they set the level of the session at 200, thinking “attendees with 1 – 3 years of experience as a DBA will know what log backups are and how to schedule them; I can use that as my starting point and build on that to show log shipping”
And perhaps an attendee with 7 years DBA experience sees that session and thinks “hmmm, my company could benefit from this technique but I have never used this, I actually need a level 100 session on log shipping because I have no experience at all in that field”.
Content vs delivery
Perhaps my biggest gripe with session levels though is that it is unclear whether the level describes the content of the session, or the delivery. I like to believe that this is not a very important distinction at the more beginner-oriented levels. But at advanced levels it does make quite a difference.
For example, last year at SQL Saturday Holland I delivered a session titled “Hash Match, the Operator”. That session not only covers what the Hash Match operator does and how it works, but it also goes into undocumented details such as how exactly the hash table is built, how the memory grant is computed, and all the phases of a hash spill situation. You may think that this description of Hash Match is deep, but that session is even deeper. So I have no doubt at all as to the content of this session: it is definitely level 500.
But how about the delivery? In other words, what did I assume my audience already knew, what did I expect them not to know, and in what way did I try to convey that knowledge? If I had purely targeted a 500 level audience, I should have assumed 8+ years of relevant experience. So that means that I did not have to explain what Hash Match does, what a hash function and a hash table are, or how a Left Anti Semi Join differs from a Right Outer Join. And I could have kept my explanations fast and high-paced, describing complex pointer structures within the hash table architecture with just a few words.
I chose different. I expected my audience to be aware what Hash Match does, but not necessarily already know what a hash function and a hash table are. I expected them to know what pointers are but still provided visual representations of a hash table to help them better understand the architecture. I chose to take a very advanced and very complex (and very specialized) topic, yet explain it in a way that I think that most of the 300-level audience should be able to follow.
Some people were probably happy with this choice. They might have struggled if I had skipped the first part of the session. Other people were probably unhappy, they might have felt that if I had not wasted so much time on explaining the basics, or on visualizing things they would understand from a quick remark, I would have been able to cover more than I did now. There is no way to please everyone.
But even more important in the context of this post: there is no way in just a single level indication to clarify which part of the audience I aim to please the most.
A single keyword- or number-based indication of session level is a good way to give the audience a quick indication of what to expect. But it is not more than just a quick indication and it has many shortcomings.
Speakers should get into the habit of giving a clear, longer explanation of what level of content the audience can expect, and what level of expertise they expect the audience to already have. Conference organizers should make sure that the forms where speakers submit an abstract allow for enough characters for the speakers to add this information. Conference organizers should also ensure that this information is easily accessible to their audience. And conference attendees then need to look beyond just the title, presenter and level indication of a session, but also check the full abstract (that then hopefully includes the information they need to check whether or not they are the intended audience).
(EDIT: Fixed three typos – thanks Kalen for pointing them out to me!)