Behind the Scenes: Ruby By the Bay Civic Hack

Reading Time: 8 minutes

I don’t write much Ruby in my day job. I also don’t go camping. And until recently, I had never laid eyes on San Francisco.

This past weekend, all of that changed.

I headed out to the west coast to participate in Ruby By the Bay, a three day civic hack that started a few years ago in Washington, D.C., and occurred this spring in Golden Gate National Recreation Area just north of the Golden Gate bridge.

I have written about hanging out with other programmers in the woods before. I’ve also written about hackathons. So this time I’ll focus on the details of a civic hack.

In a civic hack, participants help out with one of a few social good projects.

I helped lead a team for Refuge Restrooms, an app that collects and displays information about the locations of restrooms that are safe for trans and non-binary folks.

We spent Friday evening meeting one another, determining which attendees would work on which of the four projects, and installing dependencies. Computers slowed to a crawl as 40 people downloaded Ruby, docker, et cetera over a single internet connection. Folks sat around and chatted over tea and chocolate, adjudicated which team members would pick up which work streams, then played board games until far too late at night.

On Saturday and Sunday, we worked on our projects from 9 AM until 5 PM, with a break for lunch. We got Monday morning to put some finishing touches on our work, then presented our finished products to the rest of the group after lunch.

If someone were to ask me for some insights about participating in a civic hack like Ruby By the Bay, here’s what I would say:

 1.  Halve your scope at the beginning.

Programmers are notoriously bad at estimating how long things will take. In the case of a civic hack, you have a few days to ship something. Make sure you ship something.

This could mean reducing the scope of your technical goals for the event to something that gives you more room than you think you need to finish. Going into this event, the Refuge Restrooms team considered adding an API endpoint for users to bulk upload restroom locations, another endpoint to bulk download restroom locations, and drafting some marketing materials so third-party clients might use those two endpoints.

On the first evening, Mikena Wood (the Refuge Restrooms stakeholder) explained that the people asking for this functionality were mostly college campus administrators and other folks without technical expertise. So we elected, instead of an API endpoint, to build a UI flow for bulk upload. We also decided not to do bulk download or marketing materials. Instead, we’d focus on implementing the bulk upload flow from user authentication and approval, to a background job for location geocoding, to adding the new restrooms to the map.

 2.  Get the whole team on the same page.

Our feature featured a single end-to-end flow with a number of components: A UI for bulk upload, another UI for authentication, a flow for admin approval, a background job to process bulk upload CSVs, geocoding, s3 integration to store the files, and so on. Because our flow involved so many integrations between one step of the process and the next one, we had a fairly high risk of a miscommunication breaking the flow.

With leadership from Betsy Haibel, we embarked on a role-playing scenario to get everyone on the same page. The team acted out the different components of the app, communicating with one another the way that these components would. The exercise created clarity about how each interface needed to work so that team members could start tackling components. Caleb Harris and Lisa Vogt took the lead on a bulk upload job, Morgan Fogarty and Betsy started driving out the bulk upload user interface, Kai Middleton and myself took on authentication, and Mikena backed up all of our efforts with deployment support.

Throughout the work, our team deliberately employed some continuous communication strategies. At any time, spectators would find up to half our team mob programming on a large projector screen. Most of our individual pieces depended on one another, so we went for a trunk-based integration strategy: merging quickly into the main development branch. As we pushed updates, we’d announce our pushes to the team so folks whose components depended on our work would know that they were ready. On the second day, one member of each pair also rotated, so the integration steps benefitted both from a developer with context on each feature plus a developer with context on a different feature.

When all the steps were in place, Mikena performed a manual end-to-end test on the projector screen, with all of us watching and adjusting our pieces. The end-to-end test had just a few minor snags, and we got it working seamlessly for our demo on Monday.

 3. Take regular breaks.

Many of the folks at Ruby By the Bay took time before breakfast each morning to enjoy the scenic hills and beaches. But breaks during programming are also important. Mikena insisted that we all go walking in the hills together on Sunday afternoon. At the time, many folks on the team had been struggling with thorny technical issues of one kind or another for several hours. Folks were personable, but they weren’t at their most personable. We left the building, and Kai led us up a trail he had found onto one of the paths with a view of the ocean.

The walk turned out to be just the break we needed. For about 40 minutes, we forgot about the code and the deadline and spent time taking pictures of flowers, petting hikers’ dogs, and marveling at the views. We noticed the top of the Golden Gate Bridge peeking over one of the hillsides, emphasizing just how close to San Francisco we really were.


When we came back inside, several people simultaneously had new ideas for how to fix their code. As Mikena described it, “If we had stayed inside, those fixes would have taken the full time it took us to go on the walk, plus some.”

For those of us who program professionally, we get to ship code all the time. To do so in a setting like this one is unique, and it’s important to take time to enjoy it.

Also, a civic hack presents a unique opportunity to meet other folks who want to spend time learning, teaching, and writing code, for free, for good causes. Those people represent a subset of the tech community, and we don’t get to be surrounded by them all the time. So it’s valuable to chat with them. They’re interesting, kind, and eager to connect with others who care about their impact, too.

This admonition sounds touchy-feely, but it has career and industry implications. First, let’s talk about you: these people might join you as your next coworker. They might hire you into your next job. They might be your next mentor/mentee, or your next sponsor/protege (both topics we’ve talked about in the Leveling Up series).

Second, this is bigger than you. The ubiquity of software in our daily lives brings up ethical questions about how workers are treated, how products are used, and how companies protect our data. Companies exist to make money. They only care about how they treat their workers, build their products, and protect data if the units of the moneymaking care about those things. And we only have power, as the units of the moneymaking, if we act collectively to force companies to care. That’s easier when we know each other.


I love civic hacks—they’re the only type of hackathon in which I participate anymore. If you like the idea of getting thrown into a temporary team to help out a social good project, I highly recommend it.

And when you do, I recommend a couple of strategic choices:

  • Choose a small scope for your work. Err on the side of too small.
  • Coordinate constantly with the rest of the team, so that integrations go smoothly.
  • Take regular breaks. Enjoy the experience and spend time getting to know your fellow civic hackers.

If you liked this post, you might also like:

Seniority means saying no (this post is most popular among programmers who are into forcing companies to care)

Hiring for Fit (also popular among programmers who care, and who also work for companies who care)

Anger and Sadness in the Workplace (this one is about feelings! I know, gross.)

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.