Submissions for CppCon 2020
CppCon is organized by the C++ community for the community and so we invite the community to present.
Given the current situation regarding COVID-19, we feel it is best to be totally transparent with our planning process. We are closely monitoring the news regarding restrictions on travel and large gatherings. It takes about 9-12 months of conference planning and given that we do not know the situation in September, we are moving forward with the hope that it will be safe to see you all in Aurora.
As always, a submission is not a commitment. If you need to withdraw your submission at any time, we’ll understand.
Who Should Submit?
You. If you have something interesting to share with the C++ community about C++ then please consider presenting. Our goal is to create the best program that we can and we feel that there must be room for both seasoned presenters and new voices.
All submitted topics should be about making attendees better C++ programmers. Submissions such as Java for C++ Programmers are off-topic. (A submission such as What C++ Programmers Can Learn from Swift could be considered.) Submissions unrelated to C++ such, time or stress management are also off-topic.
We are open to any topic that will make attendees better C++ programmers. Below are some ideas.
- C++ libraries and frameworks of general interest
- ISO standardization proposals
- Concepts and generic programming
- Functional programming
- High performance computing
- Software development tools, techniques, and processes for C++
- Practical experiences using C++ in real-world applications
- Sessions for one of our dedicated tracks:
- Industry-specific perspectives: mobile systems, game development, high performance trading, scientific programming, robotics, etc.
CppCon attendees tend to be software engineers with many years of experience from a wide diversity of industries. Talks targeted to beginning C++ programmers are unlikely to be well attended, but talks aimed at experienced C++ programers that are beginners in a particular area (for example, functional, game, or embedded programming, or introducing a new library or language feature), can be compelling.
Platform specific talks may be accepted, especially if they present general concepts and techniques that are not limited to one platform or tool. The number of people who could use the subject of your talk is part of our review decision. Broad appeal is better than narrow appeal, but deep appeal is our real goal. The abstract should make it clear why this is a C++ talk.
Standard presentation sessions are sixty minutes long (including Q&A). We can accommodate half hour sessions and multi-session submissions. Note that multi-session submissions may be harder to accommodate. Please indicate your flexibility.
We will also have Lightning Talks, but they need not be submitted in advance. We will share more information about Lightning Talks and other opportunities for Open Content in time for you to plan your participation.
Accepted half and full session speakers will have their conference registration fee waived (one speaker per session). If you are planning to submit a proposal, please do not register for the conference at this time. You’ll be contacted with special registration instructions later.
Further financial assistance is available to accepted speakers. Please indicate, when making your submission, if you require financial assistance. Details are provided on request of the Speaker Liaison.
Submission Title and Abstract
The success of your submission and even the success of CppCon as a conference depends on the quality of your title and abstract. A compelling title and abstract will result in your submission being accepted by the Program Committee, increased attendance at the conference, and increased attendance at your session.
Writing good titles and abstracts is an art, but here are some guidelines likely to make your submission more compelling.
- Focus on the subject and the lede–the first two sentences of your abstract.
- A reader should be able to read just the title and the first two sentences of the abstract, no more, and know “what” the topic is and “who/why” should be interested in attending the talk.
- Everything else in the abstract should (just) elaborate with details on those things, not add new main points.
- Help us highlight the broad uses of C++. We want people looking at our program to think, “Wow, C++ sure is used in a lot of different applications in a lot of different industries.” If your session is based on experience from or application in embedded, robotics, games, finance, science, etc. or a large, successful, “hot,” or otherwise well-know company then consider that as part or your title.
- If worded properly your session can be compelling to those in the same field and also to those that want to apply the lessons learned in your field to their problems.
Less Great: “constexpr performance tips” Much Better: “Using constexpr for performance in low-latency Google search engine code” Less Great: “Cross-platform C++ development using Visual Studio” Much Better: “Cross-platform C++ development targeting Android, iOS, Windows, Xamarin, Linux and IoT” (possibly adding “using VS”)
- Consider a flavor of “How you can X by learning / embracing / using / understanding Y” rather than “Some thoughts on Y.” Emphasizing the practical value of attending your talk is what turns a website visitor into a conference/session attendee.
- Attendees come to CppCon to learn new ways to use C++ effectively. Therefore, all CppCon talks should focus on showing attendees how to use C++ well. As a litmus test, the take-away of every talk should be a list of “here’s what you can/should do in C++.”
- Example: A talk that shows a technique from another language and then focuses on how to accomplish that in C++ is fine. A talk about “<other language> for C++ programmers” that is primarily teaching about another language is not, because it doesn’t focus on using C++ effectively.
- Example: A talk that complains, even bitterly, about how hard something is in C++ (and there are hard things! and some issues may even take some time to explain) and then focuses on “here’s what you do instead” guidance is fine. A talk that is mostly a rant about how difficult something is but that has little focus on practical solutions that do work is not, because it doesn’t focus on using C++ effectively.
- Avoid jargon and insider terms.
- A single unknown acronym or term may cause attendees to think “this talk is not for me.”
- It is fine to use such terms if you define them or make their meaning clear in context. You may even have such a term in your title, as long as you explain it in your abstract. “Applications of Hobb’s Algorithm in Low-Latency Libraries” is fine as long as the abstract lets us know something about Hobb’s algorithm and why it has special value (or challenges) in low-latency applications.
- You may also refer to something in a way that makes it clear that you will explain it so attendees don’t need to worry if they aren’t already familiar with the concept: “We will also cover Lippincott functions and other techniques for exception handling.”
- Humor/cleverness is okay.
- It is certainly not required and it is better to not attempt it than to fail at it.
- People are attending because they want information, not entertainment, but no one wants to be bored. Having a title/abstract that is catchy/funny/clever is a signal that your presentation won’t be dry.
- The litmus test is that what you write should work on both levels. It should make sense even if the reader doesn’t get the joke. Otherwise it is maybe off-putting or alienating.
- A professional technical conference, like CppCon, is not the place for humor that is “adult” in nature or targets any group. Better to risk boredom than to risk offense.
- Focus on the subject and the lede–the first two sentences of your abstract.
If you are a first-time submitter or just want some comments on your title and/or abstract, we invite you to send an email to our submission advice address. Please include your name in the subject line and include your session title, abstract, and any specific questions in the body. We’ve recruited a set of volunteers that will share ideas and comments on your submission before you submit it. Asking for this advice is optional, and the volunteers do not speak for the conference or the Program Committee, but may give you comments from a valuable perspective. (If you wish to use this option, do not wait. As the deadline approaches, response times on this service will lengthen.) If you’d like to volunteer to join the mailing list to share your ideas and comments, please contact the organizers to volunteer. Your own titles and abstracts will benefit from the experience.
Comments from Attendees
We’ve surveyed attendees on every presentation ever given at CppCon and the single most common issue raised is that presenters speak too fast and try to cover too much material.
The primary cause of the issues that attendee surveys have identified is that presenters under-estimate how long it will take to cover material. When you practice your talk in front of your cat, you’ll cover a lot of material quickly because your cat understands everything right away. Practice in front of a real audience–at work and/or your local user group. You’ll understand from the looks on their faces and the questions they ask how fast (or slow) you can go. You’ll begin to get a feel for how much material you can cover in sixty minutes.
A common mistake made by technical presenters is to give audiences insufficient time to read code-heavy slides. (This is a programming conference. There can and should be lots of code.) You understand the code very well: you wrote the slide and have practiced it many time, so you know that the important part of the code is right there, on lines six and seven. Your eyes naturally go to this part of the code and understand its meaning quickly because you already know the context. But eyes that haven’t seen this slide before need more time to absorb the code. We are programmers and we know that the devil is in the details. We want to read it all. (If it doesn’t need to be read, why is it on the slide?)
There are a few approaches you can take for code-heavy slides. One is just to pause when a one comes up. The programmers in your audience won’t need to be told to start reading the code. Another approach is to talk the audience through all the code before focusing on the important part. (This might help you trim out code that doesn’t need to be on the slide.)
One handy technique is to highlight the important part of the code so it stands out and, when showing how code is being changed from slide to slide, dim or gray out the code that is unchanged from the previous slide. (This is one of several reason why syntax coloring, while great for IDEs, is not great for slideware. Syntax coloring tends to clash with attempts to dim or highlight code.)
You’ve researched your topic and you have a lot to say, but stay focused. Your goal should be to have no more material than you can comfortably cover in one hour without questions. If you find that you are speaking quickly to accomplish this, think about where you can trim.
Resist the urge to cover more. The difference between a session that covers less material very well and a session that hurries through material that the audience does not have time to fully appreciate, is the difference between a memorable session and a forgettable one.
Submissions should be made on our session submission page. After making a submission, you’ll receive an acknowledgement from the EasyChair system. All submissions will go through a peer review process.
Presenters are encouraged, but not required, to submit slides and source code for distribution to attendees and to agree to have their sessions recorded. Presenters must agree to grant a non-exclusive perpetual license to publish submitted and/or recorded materials, either electronically or in print, in any media related to CppCon. Note that CppCon videos are sponsored and may be published with the sponsor’s logo.
This year we are using a mentoring system to match experienced speakers with less experienced speakers. Your participation is voluntary and will not in any way impact the selection process (the Program Committee will not know that you’ve opted into the program). For additional information on this program, contact the Speaker Liaison.
If you have any questions about the submission process, please contact the Program Committee.
Submission deadline: 5 June 2020
Decision notifications by: 13 July 2020
Program available online: 3 Aug 2020
For a chronological view of all the key conference dates, refer to the CppCon Timeline.