Yearly Archives: 2017

How to write a successful conference proposal

As an organiser of a large programming conference and a speaker who’s pitched talk ideas to many conferences, I’ve been on both sides of the selection process. Last month I published a piece on writing a proposal for GopherCon. I wanted to revisit that post in the form of more general advice to give some insight into the why, not just the how, of writing a good conference proposal.

Presentations and proposals are different things

Your talk and the proposal to give that talk are different because they target different audiences. The former is what you are going to present on stage, the latter is a pitch to the reviewers to let you give that presentation.

Writing a good conference proposal is a different skill than writing the presentation itself. This article is aimed at writing a good proposal with a focus on the reviewer of your proposal as the audience.

Focus on the audience

Speaking of audiences, good public speakers start planning a presentation by identifying the audience they want to address. Presenting at a conference is like teaching a class, you have to present the material at the level of the people in the room.

It’s not just a question of beginner, advanced, or expert, you also have to consider the kinds of people at the conference. If it’s a vendor conference, there are probably going to be lots of managers, (pre) sales people, and business decision makers in the audience. While they might also be competent engineers, they’re at that conference wearing their business leader hat. They want to hear a different story; reliability, ease of maintenance, or evidence of widespread adoption, than an audience of software engineers who are more likely interested in things such as performance, orthogonality, and extensiblity.

So, if a proposal is for the conference reviewers, not the audience, should you pitch the presentation at the reviewers? Well no, but you should focus on what the reviewers want.
Your goal in writing a proposal is to convince the reviewers that, as well as thinking about your idea, and how to present it, you’ve considered the people who will come to see your talk.

Who are the reviewers and what do they want?

For smaller conferences it’ll be the organiser, or organisers, of the conference you’re applying too. For larger conferences it will likely be a group of reviewers who the organisers have invited to review proposals, this is the model that GopherCon follows. For really large conferences, such as OSCON, they will have a group of reviewers per track who funnel their recommendations up to a programme chair or set of program coordinators.

Regardless of their size, conference reviewers are charged with recommending to the organisers a set of talks they think are interesting and appropriate for the audience of the conference.

Most review panels are confidential, so you shouldn’t know anything about the individual reviewers, although you can probably guess that they will be experienced in the subject of your conference.

Most proposal are reviewed anonymously, at least in the initial rounds. This means the reviewers must judge your proposal, and your ability to present it, using only the fields provided on the submission form.

it’s important to remember that at least in part, all conferences are commercial enterprises. Venue owners have bills to pay just like the rest of us, and at a minimum speakers need to be compensated for their travel and lodging, otherwise the programme will be filled with people who are paid by their employer to speak.

To put it bluntly, reviewers are looking for talks that people will pay to see. This might sound capitalistic, but it turns out that this is what the audience want as well. At GopherCon we cover the travel and accommodation expenses of all our speakers. We think this is important because we want to hear what the speaker thinks, not their marketing department.

All of these are factors that reviewers will be considering when reading your proposal.

What to put in a proposal

Almost every conference call for proposals will ask for the following; title, abstract, and description. They may ask for other things like a biography, questions about AV requirements for your talk, and so on, but with respect to successful acceptance, these three items are key.

Title

A title is mandatory on almost every talk submission system I’ve seen. It’s your one line elevator pitch to entice the audience to come to your talk.

Keeping the title a little vague, or quixotic is popular, but I tend to stay away from 11 things that will make your proposal sound like a buzzfeed article. I’m not saying never do that, but if you do, you’d better pack a heck of a proposal behind your braggadocios

Abstract

Conference organisers usually ask you to provide a talk abstract as they often don’t feel it is appropriate to summarise your proposal for you. This abstract will be printed in the program or placed on the website so potential visitors to the event know what they’ll be seeing.

There are usually restrictions on the size of the abstract. One sentence that describes the topic that you’ll be talking about, and one sentence that describes what the audience will take away from listening to your talk or participating in your workshop, is all you need.

Together with the title, these are the two pieces of information the eventual conference audience will use to decide if they want to come to your session or not.

Talk description

This is where you sell your talk idea, and the place, as a reviewer, I have seen so many good proposals with interesting ideas fail to make the cut because they simply didn’t include enough detail.

This is where my advice differs from other’s you’ll read on the web. Many pieces of advice encourage you to write less in your description, sometimes out of recognition that the organisers are busy and you don’t wish to burden them. I wanted to take some time to explain why I push every speaker to write more detail.

