RailsConf 2018: Day One
By Steph Skardal
April 17, 2018
It’s day one of RailsConf 2018, and I’m in Pittsburgh with baby Ingrid (daycare FTW!). This is my 8th time at RailsConf and third time with a kid (SELECT DISTINCT kid FROM skardals). In my first few years of attendance, starting in 2009, I absorbed much more on the technical side, but the talks that have struck a chord in recent years of attendance have been more on the side of the human element of software and software engineering.
Concept Compression
DHH started the day with the opening keynote, and I perceived the main focus of his talk to be the idea of “Concept Compression”. Ruby on Rails has spent many years compressing concepts (e.g. ORM) to lower the barrier to entry. In theory, this should allow more diverse people to enter the software field, but the problem is that while we’ve been compressing concepts along our way, we’ve also added significantly to the list of things that developers ought to know before they start coding.
DHH has always been focused on developer happiness in Rails, so to me, this topic was another extension of developer happiness in talking about the progression of Rails over the years. If Rails isn’t careful, we’re bound to repeat mistakes of the past (e.g. too many concepts, too much to know, too much complexity), and the Rails ecosystem could implode, only to see the cycle start up again.
Scaling the Artisan
One of the first talks I attended was Scaling the Artisan by Coraline Ada Ehmke. She discussed how we as software engineers are artisans, not scientists, ‘hard’ engineers, or architects. She went through a few examples of the history of artisans and the products they crafted (e.g. screws, swords, guns). In these examples, industrialization and creation of interchangeable parts are just two examples that improved production and allowed artisans to focus on the innovation and creativity rather than production.
She drew many parallels to these historical artisanal practices to software engineering. She then went on to what it means to be a senior developer, or a senior artisan, as opposed to a junior dev using tools. It means that you consider the following questions:
- Should we solve this problem with code? Does every process need to be turned into code?
- Can we fix this with better communication instead of code?
- Is this something we should build ourselves? Or should we leverage existing tools?
- Should we extract this into a library? Could it be packaged for shareability?
- How do we build consensus? Can we evaluate alternative solutions openly?
- How do we spread best practices?
- How can we help teammates level up?
- How can we code ethically? This is specifically timely because of all the data leaks reported in the news.
What really spoke to me during this talk was how it related to a recent blog post I wrote about working as a consulting vs. in-house, where I ultimately think the best senior devs are ones that are both technically skilled and also excel at non-technical skills such as communication, prioritization, and showing empathy. Coraline did a great job connecting the dots between the software industry and artisanal occupations in the past and it was a compelling talk.
An Atypical Performance Talk
Another talk I attended was An Atypical Performance Talk by Chris Arcand. This talk/performance mixed live clarinet playing with a comparison of becoming a skilled musician with becoming a skilled software engineer. The topics Chris discussed are summarized below.
Handling Complexity
In both music and coding, at first glance a new music piece (codebase) can look daunting, so it’s best to break things down. The more skilled musicians (developers) can absorb complexity quicker, but they have more experience being exposed to many similar patterns over a number of years.
I like to describe a new codebase like a map of a city when you’ve just moved in. You first learn the most basic instructions such as driving to the grocery store, gas station, and office. Then, you memorize those paths, and move on to a more intermediate set of directions. Each time you head out, you absorb more details on your driving paths until eventually you have a 2D map in your head and you are able to instruct directions to someone else. Complexity is relative, and breaking it apart into digestable components allows you to learn in pieces.
Concentration
The most successful musicians are able to concentrate deeply. Chris recommended the book Deep Work for this topic. Because deep work/concentrating deeply is exhausting, it is important to acknowledge the importance of balance in life. Chris’ music instructors recommended limiting individual practice daily to allow him to balance his life with other interests. This was especially meaningful to me because I have worked half-time for 5 years now, and I can make a strong argument for being very productive in that time that I work because I’m able to have balance outside of work.
Hero Worship & Imposter Syndrome
Finally, Chris talked about the presence of hero worship and imposter syndrome in both music and software. He says, “your heroes are normal people” who have worked hard. They are simply able to handle complexity, concentrate deeply, and exercise balance in their lives to create quality work that others admire.
Other Notable Talks
I attended a few more talks that were related to the human element in coding, including Keeping Moms Around For the Long Term by Tess Griffin, Stating the Obvious by Ernie Miller, and the keynote “Rails Doesn’t Scale” by Mark Imbriaco. All of these speakers shared personal experiences and what they’ve learned throughout those experiences, and I found them to be very relatable, and some even timely in my current position as I balance working with three young children.
I also attended a couple of talks on specific technologies and their uses (GraphQL and webpack). Overall, it was a great first day at RailsConf 2018. I am looking forward to two more days!
Comments