RubyConf 2017 Retrospective — Day 1
As a devoted Rubyist for the last eleven years, I continue to find things to love about Ruby and its direction as a programming language. This year’s RubyConf is my sixth, and has a fun symmetry with my first attendance back in 2010 when RubyConf first came to New Orleans. Below are my thoughts on some of the talks I was able to attend on day one.
Please excuse any mistakes; this post is based on sparse notes and recollections and has not been thoroughly edited.
“Good Changes, Bad Changes” (Yukihiro Matsumoto)
It is fitting that Matz kicks of each RubyConf with the opening keynote. This year, like in some years past, the question was asked about how many attendees were coming to RubyConf for the first time. The response was surprising in terms of the overwhelming number of hands that went up, which led to a lot of applause from the rest of the attendees. I found the number of first time attendees encouraging because even though Ruby has faded as a “new and shiny” choice, it remains a meaningful and relevant choice for web development and numerous other fields of pursuit.
Like many of Matz’ talks in the last couple years there was a focus on the health of the Ruby community and the continued work on the CRuby runtime. Remembering the transition from Ruby 1.8 to 1.9 the theme of risk and community adoption were at the center. Ruby is not the only community that has struggled with making breaking changes in the language. The popularity of Rails in particular introduces in our community a strong and vocal counterpoint to certain kinds of changes. But, thankfully there have not been enormous delays in adoption of new versions of the Ruby language. The risk of Second System Syndrome has been well manages, so far. Unlike projects like PHP 6 and ECMAScript 4 Ruby has not had to abandon any upgrade attempts wholesale.
A lot of that owes to the incremental and primarily additive nature of many changes in Ruby since the release of 2.0. Matz made the point that even those incremental approaches can bring risks to the cohesiveness of the community. Looking forward to Ruby 2.5 and 3.0 there are changes that have the potential to introduce breakage. But, sometimes the breaks present enough benefit to justify being undertaken. One example that I feel exemplifies this is the proposed move to frozen string literals by default. The potential performance benefits seem sufficiently desirable and being explicit when strings ought to be mutable seems desirable to me.
The big take away for me from Matz’ keynote was that call he made for the community to get involved with the discussions about the future of Ruby. He was honest that most requests will be rejected, but he wants to hear from those using Ruby. He accepted that ultimately the language is his responsibility, but he does not want to and can not take the language where it needs to go by himself. I hope others will take the same encouragement to get engaged with the discussions around new language features and proposals. In the end, I think this was a great kickoff to RubyConf and struck an inviting, inclusive and hopeful tone.
“There Are No Rules in Ruby” (Max Jacobson)
Ruby is known for its flexibility and expressiveness. Max Jacobson tackled some of the ways that Ruby’s flexibility can be unappealing and even confusing by exploring the concept of rules. The practical example that Max used was the stark difference between these two instructions:
“Employees Must Wash Hands Before Returning to Work”
“Employees May Wash Hands Before Returning to Work”
In comparing Ruby with Rust there was valuable questioning of whether Ruby is too flexible, and whether its suitable as a language for new programmers. In the end Max acknowledged the appeal and the value of Ruby’s flexibility. I think Max rightly identified that the only solid rule in Ruby is “the actual rules are whatever you make them.” This flexibility is what brought me into Ruby and it’s what makes me want to keep working with Ruby. So-called safety in programming languages can only go so far and I’m OK writing tests to supplement for protections my language does not provide me.
“Finding Beauty in the Mundane” (Megan Tiu)
Megan Tiu presentation on how to enjoy what many consider mundane work was helpful in terms of shaping perspective about the nature of this kind of software development work. She started off by noting that enjoying our work has a lot to do with empathy, which is a heavily used term in certain segments of software development right now. I think the concept, both in the context of Megan’s talk and more broadly, gets back to remembering that software is built both by and for people.
One of the most valuable facets of Megan’s talk was her examination of how different tasks can have positive impact on the people we work with and the people we build software for. As an example, she noted that documentation can be a way to reduce siloing of knowledge within a team and it also can provide helpful perspective for those who use our software. Likewise, I appreciated that while she didn’t use the phrase “tests are documentation” she described that very fact in presenting that tests can be a valuable tool for introducing new team members to a codebase.
Unfortunately this talk was cut short by a fire alarm that turned out to be a false alarm. The talk was helpful in pointing out how certain work may be considered mundane, but its all about how we approach it, especially regarding our frame of mind. We have to remember that we are building software for people in most cases, and so our care for those people ought to be reflected in what and how we work.
“Augmenting Human Decision Making with Data Science” (Kelsey Pedersen)
Kelsey’s talk provided some really interesting context for thinking about Machine Learning in a business (Stitch Fix) that relies on highly subjective judgements regarding style. She laid the foundation by exploring the Dual Process Theory of cognition and then describing how Machine Learning has been applied to the business model of Stitch Fix to augment human intuition in order to make the work of their stylists more accurate and more efficient.
Some of the most helpful insights that came out of Kelsey’s talk for me was the recognition that there are certain kinds of decision making that is still difficult for machines. Machine Learning tends to be very good at narrowing down a set of choices, but when there is a subjective component they can struggle with the needed specificity to make a final selection. Also, she noted that algorithms have limitations on the scope of their experience and they lack robust ethical frameworks. The solution to some of these deficiencies for Stitch Fix turned out to be the most valuable.
Both in the context of individual item selection and the finalization of an entire bundle of products, Stitch Fix permits the stylist to override the recommendations of the Machine Learning algorithms. This model she referred to as a System 3 approach that relies on blending computational decision making with human intuition via a feedback mechanism that allows both the human and the machine to grow and learn over time. This struck me as being a useful approach to ensure is built into any robust Machine Learning model.
“Growing Old” (Chad Fowler)
The closing keynote by Chad Fowler resonated with me a lot. During some conversations I had at the O’Reilly Software Architecture Conference in London I expressed and talked through my dislike for the pejorative way that the term legacy is used to describe software. This same theme was a focal point of Chad’s address. I appreciated how in every other pursuit; especially creative ones like music, art and architecture; the term legacy is more often incredibly positive.
The big takeaway for me was that our legacy as builders of software is not the code we write, but the systems we build. The systems we construct are what bring value to the businesses we work for and the users that we serve. I find the idea that the legacy of software developers comes in the form of the whole, and the ideas it embodies, far more appealing than thinking of my legacy as being represented by the code I write, no matter how proud I may be of it in the moment.
So far RubyConf has gotten off to a great start. There are lots of interesting topics and my summaries will only scratch the surface. I look forward to the videos becoming available in a few weeks and reviewing the talks I attended, as well as exploring some of the talks that I had to choose to skip over. Everyone should bookmark the RubyConf section over at Confreaks.
