Planning an Internal Elixir Hackathon
I’ll cover the following topics, feel free to jump around to the bits that speak to you:
- Background
- Initial Proposal
- Prep Work
- Day-of
- What I Learned
In late 2017, I found myself in a position to look for a new job, which meant asking myself what I wanted. Did I want to keep pushing down the Python route? Maybe go back to Ruby? I had been playing around with React and thought it was pretty amazing, but I’ve always been more of a back end kind of person.
I ended up focusing on Ruby because I felt I had a strong grasp on it and generally liked working in it. About two weeks into the job search, I had a ping from a recruiter asking if I would be interested in a job that was using Elixir. At first I thought, “No way, I’m wanting to get back into Ruby and don’t need to get side tracked. Besides, I tried Go, and it was ok, but not my jam.”
Fast-forward about two more weeks and I’m trying to do some of my interview take-home questions in Elixir in an attempt to force myself to learn it. Functional programming? Heck yes. Immutable data? Be still my beating heart. Parallel processing and async I/O? It was like falling in love all over again. There was just one tiny hiccup: I accepted a job at Chime where the back end is all Ruby on Rails.
Luckily I had already talked about Elixir in my interview, and the overall engineering vibe at Chime is one of “if it makes sense and we can present a business case for it, let’s try it!” Before I could really push any kind of Elixir-based project, I needed to get people excited and interested in learning a new language and framework.
Making the Initial Proposal
At past jobs, I’ve participated in learning groups when a adopting a new technology or framework. These can work well, but one large problem is that the “extra” work of learning usually gets offloaded to non-work hours. If Chime was going to be serious about trying out this new tech, I wanted us to put valuable work hours toward learning Elixir.
I wrote up a quick one-page document to lay out the goals and budget requirements to set up a one-day off-site Elixir focused hackathon. I noted that the off-site part, while not necessary, was high priority for me. Pulling engineers out of the day-to-day would allow for a more focused space for learning and building. I can also now admit that getting the CTO to OK some budget for a breather room was also a bit of a litmus test on how seriously we were considering Elixir. I made sure to find a range of options for the breather to fit different budgets. If you will have more than 6 people, I would definitely suggest finding a space that has at least two physical rooms so that groups can collaborate without interfering with each other.
For the hackathon to be successful, I wanted other engineers to see where functional programming could be powerful. They should walk away from the day with a sense of accomplishment for having pushed out production-capable code. This meant that picking projects that would benefit from the underlying differences of Elixir was crucial to the hackathon’s success.
It took all of about 10 minutes for the CTO and VP of Eng to say “very yes” to the hackathon idea. I was pretty stoked, but now I also had to deliver on my ambitious plan.
Hackathon Prep Work
I really wanted to focus on getting as much learning done as possible. I identified the following as the enablers of that:
- Focus only on Elixir and Phoenix work.
- Remove as many setup issues as possible.
- Pick the right projects.
I encouraged people to do as much prep work as they could in the weeks leading up to the event. This included everything from “here’s some good learning resources to pick up the syntax”, to “here’s a dockerized project that you can start playing with”. The goal was to remove as much of the language basics learning time as possible.
For the hackathon itself, I took each of the potential projects and set up repos a week ahead of time with all the necessary set up to hit the ground running. Each project had a working docker-compose environment and a README with instructions on how to get the project running locally. Having this ready early also helped reduce setup time during the hackathon.
Picking the right projects was the hardest task. The scope had to be small enough that people could work on it and make progress in one day, and it had to be something that would leverage the power of Elixir. There’s no secret recipe here. I had never run something like this before, and I am far from an expert in Elixir and Phoenix. For our next hackathon, I’ll have a better idea of what our team can accomplish in one day, and which internal projects would benefit from the tech.
The three projects I ended up going with:
- a GraphQL server
- a background script processor job
- common logging and stats tracking for Phoenix projects
Why GraphQL? Outside of wanting to experiment with it for our apps, we also see it as more of an aggregation framework for our transition to SOA. Since GraphQL allows us to define reducers, we can farm out pieces of a query to multiple back end services and aggregate the results without forcing the front end app to hit multiple services. We can leverage the async I/O strengths of Elixir - in this case for any of the downstream services that take a while to respond (a common experience when dealing with moving money).
The last piece of the puzzle was matching people with shared project interest and Elixir skill levels. We’d work in pairs, each pair having one developer with more Elixir experience. This would help facilitate more knowledge sharing and learning.
Day of Learnings
With the Hackathon day upon us, we settled into the Breather we rented near the office. I gave a quick overview of the projects along with the first few steps that I thought people should tackle (I put these into GitHub issues, but we ended up not really using them since... GitHub issues).
The rest of the day was split into three, two-hour focused working sessions:
- First kick off the projects
- Lunch break
- Second focus sesssion
- Show and Tell
- Final session to wrap things up
The two hour cadence seemed about right. More can get taxing when you’re learning something new, and less can prevent you from finishing anything.
One of my initial goals was to produce a production-ready piece of software in Elixir that we could deploy, or at least get to a deployable state with minimal follow-up effort. Turns out that was a lot more ambitious than I thought, and that ended up being my biggest frustration with the entire event. While we made some great progress on the projects, we did not have enough dev ops infrastructure in place to run any Elixir projects in any of our environments. We also didn’t get to a good deployable state for any of the three projects. Between initial language learning, and overall project context, everything I picked was far too ambitious to finish in one day.
In spite of those results, the day went well. The GraphQL service pulled a separate service in, validating that it could work as a proxy. Our background script jumped over the initial hurdles and had the inklings of some impressive performance improvements. We even have a Plug that we can use to do stats tracking for request durations in Phoenix projects.
Post-Event Learnings
I set up a quick type form feedback survey for people to fill out after the event to see what went well or didn’t go well. The interesting learnings:
- Having a space with two rooms was great, but the lack of monitors and more collaborative work stations wasn’t great.
- Being explicit about ensuring all participants get work time to prep would help reduce frustrations (mostly around me feeling like the time wasn’t used to its maximum potential).
- Taking time away from the normal office was a big win.
- Sharing what people accomplished and learned half way through was really helpful for everyone.
- Finding the right project(s) is hard and you might not nail it.
I wanted to spark interest in Elixir and highlight what we could do with it. I think I definitely sparked interest, but fell short on really highlighting where Elixir and Ruby differ. Luckily, there’s enough interest that we’re continuing to have mini-hackathons to build on the work we started. We even have a few key services slated for development on our one year road map that will use Elixir, a direct result of the learnings from the off-site.
Do you want to run a hackathon for your company? Do you have other ideas around how to help a company transition to a new technology or framework? I’d love to hear what’s worked for you or your team.
