A. Scherbenina "There'll be place for Ruby in the future"

Speaker at RailsClub 2016 and RailsClub 2017, teamlead at Artec3D
14 November 2017   2178

Anna Scherbenina at RailsClub 2017
Anna Scherbenina at RailsClub 2017

Software developer. Teamlead at Arctec3D, speaker at RailsClub 2016 and 2017.

On the RailsClub 2017, we’ve managed to talk with Anna about her report, her job and future of programming.

Hi! How are you? Tell something about yourself.

Hello, my name is Ann and I'm a programmer.

What is your talk about?

In short, my talk is about the fact that software solutions presented by companies on the market should, in the first place, be stable. Despite the fact that the correct patterns for solving and avoiding serious problems have been known for a long time, many companies, instead of solving their problems, still simply let them go. For example, for the last six months there have been quite a lot of cases, when some companies did not have a backup, and I'm not talking about a well-known company, I'm talking about more local companies, as the Ruby community has a lot of information circulating inside. Therefore, I think we need to stop and think: "What I'm doing right now, this contribution I make, is it really good?" Surely, there are both interesting and not so interesting tasks out there. To my mind, almost every task is interesting, because the developer's responsibility area does not end at the moment when they wrote the code. It ends when this code works stably in production for years, when this code is supported and does not lead to side effects and potential errors.

How’s the conference going?

Quite comfortable. I'm glad that my talk is the last one, because I'm afraid that I will not fit the time limit. I want to say so much! As every speaker does, I believe.

What about the programming world in the future? How do you see it in 10 or 50 years? Will there be a place for Ruby?

To my mind, there will be a place for Ruby. It is a language that actively evolves and follows trends. Like all languages, Ruby learns from the experience of other languages. When a new technology appears, some patterns of behavior that turn out to be successful in one language, affect the other ones. You don’t need reinvent the wheel, when for some specific problems there are already existing good solutions. Same thing with Ruby: I think that concurrency in Ruby is the cornerstone of the next few years, and, I suppose, it will be implemented under the influence of the experience of already existing solutions. I'm not saying that we need to borrow them, but quite a lot of good solutions are already out there, so this experience will certainly not be left without attention.

In your opinion, what are the hypest things in the technology world right now?

As far as I remember, the Guilds were the latest theme that caused a lot of discussion.

Nowadays, the job of the coder is becoming more and more popular. There are plenty of coders out there. What is your advice to stand out from the crowd?

Probably, my answer is unpopular, but I would advise to work very hard. It is necessary to work hard on yourself, as well as work for the companies, as the first "living" experience practically does not come without setting tasks from the outside. You also need to gain knowledge, to read a lot, to go to conferences. On top of that, it is necessary to communicate with other developers and to be in the same information field with them. Try to read the blog posts, including ones from those people talking here today.

Do you need to read about the code or the code itself? What is more important: theory or practice?

I think the theory is more important. in the recruitment process, several years ago, there were a lot of candidates with good local practical knowledge, the guys were smart and talented. Still, there was no basic theory knowledge at all. I think it's too bad when the developer knows only what he has already done.

Talking about feedback, a lot of people do their job and get a great satisfaction from it, e.g. building a useful thing, such as an aircraft or a ship,  that serves people and they thank you. What do you get this feeling from?

Well, I work for a company that makes the best handheld 3D scanners in the world. To do something that is the best in the world, you need to make efforts, you need to implement something new, to be unique. I am glad that I am a part of this process. In this company, my career has developed. Moreover, I like working with external deadlines. When the deadline is caused by some external factors, you need to concentrate and focus. Most of all I’m fascinated by the amount of work that is done in such a short period of time.

It is believed, that a person of each profession has its own professional nightmares connected to their job. Do you have yours?

Oh, sure I’m in my bed, sleeping from Saturday to Sunday, and they call me and say that there is a problem with one of our projects. If only it was a dream! [laughing]

Thank you for joining us, it’s been a pleasure to talk to you!

Thanks for having me!


G. Chan: "Ruby Ecosystem Has Stabilized & Matured"

