tl;dr: My weekend at Ruby for Good taught me that imperfect, shipped code is better than perfect code that no one sees.
A couple weekends ago I had the opportunity to attend Ruby for Good in Fairfax, VA at George Mason University. Ruby for Good is a conference/hackathon where participants split into teams and spend the weekend hacking on projects that benefit someone or something. The “someone or something” is typically a charitable organization of some sort, and the projects span the gamut. They could be (and were) anything from improving documentation on existing open-source projects, to building a greenfield app from scratch for a nonprofit.
The team I was on did the latter. We built a fresh web application from the ground up for a nonprofit. I had a great time, met some awesome people, and learned way more than I thought I would going in.
Our team built an issue tracker application for Pathway Homes, a nonprofit dedicated to providing housing to adults with mental illnesses. We started the weekend in the advantageous position of knowing who our stakeholders were, and having a fairly good understanding of what they needed. Up until now, tracking maintenance issues across their properties meant one employee listening to voicemails and taking notes in Microsoft Word. This was great from a developer perspective: Anything we produced would be better than the current system.
Team members started off by identifying our individual strengths. Few things make me happier than a well-designed data model and a great backend API, but somehow I ended up leading the frontend team. This was probably because I suggested using Angular. It just so happened that not only was I the only person with any experience using Angular, but several other people were immediately excited about the opportunity to learn something new throughout the weekend. I had my reservations initially, but those were soon replaced with excitement at the prospect of being way outside of my comfort zone. These kinds of conferences are all about doing something new. On top of that, I was in a position to lead and teach: Two areas in which I definitely want to improve.
I was initially concerned about the architecture of our application. I thought we were making hasty decisions that would come back to bite us later on. That fear soon faded away, and was replaced by the driving need to Get Shit Done. It was great. I’m typically the sort of person that will spend hours or days agonizing over the perfect system design. That doesn’t fly in a hackathon situation. Inspired by team members who were pushing changes left and right, I soon fell in line. The Github stats by Monday morning speak for themselves…
That is an absoultely insane amount of work accomplished by 10 people in less than 3 days. It’s even more insane when you consider that we typically called it quits each night by 9pm in order to go be social and do conference stuff. On Monday afternoon, we had a working, (mostly) production-ready application to demo. As far as I’m concerned, any other shortcoming pales in comparison with that accomplishment.
And there are certainly shortcomings. There are design problems. There is bad code all over the place (much of it written by me). Our git practices were terrible. The separation between frontend and backend is not really identifiable despite the fact that we were using a client-side framework. But you know what? That’s okay. I don’t think I would have been okay with it before Ruby for Good, but it took this experience to bring me to that realization. Perfect code is worthless if it doesn’t ship. Our goal was to write an app that would make life easier for a nonprofit, and that’s what we did.
We learned something. We shipped something. We had fun. Who can ask for more than that in one weekend?
If you’d like to contribute or you’re just curious, the code is available on Github.
If you enjoyed this post, please consider subscribing.