You know that feeling when you want to submit a conference talk but stare at the blank CFP form for an hour?

“Scala Magic: Beyond the Basics” - too vague, delete. “Functional Programming Unleashed” - cliché, delete. “Type-Level Wizardry in Scala” - too niche… maybe?

I spent three weeks crafting my Scala Days CFP. Not because I’m slow (okay, partially), but because writing a conference proposal that balances technical depth, accessibility, and storytelling is genuinely hard.

This post shows you my complete process - the rejected titles, the abstract iterations, the technical depth dilemma, and the logistics I had to consider. You’ll see my actual drafts, what worked, and what bombed.

If you’re thinking about submitting your first CFP (or improving your acceptance rate), this is for you.

Why this matters

Here’s the reality of conference CFPs:

Most get rejected. Not because they’re bad, but because they’re unclear, too technical, or don’t hook the selection committee in the first 30 seconds.

I’ve submitted probably 15+ CFPs over the years. Some got accepted, many didn’t. The difference? How you frame the problem, not just the solution.

What conference organizers look for:

• Clear value proposition (what will attendees learn?)
• Right technical depth for the audience
• Engaging storytelling (not just bullet points)
• Practical takeaways (not just theory)
• Speaker credibility (can you deliver this?)

What kills a CFP:

• Vague titles (“Advanced Scala Techniques”)
• Abstract that reads like academic paper
• Too much or too little technical detail
• No clear audience targeting
• Walls of text with no hooks

This post walks through my Scala Days CFP from initial idea to acceptance, so you can avoid the mistakes I made.

Part 1 - Finding the idea (and why 90% of titles suck)

Every talk starts with a seed - a tiny idea that refuses to let go. For me, it was the desire to share something genuinely useful and fresh about Scala, something that would resonate with both newcomers and seasoned pros.

Here were my rejected titles:

• “Scala Magic: Beyond the Basics” — Too vague. What’s “magic”? What are the “basics”?
• “Functional Programming Unleashed” — Cliché alert. Also, what does “unleashed” even mean?
• “Type-Level Wizardry in Scala” — Intriguing, but too niche. Scares away intermediate developers.

The problem? Each title either promised too much or targeted too narrowly.

What worked: I needed a title that:

1. Promised specific value (“unlock hidden powers”)
2. Targeted a clear audience (developers who know Scala but want depth)
3. Avoided buzzwords (“unleashed”, “magic”, “wizardry”)

Eventually, I settled on something that balanced curiosity and clarity. More on that later.

Part 2 - The acceptance email (and what it took to get there)

📎 Download the PDF

Part 3 - Crafting the abstract (and why my first draft sucked)

Crafting the abstract felt like solving a puzzle. How do you convey technical depth without scaring off non-experts? How do you tease the audience without giving everything away?

Here’s my first draft:

“Dive deep into Scala’s type system and explore how advanced type-level programming can unlock new paradigms in software design.”

Sounds impressive, right? But it’s terrible for a CFP. Here’s why:

• “Dive deep” - vague promise, no specifics
• “Unlock new paradigms” - buzzword salad
• No hook - why should anyone care?
• No outcome - what will attendees actually learn?

I needed to add storytelling hooks and concrete outcomes.

The fix: I added these elements:

1. Personal pain point: “Ever felt constrained by your type system?”
2. Promise of transformation: “By the end, you’ll wield Scala’s type-level features like a pro”
3. Specific techniques: “Practical type-level programming techniques”
4. Pitfalls to avoid: “Common mistakes and how to fix them”

Part 4 - The technical depth dilemma

Scala’s power lies in its type system, implicits, and powerful abstractions. But here’s the catch: not everyone is ready for heavy type-level wizardry.

I debated including code snippets in the abstract — a bold move, but potentially off-putting.

1
2
3

trait Functor[F[_]] {
  def map[A, B](fa: F[A])(f: A => B): F[B]
}

Would this intrigue or intimidate? I chose to hint at code without overwhelming. Show the power, not the complexity.

Part 5 - Logistics nobody talks about (but should)

Let’s be real - travel budgets and time commitments matter. I had to consider:

• Is this talk worth the trip? (Flight to Europe ain’t cheap)
• Can I deliver in 45 minutes? (No sprawling tutorials)
• Remote backup plan? (COVID taught us things)

This influenced my scope: No sprawling tutorials, just focused, punchy content.

I scoped the talk to be:

• Self-contained (works without prerequisites)
• Time-boxed (fits 45 min with Q&A)
• Demo-friendly (code examples, not theory dumps)

Part 6 - The final abstract (and what I learned)

After multiple revisions, late-night coffee sessions, and questioning my life choices, the final abstract read:

Unlock the hidden powers of Scala’s type system. This talk guides you through practical type-level programming techniques that elevate your codebase’s robustness and expressiveness. Expect hands-on examples, pitfalls to avoid, and a fresh perspective on functional programming.

I hit submit. Heart pounding. Fingers crossed.

Why this version worked:

• ✅ Clear promise (“unlock hidden powers”)
• ✅ Specific techniques (“type-level programming”)
• ✅ Practical focus (“hands-on examples, pitfalls”)
• ✅ Target audience (developers wanting depth)
• ✅ No buzzwords, just value

Lessons learned

What worked:

• Iterate ruthlessly - my first draft was garbage
• Balance depth with accessibility - show expertise without intimidation
• Use storytelling hooks - “Ever felt constrained?” beats “This talk covers…”
• Mind logistics - scope affects feasibility
• Be authentic - passion beats polish

What I’d do differently next time:

• Start earlier (3 weeks is tight)
• Get feedback from 2-3 people before submitting
• Include a brief speaker bio highlighting relevant experience
• Add more specific outcomes (“You’ll learn X, Y, Z”)

Your turn

Crafting a CFP is hard. But it’s your chance to share your unique perspective with the community.

Ready to submit yours? Here’s my checklist:

• Clear, specific title (avoid buzzwords)
• Hook in first sentence
• Concrete outcomes (“You’ll learn…”)
• Right technical depth for audience
• Logistics considered (time, travel, scope)
• Passion visible in the writing

The stage is waiting. Go build something.

TL;DR

• The challenge: Crafting a Scala Days CFP that balances technical depth, accessibility, and storytelling
• Rejected titles: “Scala Magic” (too vague), “FP Unleashed” (cliché), “Type-Level Wizardry” (too niche)
• First draft mistake: “Dive deep into paradigms” - buzzword salad with no hook or concrete outcomes
• The fix: Added personal pain point, specific techniques, pitfalls to avoid, transformation promise
• Technical depth dilemma: Show code examples but don’t intimidate - hint at power, not complexity
• Logistics matter: Travel budget, 45-minute constraint, remote backup → focused talk scope
• Final abstract: Clear promise + specific techniques + practical focus + no buzzwords = acceptance
• Key lessons: Iterate ruthlessly, use storytelling hooks, balance depth with accessibility, mind logistics
• Success formula: Title (specific value) + Hook (pain point) + Outcome (what they’ll learn) + Scope (manageable)
• Next time improvements: Start earlier, get feedback, add speaker bio, more specific outcomes
• Your checklist: Clear title, hook, concrete outcomes, right depth, logistics, visible passion