Interview with Godfrey Chan, Rails core team alumni, developer at Tilde Inc. and speaker at RubyRussia 2018
06 September 2018   3173

Godfrey Chan is a Rails core team alumni. He currently works at Tilde as an in-house Canadian, splitting his time between building Skylight, Ember.js and evolving the JavaScript language at TC39. In his previous life, he was also an award-winning WordPress plugin author. He will be one of the speakers at Ruby Russia 2018 conference, which will take place in Moscow on 6th of October.

Godfrey Chan
Godfrey Chan

Meeting the speakers before the Rails conf has already become a good tradition. This year the conference name has changed, from now on it is called RubyRussia. As always we are preparing the interviews with the speakers to give our attendants the idea who the speakers are and what to expect from the event.

That's very cool. I'm very happy to be here.

I've prepared some questions as I’d like to know more about your speech and your presentation. Let’s get started!

I don't want to give too much away. The title of my speech is ‘Dropping down to the metal’. It's basically about writing some weird code in Ruby using metaprogramming to make something that looks like JavaScript run in Ruby. Of сourse, we won’t be able to write a full-fledged JavaScript parser and executive environment, but you will see some tricks (as in magic tricks/illusions) that makes a block of JavaScript-like code run in Ruby, using the native Ruby runtime. It's fun to do that, at least for me it was fun writing that. It is also the same techniques you use to write something like rspec, rake or other DSLs in Ruby. You will also get a good understanding on how Ruby parses your code and also how Ruby runs your code, and what hooks are available. I think it will be pretty entertaining but also it can teach you something useful about metaprogramming and Ruby.

Ok, so, there's gonna be some practical advice, right?

I don't know if I would spell them out explicitly in the talk, but I do believe you will walk away with something useful in that half an hour.

Alright, great! I think it will be interesting both for the experienced Ruby programmers and the newcomers.

I certainly hope it will. I will try hard to do that.

Great! By the way, yesterday I’ve read your article on Medium. It is from your keynotes, rethinking computer science education. It was very interesting, and I basically agree with your thoughts about the difference between the classic university education and the modern coding courses. So.. why did you decide to become a programmer?

I was in a fortunate situation, I didn't really decide to become one, it was always a kind of interest, a hobby for me. I really liked tinkering with computer stuff at young age and, at some point, there were only so much you can mess around with by deleting random system files and modifying the Windows registry. At some point, the natural progression was to realize that I wanted to teach the computer to do more things for me. The way things  started was when I took an after-school class for making websites in elementary school. That was pretty cool, you could create things on the computer. But soon I realized that it was pretty limited. You could create a choose-your-own-adventure game with hyperlinks and stuff, but I wanted to do something more interesting. My teacher gave me a PHP book. I read the whole book and, wow, suddenly that opened up a whole new world of possibilities on top of what you can do with just HTML and CSS. That was pretty cool and from there I started reading more and more books as a teenager. Next language I learned was Java. Eventually, I saw Rails in a Linux magazine. I thought it would be cool to learn it. It kind of snowballed from there.

So, you’ve moved to Ruby, right?

I discovered Rails around the time I started my Computer Science degree in college,  so at the same time I was also doing Java, C++, Haskell, etc. I was exploring a lot of languages. I never got to do any Ruby at school and I really enjoyed my time writing Ruby, so I kept trying to sneak Ruby into the more open-ended assignments at school, especially in the upper-division classes where they don’t really care what languages you choose. So yea, those were my chances to write Ruby during school, other than my side projects. Since I didn’t have much opportunities to do that at school, as soon as I finished school I decided to look for jobs where I could do more Ruby. It was a good time for that anyway because Rails was at its peak. A lot of startups were using Ruby and Rails, so it wasn’t difficult to align my interest with work.

Do you use Ruby as your main language now? Or do you work with other languages on a daily basis?

With my current job at Tilde I actually don’t write as much Ruby as I used to. I would say my job is a mix of JavaScript/TypeScript, Rust, Ruby and occasionally some Java, but all the work I am doing is related to Ruby in some ways.

