Katrina Owen: Exercism, and her journey to RubyC-2019

Intro

RubyC-2019 counts itself very lucky for the chance to welcome Katrina Owen, a very talented US programmer, polyglot developer, Ruby Hero award winner, author of ‘99 bottles’, who at the moment works at GitHub as an Ecosystem Engineer, focusing on low-level plumbing of REST APIs.

Katrina is famous for creating and mentoring Exercism, a programming exercise platform with thousands of contributors that is geared to helping programmers at all levels improve their programming skills through practice and mentorship. Exercism provides thousands of exercises spread across 48 language tracks including C#, C++, CoffeeScript, Elm, Erlang, F#, Go, Java, JavaScript, Kotlin, Objective-C, PHP, Python, Ruby, Rust, Scala, Swift and Delphi. It is entirely open source that relies on the contributions. As of August 2018, Exercism has 1,700 contributors and 700 mentors.

Being extremely excited about having Katrina as an upcoming speaker (something we have trying to arrange for 5 years) we wanted to properly introduce her to local communities. Thanks to Alexey Vasyliev, who has arranged this podcast and discussed Katrina’s projects as well as the topic she plans to present in the RubyC-2019. Here we present a reading copy of the interview.

Interview Script

Alexey Vasyliev: Welcome Katrina! We are happy to have you here as we want to learn more about your projects and your role in the RubyC 2019 conference. To get started, tell us about your open source project: Exercism.

 

Katrina Owen: Absolutely. The website is Exercism.io and it is essentially a platform to practice programming. Mostly, the people who use it are people who are already programmers that want to ramp up in a new programming language. For example, if you are currently using Java at work but you need to start using Python or Haskell for a project, you can go to Exercism.io to get lots of little exercises for the programming language. Also, you gain feedback on the solutions you write so you can learn to quickly write code that looks idiomatic and conventional for that specific target language.

 

Alexey: My original assumption about Exercism was that it was exclusively for people who had no experience in programming.

 

Katrina: It’s designed for everybody and I invite everyone to try it, regardless of having programming experience or not. At the moment, the platform has nearly 50 programming languages to learn and play with.

 

Alexey: That’s a very comprehensive portfolio of programming languages. Would you consider Exercism as a team effort?

 

Katrina: It was definitely a team effort. It was important for me to have a core team that supported and maintained as many languages as possible to provide an all-inclusive solution. The core team, which includes user experience designers, developers, and more, directs the entire Exercism project from various parts of the world, from the United Kingdom to the Philippines. Additionally, every single language and collection of exercises in a programming language has its own maintenance team. Right now, there are about 100 people maintaining the individual programming languages and overall I estimate there are about 1500 people who contributed to the ecosystem of Exercism throughout the year.

 

Alexey: Exercism is definitely a remarkable project. Now I’d like to ask about another highlight, which is the upcoming conference. Tell us a little bit more about the topics you plan to address.

 

Katrina: The main topic is about refactoring. I am very passionate about this topic and I almost always talk about it. The big idea in this year’s talk at RubyC is to discuss how to refactor safely. As programmers, we often have a vision in our minds of how the code can be better - we think we know the end goal, which is why we tend to go straight for it by taking really, really big steps. This, more likely than not, gets us in big trouble in a number of ways. 

The first way is if the test suite fails. If it fails, the tests are not providing feedback which leads us to make changes in the dark, not knowing if they are working. You can’t deploy broken code, which means you’re going to be in a long-lived branch with very big changes and tons of merge conflicts.

The second way that leads to trouble is when you need to pause refactoring and leave halfway when everything is broken. All the knowledge about refactoring is in your head and if you leave, you are going to lose all that context, making it hard to reload back into your brain to pick up where you left off.

The other way to get in trouble is when you have a broken test suite and you are frantically changing things to get them to work again under a new vision, making lots of unnecessary changes along the way. By the time you actually get everything working, you will have a lot of changes that are balancing each other out, much like a house of cards - making the structure brittle. 

