It isn’t very hard to pitch tech conferences. Offering a getaway from the usual desk work, a chance to pick up on new wisdoms from like-minded and genuinely inspiring folk, and room in the itinerary for sightseeing and socialising in the hip host city in between times? It’s a no-brainer… well, for most. I had never travelled by myself, let alone flown solo. I’m a junior as well as a woman in tech, so that should make me no stranger to navigating new territories… but this was a whole different venture! While every interaction I’ve had in the Rails community has been nothing short of friendly and insightful, and I was sure there was lots to get out of these conferences, the idea of going to one? It was too daunting.
Ruby for Good compelled me though. I’ve always vowed that I will use my coding skills to make things better in the world. Ruby for Good was an opportunity to do just that. That’s how I arrived at Edinburgh Airport, packed with my belongings and full of nerves, jetting out to Ghent to attend the Ruby for Good event.
The Band Assembles…
On day one, after sneaking in a Belgian carrot cake waffle for breakfast (delightful), I identified and met my fellow Ruby for Gooders. Then, we got dove right in. I learned all things SkillRX. SkillRX is a project with the primary goal of delivering ongoing medical education for people in low-resource areas, where the internet is a premium or non-existent.
It starts with medical training providers, who create topics and attach training materials with search tags. Originally, Raspberry Pis would be sent out to health providers that would broadcast a web interface to find and view these training materials. There was an issue though with how they were providing the content. That being an inefficient, slow, and duplicative sync through Azure file storage for media files. Our mission then? Get that dependency on Azure gone! We would roll in Beacons – devices that would directly communicate with the health professionals’ CMS.
So marked our noble quest. We put our issues into digital ink. We spoke to stakeholders. We diagrammed over dinner. I use the word “quest” purposefully here. Because, at the end of the day, much like a knight who had battled the dragon and saved the princess, I was exhausted. I also had a hero-esque realisation: Working on open-source code would be very different from working on code at my job.
Beginner Mission: The Tests of Open Source
The first thing I learned, which tends to go hand-in-hand with most open-source projects, is the asynchronous working style. While we were all gathered together as a merry crew for this event, the work we were going to do wouldn’t be wrapped up in a few days. To continue contributing to this project, we’d have to get comfortable with working across different parts of the world. Also, our stakeholder from before? Different time zone. That gave weight to the time I spent with the people involved in the project. Getting a change request on a PR for a single typo could be ten times more cringeworthy and hold up the approval pipeline much longer.
Even with mistake-free code though, there was still that learning curve of a new codebase and a new context. Have I understood the project’s architecture correctly? What will I add? Am I a skilled enough programmer to even contribute?
The Power of the Party
It first helped to find that some of my team were also in similar situations. It’s harder to feel like an imposter when there are people to empathise with. It was also encouraging to see how others were contributing. For instance, someone started by cleaning up the app’s Tailwind code, which was very much appreciated. This showed me that a good start to my open source journey would be to ask myself what my current strong suits are, and how I could bring them to the table. I recognised that APIs were something I was familiar with, from my fourth year university project. This seemed helpful for configuring beacons. When a beacon was to be distributed, it’d come with a token. Once plugged in, the beacon would download content based on its configuration. This seemed similar to token-based API authentication, so I took up issues surrounding beacon configuration.
As for those on the team who were already familiar with the project, they were more than open to help. In fact, these maintainers were willing volunteers to act as our sounding boards, and to sit down to explain concepts or pair-program. There was an unspoken understanding from the maintainers that by empowering new members, and teaching them to fish, was how projects like this will be successful in the long term. What did this mean for me? Well, not only is it cool and extremely valuable to learn from developers who have been in the Ruby on Rails world long before me, it was this kind of support that really got my motivation flowing.
Realising how I could be useful and contribute allowed me to wrap up the conference with a nice little bow. By a nice little bow, I mean coding an admin dashboard interface that allows users to manage and work with beacons, including configuring tokens. While being in a space where it was easy to collaborate, form bonds and share skills played a big (massive!) part in accomplishing this contribution, Rails, and the cornerstones around it, was also instrumental.
Ruby on Rails: A Magic Potion?
To be more specific, I’m talking about the “Convention over Configuration” paradigm. We work with an opinionated framework, so we’ve naturally gravitated to some community-wide defaults. The Ruby for Good project used Hotwire, for example, because it enables you to build uncomplicated yet highly interactive frontends. Its reputation precedes it because it is used here at FreeAgent for that same reason. Seeing some familiar faces like this in the codebase helped.
Although there were some comforting familiarities, the Ruby for Good codebase had its own distinct identity I had to learn! Because the Rails framework handles the grunt work of most of the architectural and project design decisions, legacy will rear its head in codebases that have been around for a long time. An example of this is how we test controllers. This project used the more recent default of request specs, where FreeAgent goes with controller specs. There’s also the scenario where you’ll want to stray away from the beaten Rails path and explore other paradigms. Take service objects, for instance. As their purpose is usually to thin out models or controllers by handling certain business logic, where do they fit into the MVC pattern?
Last but not least, every programmer knows it well: Code efficiency versus code readability. This will always be a subjective matter. I was surrounded by brilliant people at Ruby for Good. I witnessed many clever ways to write code. Yet, there were compromises made in not making the code smarter – simple code is easier to reason about. That isn’t to say I’ve swept any and all ingenious suggestions under the rug – I’m extremely appreciative of all the comments on my Ruby for Good pull request! I’ve seen and learned interesting ways of doing things, and I plan to incorporate some of these learnings into my FreeAgent work!
So Marks the End of the Quest…But not quite!
FreeAgent has always seen all the value in conferences: an opportunity to get inspiration for your craft and learn from the Ruby community, veterans and juniors in between. While this sort of thing was my first, I can imagine that Ruby for Good isn’t your typical run-of-the-mill tech event. Our work is still ongoing, and the point of the event is to help build more of a community that can go forward and make a difference through code. Having something like this to work on during my development time feels significant. I’m solving a big, real-world problem and helping people in need! In (fun) fact, SkillRx is helping over 20 million people in the global south! I’m dedicated to continuing to contribute: existing issues are waiting, and I’ve even spun off my own to tackle in the future! I’m very proud to be part of this project, and I am very excited to see how it forms.
