Kiwi Ruby Hot Takes
Last week our whole team went along to the Kiwi Ruby conference here in Wellington.
Flick developer Raquel Moss was one of the Kiwi Ruby organisers, and she was excited to see many months of work come together in a great event.
Reflections from a conference organiser
Over the last nine months I was part of a team of organisers who took on the mammoth task of organising Kiwi Ruby. It’s the first Ruby-related conference to take place in New Zealand, and we were thrilled to hold it at Te Papa in Wellington. Over two days, over 220 people from Australasia (and a few from further afield) attended workshops and talks, presented by an excellent group of developers.
We wanted to make Kiwi Ruby a welcoming conference, where people felt inspired and excited to try new things with Ruby. We were pleased to offer free on-site childcare, free tickets to people from underrepresented groups in tech, and subsidised tickets for students.
It was all made possible by our generous sponsors, and the friendly Ruby community in Wellington. Tino pai!
Here are some of the highlights for our team.
Hello Gmom!: Pushing back against loneliness in end-of-life care — Jeremy Flores
One of the many fantastic talks from Kiwi Ruby that has stuck in my mind, was the final talk of the conference ‘Hello Gmom!: Pushing back against loneliness in end-of-life care’, sensitively delivered by Jeremy Flores. He told the story of his girlfriend’s grandmother, and how a stroke left her isolated and how he built her a web app to be a ‘window into the life of her granddaughter.’
Some of the tenets of his development of the app were ‘keep it boring’, that is don’t over engineer, solve problems for the people you love, whilst remembering that not everything needs to be a product, which all resonated with me. It was a great reminder that this industry is about helping people, and that we should keep front of mind, ‘Do what you can to protect the dignity of others’, as we build.
— Olivia
Security Without Friction — Graham Jenson
Graham has some great stories from his work at Coinbase where, as you can imagine, security is a top priority. He talked about implementing the principle of least privilege such that internal staff have access to only the minimum authority required to perform their role. This is something we think about a lot at Flick.
Graham talked about how they use M of N key distribution models at Coinbase. An example of this would be splitting a secure key into 7 parts, and then requiring any 3 parts to be present to proceed with an operation. This can be used to varying degrees depending on the sensitivity of the operation.
Choosing Failure — Lena Plaksina
Lena’s talk struck a particular chord with me, as I see certain patterns over and over when working with people who are new to software. She was talking about failure.
Most often, as we grow up, we’re conditioned to treat failure as something bad, like it’s some strike on our permanent record. We then carry this through our lives where it affects our workplace behaviour and the cultural norms we develop. But take a look at preschoolers, who haven’t learned this yet: when given the same challenge (to build the tallest tower out of spaghetti and tape) as a group of trained architects, the preschoolers build higher than anyone else. Instead of planning the perfect structure from the outset, they experiment, build towers, watch them fall, and repeat. They don’t fear failure; instead, they use it as a testing ground for ideas and experimentation and end up learning very quickly as a result. Lena wants to flip our aversion to failure on its head. Instead of trying to be right 100% of the time, let’s be comfortable failing, and make our environment comfortable and safe to fail in, and then learn from our failures.
We don’t know what we don’t know, right? So break things and see what happens — the more mistakes we’re willing to make, the faster we’ll learn.
— Greg
Here’s to History: Programming Through Archaeology — Eleanor Keifel Haggerty
I really enjoyed Eleanor’s talk, the archaeologist-turned-software developer, where she drew a lot of comparisons between how history is uncovered from both ancient Greece and ancient git commits. She talked a lot about πρᾶξις (práxis), and how we construct our work history.
History and context are super important. If you’ve ever found a line of code in a mature project and thought “now how did that get there?”, followed by “git blame file.rb” then you know how important it is. This ability we have to look back in a project’s history to figure out how and why something does what it does makes our lives a lot easier. In archaeological terms, by looking at the layers as they are removed (while very meticulous recording and documentation is taken), we can infer relationships between structures and events in time. With that, we can construct a fairly accurate picture of the events around that particular time period.
One of the main takeaway points was that we have this opportunity to create our history; to record and put context around the events that take place during development. If we take a look at our commits in a few weeks, a few months, a few years; what will we know from them?
— Greg
A Brief History of Time.new — Daniel Fone
Kiwi Ruby was my first conference as Flick’s new data scientist, and my first tech conference ever. Not sure what to expect I was enthralled by speakers discussing a wide range of topics in much more entertaining way than the somewhat drier scientific talks I am used to.
One of those speakers was Daniel Fone discussing the concept of time and calendars in his talk “A Brief History of Time.new”. Daniel took us back in time, walking us through why the calendar and time is the way it is and explaining some of history of time’s interesting idiosyncrasies (looking at you October 1582). As one of many people who have thrown a laptop out the window in response to having to deal with a myriad of time-zones and formats it was interesting to hear Daniel explain just why dealing with time can be so difficult and, unfortunately, why it probably can’t be any easier than it is.
