I’m relatively new to this whole programming thing but the other week I was invited to attend my first ever Rails Conference (thanks, Shopify, thanks, team!). Since starting at Shopify I’d heard wonderful things about the Ruby community so when the invitation came my way I eagerly accepted and flew to Philadelphia.

This being my first technology conference I wasn’t sure what to expect. Technical deep-dives? Free stickers? Hackathons? What I found was all that, and much more! It turns out this wasn’t just my first Rails Conference; it was the last Rails Conference ever. But, as Shan Cureton, Executive Director of Ruby Central, reminded us:

"RailsConf 2025 may be the last RailsConf in name, but don't let that fool you - this is not the end. This is the pivot point."

One of my knowledge gaps that filled during the conference was the purpose of jobs in Rails applications. I had written jobs code before, such as to clean up stale database records, but I wasn’t clear on why and when to use them. And why did Shopify use its own job management tool instead of something from Rails’ defaults? My understanding of Rails jobs felt incomplete.

The answer came after attending a session: The Past, Present and Future of Background Jobs according to Mike, Rosa, Maciej, and Ben. It was a panel discussion featuring the authors of popular Rails Job management tools: Sidekiq, SolidQueue, Karafka and Goodjob.

It turns out that Rails needs jobs because when we receive a request we want to respond as soon as possible. We want our controller to focus on returning a view quickly, not get bogged down with job-related work. Hence, we use jobs to defer work and in a separate process handle jobs through a queue, performing them in the background. We use jobs to process work that is not necessary to complete the request and this ensures users aren’t waiting for background tasks (such as cleaning up stale database records) to complete before they can continue through their user experience. Various job management tools exist because developers hold differing opinions with differing use-cases. These different requirements influence implementations, such as if the tool should manage jobs via threads or processes and whether the queue should use a relational or in-memory store, for example.

Pretty cool stuff! Beyond this technical insight, one among many, I also left the conference with a valuable lesson in sharing your goals publicly.

Let’s jump to Thursday afternoon, the end of the conference. We’d all just enjoyed Aaron Patterson’s fifteenth and final RailsConf Keynote. He recapped every keynote he’d given over the years and I thought to myself “wow, Aaron’s given fifteen Keynotes. If he can give fifteen of them, then I, Mikey Gough, should be able to give a technical talk someday too”.

Afterwards, I was hanging back at the Shopify booth with my team, buzzing with inspiration. I told them how utterly inspired I was feeling. Inspired to build fun stuff. Inspired to contribute to open source. Inspired to share what I’ve built. I half-joked: if Aaron can give a talk about signal processing his cat’s poop data, then surely I can come up with something too!

Luckily for me, I work at a place that encourages dreaming big. And my colleagues, most of whom have given conference talks, started hyping me up. Adriana walked me through the Call for Papers (CFP) process. Jenny told me how to generate a presentation idea. Hartley shared the story of how he once wrote and submitted his proposal 15 minutes before the submission deadline (he mistook the submission deadline timezone).

Someone chimed in “Well, the submission deadline has passed for RailsWorld, but I think you can still submit for SF Ruby. The deadline’s this Sunday”.

“Interesting… though maybe next year seems more realistic” I replied.

I tucked away this idea, we packed up the booth then headed out for team karaoke…

… The following day I’m at the airport - exhausted but inspired. I boarded the plane and fell asleep.

When I woke up, the person next to me was programming. I watched him code for a few minutes.

Could it be Ruby? Could he be hacking on Rails? We both ordered coffee from the flight attendant and I finally asked:

“Sorry to peep, but what are you working on?”

He explained in that patient and friendly way only a Rubyist could. I nodded along but didn’t follow completely (I’m new to this, remember?). He’s understanding and kind. Answered all my questions.

Then the gears start turning as I shake off my sleep. He’d given a talk at RailsConf about making the front-end of Rails more omakase. I must have missed that one so he ran me through it.

It sounded interesting, I liked the idea. We chatted about front-endy stuff. I mentioned that some of the new CSS features were pretty amazing. Wouldn’t it be neat if rails new shipped with a stylesheet using some of the new CSS features - like variables (properties), a basic reset, native light and dark mode support, etc.?

Then I dreamily mentioned that someday I’d love to give a conference talk.

“You should do it!” he exclaimed. “Write a talk about this! The SF Ruby submission deadline is THIS Sunday. Submit it!”.

He was right. Holy shit - he was right.

I spent my layover poking around the Rails source code. There was a --css tailwind flag you could add to rails new. Maybe I could leverage that pattern? On the next flight I drafted a proposal. The following day I polished it up and hit submit.

The other week, I heard back: my talk for SF Ruby is waitlisted. Not quite an acceptance, but I’m an optimist and this is a huge step forward! Even if I don’t take the stage, I’ve learned more than I could have imagined.

That, I think, is the real magic of conferences. And of sharing your goals publicly! You never know who might encourage you, who’s been in your shoes, or how far a single conversation can carry you. Pronouncing your goals, whether personal or professional, can get you a bit closer to achieving them. And as all programmers know, ever bit counts! 😂