For example, our main product at Tilde is Skylight. Not all components in Skylight are written in Ruby. For example, the frontend is written in JavaScript with Ember, the backend is written in Rails but the data-processing pipeline is Java and Rust. Even though not all the code I write is in Ruby per-se, Skylight itself is intrinsically about Ruby, since it is a performance monitoring tool for Rails apps. So in that sense, all the work I'm doing are still related to Ruby.

I see. Actually, I've registered in Skylight a few days ago for one of my projects, so I am testing it now. It looks interesting and it’s quite clear from the beginning. I haven’t digged too much in, I hope to do it next week. I hope it will help me to fix some issues.

If you have any feedback, it would be great to hear it!

One of the most interesting questions is how you would compare Ruby with the other languages. For example with Rust. Ruby is very expressive. It is created to make the program readable. If you compare it with Python or with C++, C# or Java, they’re not so easily readable as Ruby, in my opinion. What do you think?

I would agree with that. There are two ways I “learn” new languages. The first way is pretty superficial, where I look at the language, learn the syntax, play with the examples and then I pretty much forget about it. That’s what I did with Go. It took a weekend and then I spent another week or two writing different projects. But it never stuck, I didn’t have many reasons to keep programming in Go. I was just learning it for curiosity sake.

On the other hand there are those languages that stuck around for me, like JavaScript/TypeScript, Rust and Ruby. It's really about unlocking some possibilities that I didn't have before and that’s the intrinsically exciting and motivating thing for me.
For example, when I’ve first found Ruby, the thing that really attracted me was the expressiveness. No other languages gave me the possibility to do such crazy things as method_missing. I think that metaprogramming, expressiveness and code readability are really the key things that drew me to the language. I wish that other languages that I'm using are more like that.

At the same time, the other languages I use added some new possibilities for me that were impossible with Ruby. JavaScript is a pretty obvious example. I did not intrinsically like JavaScript that much, it’s not like Ruby where I fell in love at first sight. JavaScript came on my radar by necessity, because I needed to write code that runs in the browser. For better or worse, JavaScript is the language you have to use for browser programming. If you want to write an interactive browser app like Skylight, and that was something I was interested in doing at the time, then JavaScript is really the only way.

So my focus with JavaScript is to bring some of the ideas I liked in Ruby into this environment which is why I ended up working on things like Ember. That, in turns, brought me to TypeScript, because when you are writing a huge framework like Ember in JavaScript, having types and a compiler to check your mistakes actually helps a lot. That's what JavaScript and TypeScript unlocked for me.

Finally, the things Rust unlocked for me were quite similar to TypeScript. It is very satisfying to be able to compile the whole program and have the compiler assure you that things are correct. That’s fascinating for me. I’ve used other compiled languages before, like Java and C. You have to go through the process of compiling your code but you don’t really get much out of it, because the type system in those languages are just not very good at catching mistakes. But in Rust, the compiler can guarantee your program is memory-safe and you can be sure that you won’t get a segfault in runtime, and that’s a powerful thing. One of the trickiest things about programming in C is this kind of memory-safety issues, which is very difficult to avoid. The main thing Rust unlocked for me was the ability to do low-level programming without having to worry a lot about memory-safety.

Interestingly, the way I got into Rust was actually related to Ruby. At the time I just started working at Tilde and I knew the Skylight gem was written in Rust, so I was thinking that it would be cool for me to learn how to write a native extension for Ruby. I wanted to learn Rust and not have to worry about crushing peoples’ Ruby processes because I didn’t dereference a pointer correctly in C. So the main purpose for me to learn Rust was actually to write native extensions for Ruby.

That has been a main line of work I’m doing with Rust. Just this morning I was working on a project with Peter Wagenet, who works at Tilde and Sean Griffin from Shopify and the Rails team. Sean is working on a drop-in replacement for Active Record that’s written in Rust to speed up some of the slower parts. So just before this interview, I was working a Rust project called libcruby-sys that allows you to write those kind of Ruby native extensions in Rust.

So, in the end, they are all connected. At the end of the day, the languages I learn and program in are just tools that allowed and enabled me to build things I wanted at the time.

