EMPEX Speaker: Kate Travers
Kate Travers is software engineer at the Flatiron School in New York City. She will present “Pattern Matching: The Gateway To Loving Elixir” on May 19th at our conference in Manhattan. Kate sat with me to talk about here love of Elixir, how they’re using it at Flatiron School, and how she came to software development.
Troy Denkinger: Hi, Kate, thanks for your time today. Where are you working currently and what is your role?
Kate Travers: My official title, very grandiose, is “software engineer” at the Flatiron School — it’s full-stack web development all day, every day. I was at Flatiron first as a student. When I graduated in 2015, I joined the engineering team as an apprentice and I’ve been here ever since. For the last three years, I’ve grown on the team. It’s been a blast and I absolutely love it here.
TD: And what are you working on day-to-day?
KT: It’s always in flux, which is fun. Our core application is a five-year-old Rails app. [laughs]
TD: [laughs] Sounds familiar.
KT: Yeah, pretty much. We recently started trying to modernize the front-end. We’ve gone through a couple different frameworks, as you will, and have landed on React/Redux. But what is exciting, and what brought me to EMPEX, is our team lead [Steven Nunez], who is an early adopter and huge advocate for Elixir. And fortunately we have a team that values exploring new tech like this.
We had a couple of smaller projects, and Elixir solved a lot of the issues we were trying to tackle. Most notably we had a project that was just too slow and depended on having a lot of concurrent processes running. We tried to write it in Ruby, but as you can imagine it didn’t perform quite up to what we wanted. So that was a perfect opportunity to explore Elixir. We needed to rewrite it anyway, so we spiked on it with Elixir. It was just great, so we looked for more opportunities to keep using Elixir. It has served us really well.
TD: So you are using Elixir in production.
KT: Right, yeah, and specifically in the core on-boarding functionality in our main app.
TD: What are you relying on in the Erlang/Elixir ecosystem?
KT: We have an IDE that our students can run in a browser. People work on lessons and each lesson is represented by a Github repository. So when you work on something, you clone down the repo that has a test suite in it, and you get the suite to pass.
Originally, we relied on students to setup their own local development environments, run the test suite, push code, and move the test suite from red to green, etc. But that was all in documentation we provided to help them setup their local environments, with all the necessary dependencies. As you can imagine, setting all that up can be incredibly hard especially when you’re a beginner.
So, instead we have the Elixir app manage all that. We’re relying on GenServers to the extreme, and Supervisors, to spin up all these processes. The main functionality spins up Docker containers individually for the student, for the specific lab they’re working on, clones down the lab for the student [from Github], does the bundle install — all the stuff to setup. By the time the student comes to the browser, they’re up and running. And anytime something fails while cloning, installing, or whatever, we have Supervisors to spin up a fresh container automatically for the student.
TD: The student just sees the IDE running in a browser, and they’re ready to go? That’s pretty cool.
KT: Yeah, it’s great. And we’re using Phoenix websockets to intercept the students’ keystrokes and send them back, so each student gets their own Phoenix channel per lesson.
It’s the best and solves all these problems that would have been extremely hard to tackle without the stuff that Phoenix and Elixir provide for us. “Out of the box” is oversimplifying, but they’ve solved these problems for us, so it’s a matter of applying the tools that are there.
TD: You came up through the Flatiron School curriculum where there isn’t a heavy emphasis on Elixir so far as I know, how did you address getting up to speed with Elixir after graduating?
KT: I’d pretty much been in Rails land the majority of my time as a developer. The languages I’d been asked to level-up on were Ruby, JavaScript, and various related frameworks. Even our CSS was object oriented. Being dropped into a functional language — Elixir was my first taste of that world — it required a different way of thinking that was probably the toughest thing to get up to speed with. I’m sure you’ve seen this a ton: if you’re coming to Elixir from a Ruby background, in a lot of ways, the syntax is familiar and the way you structure things is just familiar enough that it’s easy to write it the wrong way. Which is what brought me to my [talk] topic: pattern matching.
When I was first writing Elixir I was writing it like Ruby. And it was “working” but it wasn’t really the way to write it. The concept of immutability and all that, I was ignoring all the stuff you get from that, among other things. One of the things that really helped me turn the corner and see the light was pattern matching as a concept. The minute I wrapped my head around what you get from that, I completely turned the corner. I wanted this everywhere.
TD: Have there been times when you’ve wanted pattern matching in Ruby?
KT: I’m telling you. Literally just yesterday I was working on a project in Ruby-land decoding JWTs, just redoing our authorization system — no big deal — and we got sidetracked during a meeting about how this would be a breeze with pattern matching.
I’m really optimistic about pattern matching. It’s such a strong concept that won me over completely right away. So, I hope I can present it in such a way that folks without a lot of experience in the audience can connect with this and I can get them excited about this language that they may be intimidated by. It’s one of those things that if you only have 20 minutes to talk about something, you can sell it.
TD: One last question, what were you doing before you went to the Flatiron School? What brought you to software development?
KT: It’s not always a linear path, and mine was kind of an unexpected one. I have a background in art history and for years I was working in fine art shipping. Such a niche industry within a niche industry. For about five years I was handling all of the domestic and international exhibition logistics for MOMA and The Met, I was working with the Picasso family, crazy high profile stuff. And it was a very exciting job and also very stressful.
One of the things that made it especially stressful, and I’m still kind of shocked by it, was so much of what we were doing was done on paper. Delivering priceless things to airlines, I’m riding in the truck going into the cargo warehouse, and I’m handing these things over to someone to load into this enormous cargo plane — nothing is being tracked digitally. I am handing sheets of paper that I filled out by hand. It’ll eventually get entered into some systems, but so much of that industry is still very much pen and paper.
It was frustrating because I spent a lot of my job trying to introduce technology, even using a tool as simple as Google Sheets would have helped, but we weren’t really doing much of that.
Toward the tail end of it, when I was about to leave, we started that process. We’d hired a contractor who had helped Christie’s with their systems, and we had three developers working in-house with us. I signed up to be the stakeholder, and I’d sit with the devs and then transitioned into tech support for their team. That was really fun, and as soon as I got a taste of it, I thought it was really cool. I wanted to do what those guys were doing.
So, I looked around. In New York bootcamps are definitely a thing, and I was sold on Flatiron immediately. And I couldn’t be happier with how that worked out.
Big thanks to Kate Travers for taking the time to talk with me. Please don’t forget to get your ticket to the EMPEX conference to be held on May 19th in Manhattan. See you there!