You are looking to do three things when writing a description of your talk:

  1. Make it clear to the reviewers that you know what you are talking about.
  2. That you have a plan to communicate what you know to the audience and you’ve thought about how to do this within the time limit of the speaking slot.
  3. Answer all the selection criteria for the conference.

The first point is self explanatory, but you still need to make sure that you communicate this clearly to your reviewers. For example, if you’re talking about how to manage a large open source project, then make sure you mention that in the proposal, “as the maintainer of a large open source project”. If you plan to talk about a subject in the third person, then you should cite your sources, “for my PhD thesis I studied the day to day interactions of the top 10 projects on GitHub”. You don’t have to be an expert, but if your goal is to communicate something new to the audience, you should demonstrate that you know more about the topic than they do.

The second point relates to how likely you are to effectively communicate your ideas. The reviewers want to feel comfortable that you have a plan. It is all too common to see a proposal for an hour long session with only a sentence or two for the description. The less you write in a conference proposal, the more the reviewers are left to take it on faith that you’ll do a good job.

The opposite is also true. Occasionally I see a proposal for a talk that includes every possible aspect of a subject. Reviewers are generally wary that the speaker cannot cover all their material in the time available–few conferences can afford C++Con’s multi-part multi-hour format. A presenter that doesn’t manage their time, rambles without conclusion, or covers a lot of material in common knowledge is going to waste the audience’s time. That’s not just unfair to the audience, but unfair on the speakers that follow who must deal with a disgruntled audience.

One thing that I recommend to anyone considering submitting a proposal is to include an outline of your talk in the proposal. This can be literally the headings of your slides, or your ideas in bullet points. As a reviewer this makes it crystal clear that you’ve not only thought about your idea, but how to present it.

The last point, address all the selection criteria, I cannot emphasise enough. Review committees strive to be fair and often rate all proposal by a common standard. It crucial to address the selection criteria clearly as these are the ground rules by which every proposal are judged.

This point is probably the trickiest as not all conferences publish their selection criteria. Sometimes conferences ask for talks along a particular theme and these can be substituted for criteria in a pinch. If there are no criteria available–don’t guess, ask the organisers. If they don’t have any to share, which can happen with smaller conferences, then think about the audience and the wider ecosystem of the conference’s focus and ask yourself “if I were thinking about coming to this conference, what would I like to hear about?”

If you take away one thing from this section it is this–proposals with less detail loose out to proposals that provide more–as they do not provide the reviewer with sufficient evidence to be confident in their recommendations.

Don’t sell snow to Eskimos

Before closing I want to highlight a very common mistake I see in both conference proposals, and conference presentations, which is a speaker selling their audience on a thing the audience already likes.

To give an example, you wouldn’t go to the JVM Language Summit and give a presentation about how great the JVM is and they should use it. Instead, you’d go to the JVM language summit and show the audience the JVM is great by telling them about your project which was only possible because you chose to base it on the JVM.

Don’t take my word for it

Finally, if you’ve read this far, I encourage you to read what others have written on the topic, especially where their advice differs.

Karolina Szczur recently wrote a great article on writing conference proposals and includes many references to similar articles for further reading.

Conclusion

Reviewers are looking to put together the best conference they can. They want to see your talk on stage, but you have to give them the evidence they need to feel confident in recommending you. Show the reviewers you’ve thought about the audience, and you’ll make their decision a lot simpler.

I’m speaking at GopherChina and GopherCon Singapore

In April and May I’ll be speaking at GopherChina and GopherCon Singapore, respectively. This post is a teaser for the talks that were selected by the organisers. If you’re in the area, I hope you’ll come and hear me speak.

GopherChina

GopherChina is the third event in this conference series and this year will return to Shanghai. I was lucky to attend the event in 2016 and am looking forward to 2017.

The hidden of Go

Go isn’t like C. It doesn’t have a preprocessor, it doesn’t have macros, and it certainly doesn’t have #define, but Go does have pragmas.

What are pragmas? The name come from the #pragma declaration that tells C compilers to alter their interpretation of a piece of code. Now, Go doesn’t have a #pragma directive, but it does have ways of altering the operation of the Go compiler via directive syntax hidden in comments.

This talk will explore the history of these directives, how and why they are used, and how you can, but probably shouldn’t, use them in your own code.

GopherCon Singapore

GopherCon Singapore is the latest in the GopherCon franchise, and as flight times go, relatively close to home. I’m delighted to have the opportunity to present at their inaugural conference in May.

Concurrency made Easy

In my experience, many people who come to Go do so because they have a problem where being able to run more than one task at a time in their program would be beneficial. Ruby and Python programmers come to Go because the concurrency story is much better, the same is true of Node programmers; the event loop is still inherently single threaded.

