This past weekend, I wrote an article on the Super Good site about how to start debugging code in the gems that your app depends on. In the conclusion I mention that taking the opportunity to explore code written by people outside of the project you’re working on can be really beneficial, and I want to expand on that thought a bit.

One of the first things I used Ruby for professionally was building Tumblr themes. We used Middleman as a build tool which worked pretty well as Tumblr themes are really just static HTML files with some custom template tags in them. Another developer in the office (who worked for a sister company) had even built a tool that made local development (powered by Tumblr’s API) possible.

No one working at the company had much Ruby experience, but we didn’t need to do much beyond using the configuration DSL to get the asset pipeline working correctly, so this wasn’t a problem.

One day I found that there was something missing from the tool we used to do local development, and it was preventing me from testing certain kinds of audio posts locally. This presented exactly the opportunity I described above, a chance to read some code written by a Ruby programmer outside the team, understand and debug the code, and make a small contribution to an open source project.

The specifics of the scenario were really fortunate for me. The author worked in the same building as I did. I was comfortable suggesting a change to him. The change was something that benefited the whole team. The issue was something that I could solve with my limited Ruby experience.

I explored the gem, figured out how to make it do what I needed, and opened a PR. The author provided some feedback which I learned from and addressed. (I had no understanding of what Module#include did at the time, and misused it.)

My PR was merged. It was my first contribution to an open source project on GitHub. I didn’t view this event as particularly foundational or significant at the time. I’d even forgotten that this was my first accepted PR until I started writing this.

Looking back now, I can see that I was lucky. Everything came together for me to learn the lesson that the gems we use are just other people’s Ruby projects. Learning to read, understand, and debug the gems I use was never something I consciously learned, but I believe it to be one of the most important skills that has helped me become a better programmer.

If you’re not comfortable jumping into the gems you use and reading them, I encourage you to try it. Don’t restrict yourself to only the code and ideas produced by your coworkers. You’ll learn new patterns, techniques, styles, ideas, and you’ll find things you never knew you could do in Ruby. There’s a whole world of Ruby code out there! Don’t let the edges of your codebase be a barrier that stops you from experiencing it all.