It is very interesting. Especially because it seems that the ActiveRecord will be much faster in the future! As far as I understand, the idea behind the new ActiveRecord is the same. I mean it will still be an ActiveRecord. Not something like a Data Mapper.

To be clear, Active Record, the Ruby implementation, is not going anywhere. That’s still the main implementation that’s being actively developed. That’s still useful. If you are using JRuby that’s still the way to go. What Sean implemented is 100% API-compatible;  it’s just re-implementing the guts in Rust, which does the same things faster internally but keeping the same API from the end user’s perspective.

This is connected with a project I’ve been working on for the last couple of years. It is called Helix and it traces back to my journey of learning Rust to build Ruby native extensions when I first joined Tilde. It was really difficult to get started, and there were a lot of safety issues to consider. Helix allows you to just focus on writing your Rust code and Helix will take care of compiling that into a Ruby extension for you.

You’ve probably used json gem in Ruby. There are actually two different implementations of this gem. There’s the pure Ruby implementation and the C extension version which implements exactly the same API. You may have not noticed this, but when you say require json in your code, you’re probably using the C extension version, unless you are on an unsupported platform, in which case the pure Ruby implementation is used. But again, the way you use its API is exactly the same. The only difference is that the internals for one of them is implemented in C, so it runs faster. You get the higher performance. But otherwise, as a user, you don’t really notice the difference. That’s the goal of all these projects – to be able to use the same Ruby we all love to write on, but get the performance benefits of native code when you need it.

It sounds great! Ruby’s going to be faster. But I think that the speed of execution is not too important for the developers who use Ruby. But although everybody tells that it doesn't matter too much, they will be happy to have the better performance of their programs.

I totally agree with you for the most part. You don’t care and you shouldn’t care. My angle on performance is enabling use cases which were not possible before. Like I said, I learned JavaScript because I wanted to program the browser and that wasn’t possible without JavaScript. I think the same thing is true for performance. I don't really care that your code runs 20% faster. That’s nice, but that’s not intrinsically what I care about. What I really do care about is if your code now runs 10 times faster, that enables you to build things that were not previously not possible.

For example, if you’re interested in machine learning, that involves a lot of heavy number crunching and you might not be able to implement that in Ruby because Ruby is just too slow. However, if you have a way to easily interface with a machine learning library written in native code, then you are able to explore machine learning in Ruby, because when you make those calls you are actually running native code that is very fast. You can still write the code that orchestrates all the machine learning processes with Ruby, with all of its expressiveness and the RubyGems ecosystem. For me, it's really about enabling things that were not previously possible to do in Ruby before.

That's absolutely true! I’ve been struggling with the issues when Ruby programs worked very slowly many times. So I found myself writing a lot of SQL code to speed them up. I’ve moved some logic to database queries because they work, like, 100 times faster.

Right, I would much rather move the hot code into a native extension than to reimplementing it as a microservice in Go or Haskell. I think that it's good to be able to keep as much of your code as possible in Ruby, only move the performance critical parts somewhere else where you can still easily interface with in Ruby. That’s the beauty of that.

Yes, it should be faster and easier. It should be more productive in terms of business. You do not need to hire programmers with different skills and languages since everything can be written in Ruby. That sounds promising. What do you think about the future of Rails? Every year there’s a lot of rumours about that Rails is dying...

I am probably biased because I work for a company whose main product is a Rails performance monitoring tool. I personally don't think that it is dying, but it's definitely maturing. For a lot of people in the Rails community that’s an unfamiliar thing. A lot of us joined Rails and Ruby community when the Rails was the new hot thing. There were a lot of excitement and innovations going on there. Though, a lot of the “innovations” were just us trying to figure out how to do certain things in Ruby and Rails that were pretty common in other ecosystems. We weren’t able to do it because the ecosystem was so immature at that time.

That was definitely very exciting time to be around. Every monday I would be super looking forward to watching the latest episode of RailsCasts. You learn about a new gem every week. For example, one week there is this new gem for generating PDFs, next week there is yet another new gem for handling file uploads, and then there are even big paradigm shifts like bundler coming into the scene. Those were great innovations and there were a lot of excitement and energy, and a big part of the sense that Rails or Ruby is dying is that we just don’t have a lot of that anymore.

