-
-
Save calonso/17b5dcc48071a55538c9 to your computer and use it in GitHub Desktop.
Presentation Title: Case Study: Troubleshooting Production Issues as a Developer. | |
Presentation Abstract: Step by step walkthrough of a developer troubleshooting a real performance issue we had at MyDrive. From the very first steps diagnosing the symptoms, through looking at metric charts down to CQL queries, the Ruby CQL driver, and Ruby code profiling. |
I agree with @adamclup here.
The abstract is a big vague, and that keeps it from being compelling. All of us have had a performance issue or two in production, and there are lots of talks covering that. Why should i listen to this talk? What are you going to teach me/show me? What am I going to walk away with that I didn't have before?
Is this a talk about how you solved a problem, or about how I can solve my next one? How specific is it to the tools that you mention? Who would benefit from seeing this talk?
Something I don't include in my abstracts but which I always create before creating an abstract is a list of learning outcomes? Who should come to this talk, and what will I give them if they do? I think this will help you to flesh out your abstract and also focus on a more descriptive title.
Title is not as descriptive as it could be.
Need to build a little more story but keep it short, highlight the problem, hook the reader on why they should listen to this talk, and clearly define what they will leave the talk with. While this abstract does a bit of this, it isn't compelling.