This year, I had the good fortune of attending RubyConf along with 800 awesome Rubyists. As someone who is still fairly new to industry, this was my first major language conference, and I didn't quite know what to expect; I thought I might learn a few new things about the Ruby language and meet some new people. Needless to say, I was not quite prepared for what I was about to experience.
Though I did learn a lot about code, I learned so much more about community, collaboration, and ethics. The people I met thought not just about the software they wrote, but the context in which they wrote it. I had conversations with total strangers about engineering culture and how to best encourage underrepresented developers. I ended each day of the conference feeling giddy -- I couldn't wait to tell my friends all of the amazing things I'd learned that day.
In this article, I want to share the three most important lessons I learned at RubyConf. I've used Ruby boolean expressions as section titles because Ruby is great, and I am a nerd. (And yes, all of the titles evaluate to true.)
Lesson one: code == community
The first talk of the conference was a keynote by Yukihiro Matsumoto, (aka Matz), the creator of the Ruby language. Though Matz spent much of his talk focused on the new features being introduced in Ruby 2.7 and Ruby 3.0, he opened his keynote, and the conference, by highlighting what makes Ruby great. In his own words: "Ruby creates programming joy."
Ruby is a language created to be readable. It is created to make people enjoy programming, which will boost their productivity and encourage them to develop tools and frameworks around it. Ruby is a language fueled by the people who love it.
Of course, this means that Ruby can't survive without an active community.
It's no secret that the Ruby language has been losing popularity over the past few years, especially as Python becomes increasingly popular for scripting and data science work. This fact is not lost on Matz. He emphasized that the Ruby community needs to keep growing, but that he and the other Ruby language maintainers can't expect loyalty for free. They plan to roll out features that have been requested by the community, such as pattern matching, improved GC, a better repl, an improved concurrency model, and static typing.
The first lesson I learned from RubyConf is that community is the essence of code. When you create an open-source library, you're not just releasing streams of binary into the void. You're getting someone on the other side of the world that much closer to building their dream project. You're teaching a new engineer best practices. You're unblocking the way so that other people can build on top of your work.
That leads me to my next lesson.
Lesson two: (idea + collaboration) > idea
After Matz's keynote, I attended a session called "Thomas Edison vs. Three Teslas in a Trenchcoat," presented by Coraline Ada Ehmke. Though her talk was primarily about choosing when to adopt new technologies, Ehmke said something that really struck me (and I'm going to paraphrase here because I didn't write down the exact quote during the talk): ideas flourish within intense intellectual relationships.
Software engineers love to spread the myth of the lone genius -- they imagine the ideal engineer as a man (usually) so brilliant that he doesn't need to collaborate with anyone else. In software engineering, this could manifest as the senior engineer who refuses to document his code or deploys without code review -- you know, your typical "10x engineer." Much has been written on the topic of the "lone genius," so I'll point you to one Medium article that I particularly like).
In her talk, Ehmke gave the example of one of the most famous "lone geniuses" in history: Nikola Tesla. Tesla was notorious for being an eccentric loner, but Ehmke emphasized that he could not have revolutionized the field of electrical engineering by himself. In fact, it was his rivalry with Thomas Edison that forced him to become smarter and more creative, to make his ideas bullet-proof. Though we often point to Tesla as an example of the "lone genius" archetype, he was anything but.
At RubyConf, I attended countless sessions that stressed the importance of collaboration. On day one, the closing keynote was a talk called "Collective Problem Solving in Music, Science, Art, and Software" by Jessica Kerr. In her talk, Kerr emphasized that software engineering is the product of the relationships between people and the software they build. Whether or not an engineering team is successful depends on people on the team having accurate mental models of their code. As software systems grow increasingly large and complex, it is impossible to trust one person to keep a model of an entire system in their head. Our success as engineers depends entirely on our ability to transfer our mental models, especially (ESPECIALLY!) to people who think differently than we do.
Kerr put it perfectly when she said, “Ideas become bigger when you share them."
Lesson three: (code - context).empty?
It's hard to pick my favorite part of RubyConf, but if I had to choose, I would say it was the Birds of a Feather (BoF) sessions. If you're unfamiliar with that term (as I was until literally the day before the conference), a BoF is an informal session where people can get together to discuss a topic of shared interest. At RubyConf, I attended two BoFs.
The first was a session on Ethical Open Source led by Coraline Ehmke, whose talk I had previously attended. She recently created the Hippocratic License, an open source software license that prohibits people and organizations from using software to commit human rights violations. In her session, we talked about ethical open source licenses, why they're necessary, and what we can do as developers to promote ethical development practices.
The second BoF I attended was about Ruby For Good, an organization that puts on conferences where Ruby developers build projects to help non-profits. During this session, I spoke to some of the Ruby for Good organizers and participants about about the projects they'd seen, including a diaper bank inventory app and a data tracking system for abalone conservancy. They had a pretty easy time recruiting me, and I hope to start contributing a Ruby For Good project in the next couple weeks!
The lesson I learned from these Birds of a Feather sessions was two-fold: not only do we have an obligation to create tech that makes the world a better place, but we also have to ensure that our work isn't used to cause harm.
Sandi Metz, author of Practical Object-Oriented Design in Ruby, brought this message home in the final keynote of the conference. Metz began her talk, titled "Lucky You," by explaining the difference between lucky people and unlucky people. According to research done on the subject, people get lucky because they expect to be lucky. Of course, that begs the question: who expects to be lucky? Throughout her talk, Metz demonstrated that where one grows up, along with one's race, gender, and income level, often predict how successful (lucky) they will be. This isn't because certain groups of people don't work as hard or aren't as smart; it's because of systemic inequalities that date back generations.
In recent years, big tech has done a lot to widen the inequality gap. We live in an economic system designed such that the tech-elite can hoard wealth while many people can't even afford to pay their medical bills. This is wrong, and those of us who have the privilege to work in tech are responsible for making sure it gets better.
This was my biggest takeaway from the conference: code cannot be separated from the context in which it is written. The software we build has real-life consequences. It can give a platform to the voiceless or expose people to bullying and abuse. It can spread information faster than ever before or foster communities riled by hatred. It can be used to open up the world or tear people from their homes and families.
We choose what our technology does, and those choices matter.
Metz ended her keynote with this call to action:
Decide what social problem pisses you off most, and then pursue a solution that is public, democratic, universal, and institutional.
~ Anand Giridharadas
My hope is, that now and throughout my life, this is what I choose to do.
I went to RubyConf to learn how to be a better coder, and I did, but not in the way I expected. I learned about the importance of software communities. I learned that ideas are best when shared. And finally, I learned that our code is only as good as the context in which it is written.
There is still a lot of change that needs to happen in the tech world. However, I came away from this conference with a fresh perspective and a renewed commitment to work towards the things that drew me to tech in the first place: spreading ideas, creating things that matter, and empowering others. My hope is that, by writing this blog post, I have encouraged you to do the same.
And who knows. Maybe we'll see each other in Houston next year.
Addendum
In a blog post partially about Nikola Tesla, I would be remiss not to include my favorite Tesla-related thing from the internet. This is taken this post by Tumblr user salamandertoast. Here you go:
Top comments (0)