In my opinion, that is because the ecosystem has stabilized and matured. We already did the experiments of having 5 completely different ways of handling file uploads, maybe we just don’t need to do that every week anymore. Emotionally, I definitely miss those times. At the same time, I don't think this is a bad place to be in. It's good to be able to say: ok, we have been on those journey, tried different approaches, learned the lessons. And now we’ve chosen the best option that everyone uses. I think that’s great.

A part of me definitely misses that energy and excitement and constant feeling of change and progress at that time in the Ruby community. Personally, I’m finding a lot of that in the Rust community. That’s where I'm getting the excitement. I agree that the Ruby community is dying in terms of excitement. But in terms of productivity and real work - that’s not a bad thing at all. I understand that for a person who likes to be learning new things constantly there is a need for that. As for me, I am doing exploratory work in other ecosystems instead of Ruby. The community is maturing and things are not changing so much anymore. But personally, I’m ok with that.

I think it's a natural way of things and Rails is still great. It’s very useful for real business that develops commercial applications. Actually, one thing about Rails I like  is that you still can use different approaches if you want to. For example, you can use trailblazer or dry-rb gems. You can use different kinds of abstractions in your program but still stick with Rails. That’s the thing I like about it.

I definitely agree with you. I think that the whole maturity thing comes for the whole ecosystem. At the time that we would call “the peak” of Rails, a lot of users were starting to build new startups and new projects. No one really cared about stability. That’s when you get constant influx of excitement and energy. Now a lot of those companies have turned into big companies like Github or Shopify, and now we care about stability a lot. That’s true for a lot of us in the community.

As a community, we just collectively decided to favor stability over experimentation. From the language’s perspective, there’s still just as much space for experimentation, because Ruby is still the same language. The reason that Ruby was great for experimentation back then is still true now. However, the community have decided to focus more around building things that work for Rails, because Rails is heavily used already. When you write a gem, you would probably support a few Rails versions, because there are a lot of companies which use them. As a result Rails itself also becomes more conscious about not breaking its API unnecessarily. Personally I'm happy to be a part of that process.

That’s very nice in terms of business to have stability rather than experimentation. Especially, for high loaded programs. The stability of interfaces and frameworks is very important. I remember the times when it was extremely hard to move from one version of Rails to another. For example, it was like that with an issue with encoding incompatible exceptions.

I think trailblazer is a good case study for the current state of the community and ecosystem. On one hand, the fact that it exists is pretty good evidence that there’s still a lot of space for experimentation in the Ruby community. However, I do think that if trailblazer came out 5 years ago, it could have been much more popular, because now we’ve already built a much bigger ecosystem around Rails with a lot of gems.

At the end of the day, you care more about what you can do with a programming stack. What you need to do is to write that app that knows how to do invoicing, PDFs, websocket. A lot of people in that part of ecosystem just prefer to work with something that is maximally compatible and on the same path as other people, so you can share gems and conventions, find answers on StackOverflow, etc.

Maybe in that sense, a part of the Ruby community has died. The part of the ecosystem from 5-10 years ago where you are building new stuff all the time and not have to worry too much about compatibility, and just wanted to use the latest and greatest gems because you did not have too much baggage. Now as a community, we just have a lot more baggage. That part of the ecosystem that likes a lot of experimentation and innovation may have moved to other communities.

I think it's ok.

I'm ok with that too. It’s like growing old, it's like a different stage of life.

What do you think about static typing in Ruby? Like a possibility to gain advantages of that approach in the Ruby?

I'm very excited about that because I have experienced the benefits in the JavaScript ecosystem with TypeScript. For those who are not familiar with JavaScript it is very much like Ruby. It is dynamically and loosely typed so you have a lot of flexibility but also a lot of runtime errors. TypeScript is an attempt to give JavaScript a type system in a way that basically just exists as a layer on the top. So it’s basically a superset of JavaScript syntax. When you compile your code, you compiler checks the types to make sure that everything is correct, then it just erases all the type. When you delete all the types from TypeScript files, you’re back to pure JavaScript.