Lastly, if you get a really big change and a really big refactoring, it’s really hard to perform a comprehensive code review. If the change is big, the code review is complex. This elongates the process for you to get feedback on the big change and things are going to diverge from the master branch even further. Every different type of change requires asking a different question from the reviewer. 

 

Alexey: Very interesting topic and one that I definitely look forward to - it is already pretty clear how amazingly knowledgeable and experienced you are about refactoring. I hope the majority will find it useful. 

Next, I’d like to ask if you have any plans for a new book since the one you have previously co-authored with Sandi Metz called “99 Bottles of OOP” was quite impressive? Perhaps one about refactoring?

 

Katrina: I don’t have plans for a future book. I would love to write another one eventually but it takes a lot of time and a lot of effort. In many ways, the “99 Bottles of OOP” book is about refactoring but it would be fun to write a book entirely about refactoring in big projects.

 

Alexey: Hopefully that book becomes a reality soon. From what I know, the Exercism project started in 2013 and now, after nearly 6 years of being active, what can you tell us about your take on managing open source projects?

 

Katrina: I learned a tremendous amount of things and one of the most important lessons is that it’s essential to know what problem you are actually solving. If you don’t have a very clear and crisp idea in your head of the problem you are solving, people will make contributions and it’s going to be very hard to decide whether or not to accept that contribution. It takes an enormous amount of energy and cognitive resources to make that yes or no decision, and for every contribution, you would have to go through the same process. If you don’t have a clear idea, you end up accepting things that don’t actually make the project better and as soon as you accept something, it means you need to maintain it forever. This makes it very hard to say no as the pressure is to always say yes, but by having a clear definition, you can have a written-down policy of what fits and what doesn’t, making it easier to accept or reject contributions, without people feeling rejected.

 

Alexey: From your perspective, what are the most important skills to have to work alone and to work within a team?

 

Katrina: I think the answer, frustratingly enough, is that it depends. It depends on what type of software you are writing, what type of team you are working with, but for me, the most important skill personally and individually is troubleshooting - really understanding how to ask a better question, how to define a hypothesis, how to design an experiment that is going to eliminate options or how to make a minimal reproduction case. Troubleshooting helps clarify assumptions and it also helps to communicate better with your coworkers. As part of a team, the most important things I learned have to do with communication and the ability to accept and solicit feedback - understand how to disagree with someone in a productive way. It’s very common in open source projects to have disagreements, which can lead to a blow out rather than a collaborative space, which is why it’s important to disagree in productive ways.

 

Alexey: What are the most expensive technical lessons you have learned in your years of experience?

 

Katrina: I think it goes back to not knowing what problem I’m solving. For a long time, I didn’t know what problem I was solving with Exercism. I hired several people to try and solve problems within Exercism, but because I didn’t know exactly what the problem was, all the money invested in the people I hired was completely wasted.

 

Alexey: Of course, it can waste both time and money. Now, for the next question: do you have a master list of books that you would recommend for software developers?

 

Katrina: I do - this is kind of my favorite question because I spend most of my spare time reading. None of the books that I typically recommend are technical as most are about improving other aspects of your skillset. In terms of solving the right problem and making better decisions, these are the 3 books I recommend: 
“Good Strategy, Bad Strategy” This is not a programming book, instead it is a business strategy book. The author goes in-depth about defining what a strategy actually is.
“Decisive” It is about strategies or tactics to make better decisions - how to evaluate options, how to create more options to end up with the most useful decision.
“A more beautiful question” It’s about being able to use the process of asking questions to generate more options and to re-evaluate your assumptions.

 

Alexey: Thank you for this list and thank you very much for your time. I hope to see you soon. To wrap up, do you have one final piece of advice for our audience?

 

Katrina: As a final piece of advice, I would say: Take smaller steps. And I very much look forward to meeting and talk to everyone at RubyC!

 

Alexey: Straightforward and full of wisdom. Thank you, Katrina.

 

***

If you have enjoyed Katrina’s answers as much as we did, don't miss a chance to meet her in person on RubyC-2019, which takes place on 14-15th September in Kyiv. Catch your early birds ticket here.