But, most programmers who stick with Go for a while tend to look back on their early efforts and say things like “wow, I really went overboard with channels” or “I went crazy with goroutines when I started writing Go. It was impossible to understand what the program did”. For people who learn Go formally from an instructor or a book, the concurrency section is always the last section they cover.

So there is a dichotomy here. Go’s headline feature is simple, lightweight concurrency. As a product the language sells itself on that feature alone. On the other hand, there is a narrative that concurrency isn’t actually that easy to use, otherwise people wouldn’t make it the last things in their books or classes, or perhaps more accurately, concurrency is not the solution to every problem.

With this as a background, I’d like to explore some strategies for using concurrency in Go without the pitfalls of convoluted code, the importance of memory ownership, and the best way to structure a Go program using goroutines.

Context is for cancelation

In my previous post I suggested that the best way to break the compile time coupling between the logger and the loggee was passing in a logger interface when constructing each major type in your program. The suggestion has been floated several times that logging is context specific, so maybe a logger can be passed around via a context.Context. I think this suggestion is flawed (as are most uses of context.Value, but that’s another story). This post explains why.

context.Value() is goroutine thread local storage

Using context.Context to pass a logger into a function is a poor design pattern. In effect context.Context is being used as a conduit to arbitrarily extend the API of any method that takes a context.Context value. It’s like Python’s **kwargs, or whatever the name is for that Ruby pattern of always passing a hash. Using context.Context in this way avoids an API break by smuggling data in the unstructured bag of values attached to the context. It’s thread local storage in a cheap suit.

It’s not just that values are boxed into an interface{} inside context.WithValue that I object to. The far more serious concern is there is no schema to this data, so there is no way for a method that takes a context to ensure that it contains the specific key required to complete the operation. context.Value returns nil if the key is not found, which means any code doing the naïve

log := ctx.Value("logger").(log.Logger)
log.Warn("something you'll ignore later")

will blow up if the "logger" key is not present.

Sure, you can check that the assertion succeeded, but I feel pretty confident that if this pattern were to become popular then people would eschew the two arg form of type assertion and just expect that the key always returned a valid logger. This would be especially true as logging in error paths is rarely tested, so you’ll hit this when you need it the most.

In my opinion passing loggers inside context.Context would be the worst solution to the problem of decoupling loggers from implementations. We’d have gone from an explicit compile time dependency to an implicit run time dependency, one that could not be enforced by the compiler.

To quote @freeformz

Loggers should be injected into dependencies. Full stop.

It’s verbose, but it’s the only way to achieve decoupled design.

The package level logger anti pattern

This post is a spin-off from various conversations around improving (I’m trying not to say standardising, otherwise I’ll have to link to XKCD) the way logging is performed in Go projects.

Consider this familiar pattern for establishing a package level log variable.

package foo

import “mylogger”

var log = mylogger.GetLogger(“github.com/project/foo”)

What’s wrong with this pattern?

The first problem with declaring a package level log variable is the tight coupling between package foo and package mylogger. Package foo now depends directly on package mylogger at compile time.

The second problem is the tight coupling between package foo and package mylogger is transitive. Any package that consumes package foo is itself dependant on mylogger at compile time.

This leads to a third problem, Go projects composed of packages using multiple logging libraries, or fiefdoms of projects who can only consume packages that use their particular logging library.

Avoid source level coupling

The solution to this anti pattern is to delay the binding between the type that does the logging, and the type that needs to log, until it is needed. That is, until the variable is declared.

package foo

import "github.com/pkg/log"

type T struct {
        logger log.Logger
        // other fields
}

Now, the consumer of  type T supplies a value of type log.Logger when constructing new T‘s, and the methods on T use the logger they were provided when they want to log.

Interfaces to the rescue

The eagle eyed reader will note that the previous selection removed the package level log variable, but the coupling between package foo and package log remains.

However, this can be remedied by the consumer of the logger type declaring its own interface for the behaviour it expects.

package foo

type logger interface {
        Printf(string, ...interface{})
}

type T struct {
        logger
        // other fields
}

As long as the type assigned to foo.T.logger implements foo.logger the decision for which specific type to use can be deferred until run time in the same way that io.Copy escapes any knowledge of the io.Reader and io.Writer implementations in use until it is invoked.

It’s not just logging

Logging is a cross cutting concern, but the anti patterns associated with it also apply to other common areas like metrics, telemetry, and auditing.

Get involved

The Go 1.9 development window is opening next month. If this topic is important to you, get involved.