I think that approach works surprisingly well with JavaScript. Now people have built a whole ecosystem around TypeScript. I would love to see the same story happen for Ruby. The genius of that is because TypeScript is a superset of JavaScript syntax, a layer on top of JavaScript, it didn’t take anything away from the JavaScript ecosystem. If you are a JS programmer, you can just interact with untyped version of the code. People who work on projects that will benefit from having the type can look at the typed version. But ultimately,  everyone will be able to call the libraries in the same way. Even if you’re using JavaScript you get some nice things like autocompletion because someone did the work to produce the typings for those JavaScript files. So in my opinion, the whole TypeScript thing is a big win for everyone in the JavaScript community whether you use it directly or not.

I think there is probably a way to make it happen in Ruby too, where no one is forced to do anything. The people who are enthusiastic about types will do the work and everyone will benefit from it, whether it is about getting better autocompletion in the editor or just knowing that your framework like Rails is less buggy because internally it uses types, which helps you catch bugs in the compiler rather than at runtime. I would very much like to see that layering made possible in Ruby.

I completely agree. I think It will be a big step to the stability of applications. Actually, it will be easier for juniors. They will have less chance to make errors. Now we need to be very careful about the variable naming to provide the idea of what is stored inside the variable. When I write a code I have to be very expressive about what type of a value is expected in this or that variable to give an idea for the next person who will read my code. If we’ll have the types, it will be easier

I think that for people who like types, they are basically executable documentation. If it’s done correctly, TypeScript does a very good job of that. It reads naturally as a self-documenting code. However, even if you don't want to look at the type code, you can look at JavaScript version of the same code which is again, in the case of TypeScript, exactly the same code, just without the types. But thanks to someone who actually did the work and put annotations there, you can actually use those annotations and generate documentation for the untyped code as well.

So, I think that the layering there is really important. Some people are very enthusiastic about types and some strongly dislike them. The TypeScript story shows that there’s really a way for those different approaches to co-exist and benefit from each other. I'm slightly nervous about  the direction that the types in Ruby is going. I personally would rather find a way where we can layer types on top on Ruby and let two opinions co-exist with each other rather than making a lot of compromises.

We had Matz couple of years ago at RailsClub in Moscow and we obviously talked with him about the typization. But I had a feeling that he was not too optimistic about that. But certainly his mind could change some day.

I think if Matz dislike types, I would much rather find a way that Matz would never have to see the types, rather than trying to writing them in a way that he would tolerate, like in doc comments. If that makes sense.

I could be wrong, but I think that the idea of Matz is that it is just easier to program without types than with them.

That’s totally true for some people, and I think that’s even true for me most of the time. But in some types of the programs, such as a big framework like Rails, at some point you cross the line. Without types, you have to keep that information in your head or in documentation. At some point, that’s too lousy for big codebase like Rails. I definitely think even for JavaScript there are code bases where the benefits of types are not worth it. On the other hand, there’re also big code bases like Ember that really benefited from having TypeScript. As I have already said, the beauty of the layering is that in the end of the day you are all still writing JavaScript, you can choose one or another without affecting the other half of the community that doesn’t like types a lot. At least that’s my experience.

Thank you. Let’s change the topic a bit. It is just a month until the RubyRussia conference starts. So what do you expect from coming to Russia? Have you ever been here before?

I haven’t been to Russia and, honestly, I have no idea what to expect. But I think it's gonna be really fun. I'm really excited to visit Russia for the first time. I'm sure it's gonna be good. What should I expect? Is there anything I should have prepared?

Haha, at least, we will have a great afterparty! Everybody have really enjoyed it the last year. There will be some activities during the day, an excursion and so on. You will have a lot of fun. The people are friendly here, and I’m sure we will have a lot of interesting topics to discuss.

I definitely look forward to all that. I'm very thankful to you for inviting me to your conference. It wasn't really on my mind to visit Russia. Now I’ve realized that I should have done it earlier. I think I will have great time! I am looking forward to it.

