So, my conference talk proposal got declined. Is that such a big deal to dedicate an entire post to it? I mean conference organizers receive all kinds of talk proposals - many more submissions than the lineup of speakers they have to fill. So, unless you are a superstar in any given community (which, clearly, I am not), there is a serious non-zero chance that you will get a “No,” which probably has nothing to do with the topic you are going to present, or how knowledgeable you are in it.
The first rejection didn’t really register with me. So, I did not get accepted, whatever. Let’s try again. I spiced up the proposal a little and submitted it for another conference. And it got declined again. Fine, the third time will be it. But it wasn’t.Â
I’m trying to make sense of what I can do better next time. I’m not entirely sure if there’s something wrong with the proposal itself or the Go community is generally not interested in such topics. Like Dave Cheney said once, you have to “consider your audience“:
The audience have already invested time and money in flying to to visit the conference – they already think Go is pretty great. Instead, you want to inspire the audience to convince other people that Go is great, and do that by presenting information that is relevant to Go programmers today.
This is the part where I am starting to think that the topic may simply not be relevant to the Go community at large. I wasn’t able to get much feedback from the selecting jury on any event, but I think this is the criteria they may have used. I didn’t intend to address the people sent by the employees to learn how to incorporate Go better in their workplace.Â
The Proposal #
I am leaving the final judgment to you. I will post the proposal the way I submitted it, and hopefully, I will get some feedback from you, the readers, on how to make it better next time.
Title #
Go for the rest of us: building robust web applications while staying small and moving fast.
Elevator Pitch #
How do you bootstrap web products in Go fast without a large team or infrastructure? Is it worthwhile, given Rails, Django, or Laravel? What can we learn and apply from them? My talk will explain how we approach rapid web development without compromising on the robustness and simplicity of Go.
Description #
Go has come a long way since its early days as Google’s “better C.” It didn’t take long for it to show the world that it’s a solid pick for just about any application, whether we’re talking cloud software for huge companies or a pet project by a lone coder. While the language quickly found its unique advantage in developing software for the cloud and large enterprises, it is just as viable an option for individuals or small teams setting their next software-as-a-service solution to the market.
In a landscape dominated by heavyweights like Ruby on Rails, Django, or Laravel - each celebrated for their flexibility, rapid development capabilities, and thriving ecosystems - it might seem audacious to choose Go. Yet, in mid-2021, my team and I did exactly that for our next product. And we are still happy with our decision.
Discussion around Go’s potential as a choice for individuals or small teams looking to build products is somewhat lacking within the community. Not all software solutions need to hinge on microservices, use exotic data storage options, or operate on complex, self-healing infrastructure. At times, the simplicity of shipping a binary and testing your idea in the real world is all that you need. The challenge I intend to explore in my talk is the untapped potential of Go, particularly in the context of small-scale, fast-moving development.
Have something to say? Join the discussion below 👇
Want to explore instead? Fly with the time capsule 🛸
You may also find these interesting
Interfaces Are Not Meant for That
It’s time to ask ourselves how much abstraction in our Go code really makes sense.
Python is Easy. Go is Simple. Simple != Easy.
Python and Go have distinct qualities that can complement each other.
Focus on the Happy Path With Step Functions
A simple pattern that will help you reduce error handling, while keeping your Go code simple and idiomatic.