Last weekend, I attended Ruby for Good at George Mason University. Ruby for Good is a cross between a mini-conference and hackathon where participants spend three days building web applications (or other software) for non-profit organizations. This was my second year attending and my first time leading a team. I personally think our team was amazing and managed to deliver a great application, but I definitely learned a few things along the way about leadership and deadlines.

You Can Never Be Too Prepared

I learned I would be leading a team about a month early, and I attempted to make good use of that lead time by contacting my organization’s representative early and often via email and phone. After a few conversations, I wrote up a series of user stories for her to review, comment on, and approve. Then, I turned those user stories into Github issues. I did all of this in an attempt to understand the domain as deeply as possible. At Ruby for Good, the team meets on Friday morning and delivers a project on Sunday afternoon. The faster I could transfer my knowledge of the problem space to my teammates, the more productivity we could squeeze out of those 2.5 days.

I set a goal of having a code repository ready and waiting for teammates to clone on the morning of the event. It’s easy to lose half of that first day to environment and build issues. So, after initializing a bare Rails app, I wrote a README with a list of succinct instructions for getting up and running as quickly as possible.

I prepared as best I could prior to the event, and I think it paid off. Teams were selected at approximately 10AM on Friday morning. The first commit from one of my team members occurred at 11:41AM. The first pull request was merged at 3:30PM, and that was after we took a break for lunch.

Being Decisive Saves Time

Time is the most valuable asset at any hackathon. Ruby for Good amplified that feeling because I wasn’t simply building something for myself. I made a commitment to deliver a working application, and I wanted to follow through on that promise. There were two things in particular that I didn’t want to waste time on: Technology choices and stakeholder feedback.

I normally take the time to evaluate technology options carefully by comparing the requirements to the available solutions. I consider if it’s worthwhile to experiment with pre-1.0 products. I poll my teammates to see what they’re interested in and if we can find an opportunity to learn something new. None of that applied in this case. The choices I made were meant to be traditional and obvious to Rails programmers, regardless of experience level: The latest stable versions of Ruby, Rails, and Postgres. Vanilla JavaScript without any frameworks. I set up deployment using Capistrano to an Ubuntu 14.04 machine on Digital Ocean. The team later decided to use the CSS portions of Materialize, but that was a deferred group decision that was easy to drop in during development.

I did my best to eliminate anything that resulted in waiting on stakeholder feedback. Normal, non-programmer people who aren’t participating in hackathons typically don’t respond to email very promptly on weekends. It’s a bonus if a particular stakeholder is able to be more involved, but it’s not the expectation. A sufficient amount of preparation meant that I wasn’t waiting for responses to questions and blocking development as a result. In those rare situations where something questionable came up, I took the initiative, made a decision, and acted on it. If it turns out to be the wrong choice and the resulting feature isn’t delivered just right, that’s fine. Tweaking things later in response to feedback is just iterative development. The most valuable (and limited) resource available to me in this situation was the time of my team members, and I didn’t want to waste it on indecision.

Junior Developers Know More Than You

The team had a healthy variety of experience that was evenly split between senior and junior developers. My goal as a lead was to find divisions of work appropriate for those different experience levels. I wanted everyone to feel that they were making important contributions. To that end, I tried to set aside tasks for the junior developers that were more straight-forward or easier to reference in documentation: Using generators to build out application scaffolding, or integrating third-party login using the OmniAuth gem. Meanwhile, I leaned on the more experienced developers for things like researching integration with various Google APIs and making higher-level architectural choices for the entire application.

One thing I didn’t expect was the sheer amount of new stuff I learned from reading pull requests from junior developers. I spend my days working on an older Rails application with a fairly stable set of gems and libraries. The people on my team at work are mostly senior developers. It was great having exposure to gems I’ve never heard of and language or framework features that I don’t normally have an opportunity to use. I pride myself on continual learning and professional growth, but this was a stark reminder of just how quickly technology moves. More importantly, it was a reminder that experience diversity is a good thing.

Leadership Means Becoming a Renaissance Developer

Our team had people comfortable working at most levels of the stack: From design, styling, and JavaScript on the front-end to Ruby and Rails on the server. One thing we were missing was someone to handle the infrastructure, operations, and deployment strategies. I initially filled that role myself, but soon started taking on a variety of increasingly diverse tasks in support of other team members. I was suddenly very thankful for the excuses I’ve had to work on all sorts of crazy projects at every level of the stack. I often worry that I’m not focusing on specific skills enough; that I’ll end up with knowledge that is wide but shallow. That’s still a concern, but this showed me the importance of being able to jump into any role that a team might need.

Doing Good at Ruby for Good

Ruby for Good is an opportunity to participate in a full (albeit accelerated) project lifecycle from concept to delivery. That kind of experience can be hard to come by. It’s valuable to have insight into how a project evolves beyond simply writing code, and that goes double for anyone considering freelancing or contracting. The icing on the cake is the knowledge that you’re giving a little something back to organizations who wouldn’t otherwise have the means to hire developers. We’re all immersed in technology and surrounded by brilliant people on a daily basis, and that environment breeds impostor syndrome. This conference is a great reminder that everyone’s skills are valuable and the demand for them is high, regardless of our perceived self-worth when compared to peers. Ruby for Good might not be able to save the world in a single weekend, but I think it does a pretty good job at making things a little better.

If you enjoyed this post, please consider subscribing.