You're welcome!  What advice can you give for newbies? What will be the mainstream in the programming in the next 5 years?

This topic is really huge and requires much more time to discuss. But I have 2 advices.

First, instead of chasing after the “mainstream”, chase what interests you. Maybe I was just lucky, but that worked very well for me. When I was into Ruby I started looking for a job that allowed me to do a lot of Ruby. Because I was really motivated to learn more about Ruby, I eventually learned to make open source contributions, and that helped my career after. That’s the first advice. Chase your interest. If you are motivated, the chances that you will do a good job is much higher.

The other thing is basically what I said in the medium article you mentioned. It is to be more conscious about how you learn, because no matter what you do, learning is really the key part of the job. I recommend finding good ways to learn beyond what you already know, going into territories that you’re not familiar with, and figuring out how to build and correct mental models for different concepts. Being conscious of the layers you are building on is really one of the key skills you should have in terms of navigating the programming career.

I think that the higher education is very important even now. It gives people deep understanding and the basics which haven’t changed too much. The basic principles of how the computer or database works are not changing much. There are a lot of things happening on higher levels. But the basics are still the same for decades. I think the higher education is valuable.

I would agree that university still has a place and is still very valuable. I personally benefited a lot from it. Though I do not like the term ‘basics’. There is always something more ‘basic’ that you can learn. The key thing is to realize that, that there’re always more things sitting underneath what you know, waiting to be discovered. If you do learn it, it will probably help you in surprising ways.

For example I've learned a lot of operation system, compilers and such at university, and I did not use it too much since I graduated because I was working primarily with Ruby. Until recently, when I had to remember all of that, because I was working on a toolchain that lets you compile Rust code into Ruby native extensions. That forced me to re-learn those things on the spot. Even though I supposedly learned those things in school, I already forgot all the details. However, I roughly remembered the key concepts and knew what to google. And what was more important, is the fact that I already learned this stuff in school gave me the confidence that the topic is approachable and learnable. That part is super valuable. It gives me a motivation that I need to solve the problem.

In your opinion, is it a good idea to do more mentoring while you are a programmer?

That’s the topic that I'm quite enthusiastic about. Teaching and mentoring is intrinsic part of any organization. In programming, it’s especially important because there’s always so much to learn. It is a part of my job now to learn how to be more effective at teaching and mentoring. Like everyone else I’m still learning to do that myself. It’s important to get it right. I appreciate it. The culture of learning on the job is very important.

At my company we try to make it easy for people to learn things they are interested in. For example, I'm currently mentoring some people at the work to help them to learn Rust, in the context of what we do as a company. We want to move more backend stuff from Java into Rust. It is an important goal for the company to have more people who are skilled with Rust. It is an investment; we are definitely making an effort to do it. When a person in a company is interested in Rust, we try to figure out how to give them the resources and time that is needed to learn those kind of things.

I think mentoring is a good way to learn things yourself. It is a great instrument for learning. When you teach someone to do something you learn how to do it much better.

I do weekly mentoring sessions on Rust, and every time I realize how much I don't know about Rust. When I try to explain things I thought I knew, it always uncover parts that I don’t know anything about. I spend a lot of time after each session to learn stuff I thought I already knew. That definitely enhances the experience.

By the way, I would like to say thank you for the ‘This Week in Rails’ newsletter email.

Thanks! I don't have time to write that anymore, so I can’t take credit for it, but the people who write it nowadays do a very good job. As a reader of the newsletter now, I appreciate their work a lot.

I’ve been receiving it for the past 2 years at least.

It was a lot of fun! I'm glad I've started this project.

It is very interesting to read on Monday what has happened last week in the Rails community! I think it's time to finish. Hope to talk with you personally at the conference. We’ll definitely have time at the after party.

Looking for it as well!

It was very interesting to talk to you! Thank you for your time! Have a nice day! See you in Moscow at RubyRussia!

Meet Godfrey and ask a question in person at Ruby Russia 2018!

Questions were asked by Dmitry Matveyev, project manager and developer from Evrone.