Interview with Jonan Scheffler @RubyKaigi 18′

  • Post author:
  • Post last modified:2020-11-25
  • Post category:Interview
  • Reading time:13 mins read

This past May the Sider team attended RubyKaigi 2018 in the beautiful city of Sendai.

We were fortunate to be able to interview a fellow developer and Developer Advocate at Heroku, Jonan Scheffler.

Jonan also goes by Deka Gaijin (“giant foreigner” in Japanese) occasionally, in particular when he hosts quiz shows that take place randomly between the sessions at RubyKaigi. Jonan spoke frankly with us about several topics, ranging from his new project at this year’s RubyKaigi and his work at Heroku to Japanese hot springs. Jonan majored in Japanese culture in college, so he spoke Japanese in this interview. Sider has translated the original interview and edited this English version. Enjoy!

Left: Soutato Matsumoto, Sider CTO. Right: Jonan Scheffler

From Poker Dealer to Programmer

Soutaro: I know RubyKaigi attendees know you as “the big white guy you can meet at RubyKaigi,” but please introduce yourself to people who might not know you.

Jonan: I am flattered to hear everybody knows about me. I started attending RubyKaigi seven years ago, so I’ve been lucky to make some friends. When I first attended, I had just started developing software. Before software, I had lots of different jobs. Directly before becoming a software developer, I was actually a poker dealer.

Soutaro: What?

Jonan: Yeah, I used to be a poker dealer at a casino. I was also a car salesman and a front desk agent at a hotel; lots of different jobs…

I became a software developer because I attended a coding school, where I spent six months learning to write software in the United States. The school was called Hungry Academy. There weren’t very many coding schools at the time, so I was very fortunate to be accepted.

I actually attended a RubyKaigi before I got into coding school. I had very little knowledge of software development, but I came to Japan to attend RubyKaigi anyway.

Soutaro: Were you learning software development as a hobby at the time? Or did you already study coding in college?

Jonan: I studied Java in college. Most of my friends at the time coded Java. They worked at game design companies, and they seemed very unhappy at work, so I decided not to move on with coding. In college, I was initially trying to earn two bachelor’s degrees at the same time: Computer Science and Japanese Culture & History. I studied Japanese grammar and linguistics as well, but I mostly focused on the cultural aspects of Japan, so I still struggle reading Chinese characters.

After graduating from High School, I lived in Japan as a Rotary Youth Exchange student for a year. When I got to University I tested out of the first 2 years of Japanese classes, so they placed me in the 3rd year classes. By the time I was a Junior I was taking graduate level Japanese classes, which unfortunately conflicted with my 3rd year Computer Science courses. I had to pick one if I wanted to graduate on time, so I chose Japanese Culture & History.

After college, I started working as a graphic designer, using Photoshop. The company where I worked was also using Ruby and I loved the language, so I decided to go to a coding school about seven years ago. That’s how I started my career as a software developer.

RubyKaigi and Japan

Soutaro: So you started coming to RubyKaigi seven years ago. You’ve been attending RubyKaigi ever since?

Jonan: Yes. The first time was the so-called Final RubyKaigi. I think it was 2011. The next year, there was no RubyKaigi, so I didn’t come to Japan. After that, I’ve been attending every one of them. I went to Tsukiji in Tokyo, Hiroshima, Kyoto, and here in Sendai. I think there was another one in Tokyo, so I’ve been to six of them total I think.

Soutaro: It’s impressive that you came to every RubyKaigi. So you visit Japan pretty often then?

Jonan: I do, I have many friends in Japan. I often go to Aomori where I studied as an exchange student.

That’s why I enjoy hot springs and visiting the countryside like Aomori. I really recommend trying out the hot springs in Japan. If you’re from another country and attending RubyKaigi, you MUST take a dip in the hot springs. If you’re too shy to go in a shared public bath, you can try one of the family private baths that are called “kazokuburo.” If your hotel has that kind of facility, you can just reserve it and enjoy the hot spring in privacy. If you’re comfortable with the idea though, I highly encourage people to try the shared bath and experience this very interesting part of Japanese culture.

Soutaro: So you recommend hot springs in Japan the most?

Jonan: Yes, hot springs and sushi. You obviously have the best sushi.

Sushi in the States is something similar to sushi from Japanese convenience stores. Of course, there are fantastic sushi restaurants in the States, but most of them use frozen fish. Uni (sea urchin) is the worst when it is frozen and defrosted. Uni tastes the best when it is freshly caught that day. I want people to try out uni in Japan. I think there are quite a few people who had uni in the States and didn’t really enjoy it. I want them to try uni again in Japan. I want people to explore Japanese cuisine and expand their palates.

Soutaro: Thank you for the suggestions. It will be great if people can enjoy Japan like that when attending RubyKaigi. How are you enjoying RubyKaigi this year? You’re playing Magic?

Jonan: Yes! I’m hosting Magic: The Gathering tournament, the First Annual International Ruby Magic Championship.

We’ve played Magic a few times at different conferences. Playing it with a bunch of people is a lot of fun; it’s a great way to make friends. This is the first time we’ve held this competition at RubyKaigi, but I would love to do it again next year.

We’re also live-streaming pair programming sessions. It’s so much fun. I think displaying how you code in front of people is very helpful for beginners. People who just started programming are usually embarrassed to show their code, and when they look at the completed code of experienced programmers, they think “I’ll never be able to write code like that.” For example, when you publish a gem, beginners see that code and start to worry about their own skill level.

In actuality, you almost certainly made many mistakes while you were developing that gem. I want to show those mistakes to newcomers. I want people to feel more comfortable making mistakes by showing them that we all make mistakes. That’s a large part of my motivation for live-streaming these pair programming exercises.

Code Review and Automation

Soutaro: It is intriguing to let beginner coders watch how good programmers code and make mistakes by showing the actual process of coding.

Jonan: Yes, it is. It’s not only for experienced coders though. All skill levels are welcome. I do this to have fun with everyone.

Soutaro: I’m assuming you got this idea while you were reviewing code and training at work. Where did you get this idea?

Jonan: There are two Developer Advocates at Heroku, including me. Our main tasks are going to conferences and writing blog posts, so we already understand how to reach developers that way. We’re obviously not perfect, but we have a pretty good idea of how to approach those methods, so we wanted to explore alternatives.

While searching for new ways to communicate with developers we found Twitch, a website where you can live-stream and viewers can chat with you live. Most of the live-streaming videos are about video games, but they recently created a category for programming. So, we decided to try out the platform.

In addition to the pairing sessions, we’re planning on using the platform to produce internal-only videos. We’re going to be interviewing developers within the company, and pairing with them on their projects, so we can all learn more about what the various teams do, and especially how they work with their code. Next week we’re going to have our annual internal engineering conference, and I’m hoping to have a chance to pair with some of my coworkers in person. I rarely see them, because we’re almost entirely remote workers…

Soutaro: How do you review code at Heroku? I think it’s pretty vital.

Jonan: Of course, I agree. At large companies, we’re required to peer review code to comply with standards and regulations like PCI Compliance (Payment Card Industry Security Standard) and HIPAA Compliance (Health Insurance Portability and Accountability Act). Heroku recently became one of only a few companies that are able to offer HIPAA compliant cloud services. Even before we released HIPAA compliance, we often used code review internally to improve the quality of our code and share responsibility for the codebase.

I was on the internal tools team when I first joined Heroku, a team that builds systems to help Heroku’s engineering team ship code, and we used several tools to improve our code quality. Gems like Rubocop along with CI and code quality analyzers, and tools like flay to detect complicated or unnecessary code. We were able to identify code that changed often; code with a lot of churn. Those are the places you want to pay attention to in your application.

So that’s how we review code at Heroku.

Soutaro: So that’s the story at Heroku, but you’ve worked at several different software companies, right? Were there any differences in code review style?

Jonan: Nowadays GitHub has a feature to review pull requests natively, but before that existed, I helped build a similar system at Heroku. Before you were able to merge a pull request, you had to get a coworker to look at your code and comment with an emoji; something like a thumbs up or a smiley face. If the pull request was merged before a peer had a chance to review it, perhaps in an emergency, the responsible team would get an alert to make sure they completed that review.

So at Heroku, it was generally my immediate teammates who reviewed my code, but at some previous companies it wasn’t necessarily like that. Sometimes we would have an architect review the plan before we started writing anything, and then get involved in code reviews once we began building. It felt more like a waterfall style of development, and I wasn’t a huge fan. I don’t like the idea that the architect determines what we should build or how we should build it. It’s a lot easier for everyone if we take responsibility for that work as a team.

Soutaro: So you think it’s easier to work when you’re using peer reviews, rather than architectural reviews?

Jonan: Absolutely. First of all, there were usually only three to five architects in the company; they’re very busy people. They don’t have time to become familiar with all of the details of a project, and they aren’t that familiar with our codebase. Who knows best? Developers that work with the code everyday, or architects who may only delve into our codebase.

Soutaro: When you compare those review methods, peer review and using a designated reviewer such as an architect, which is better from a product and quality standpoint?

Jonan: Peer review improves the quality of the code and the productivity of the team. Let’s say you and I are on a team; we both review the code, so we both understand the code. If I’m writing code in a particular file, you’re likely familiar with it, and you can help me write it or improve it. In a larger team, this shared understanding will be more difficult to achieve; I think 8 people is about the most people you can have on a team before you start sacrificing productivity. That being said, a strong peer review system will help even large teams to understand the code. It makes everyone aware of what other people are working on, and it encourages them to get involved in pull requests. Even if they don’t deep-dive into the code, they can get a general sense of it. And understanding how the system works at a high level is really valuable for productivity and code quality.

In a team structure where most of the code review is done by an architect or the QA team, developers are at a disadvantage, and eventually, that system slows everyone down. Peer review incentivizes them to learn more about the system, so they can be more effective in reviewing their peers’ code.

How to Use a Review Automation Service

Soutaro: Thank you for your thoughts on code review processes. By the way, have you heard of Sider?

Jonan: I’ve seen the website, but I haven’t signed up for it yet. I just found out about it here at RubyKaigi. I’m looking forward to trying it out, but my schedule for this event is a little bit hectic.

Soutaro: Broadly speaking, Sider is a code review automation service. There are some competitors, but our focus is to help engineers review Pull Requests.

Jonan: We’re using a similar service at Heroku, but unfortunately I don’t feel like we’re getting the full value out of it. Developers are busy, so they sometimes move too quickly setting up a service like this. It generates too many notifications and they end up being ignored.

I try to plan for that notification fatigue when I’m setting up one of these services, or even something like RuboCop. If it gets too noisy developers will ignore it, which defeats the purpose of using the tool in the first place.

I haven’t tried Sider yet, but I hope you have very configurable notifications. Effective notifications are essential in a code review service. I want one type of warning for critical errors, something that must be fixed right away, and another type for something minor that doesn’t require my immediate attention. I promise I will love Sider if you give your users useful notifications.

Right now, we are using that kind of code review service, but not at my previous job. We were using gems like flay and built a system for automated review. It is difficult to make the system work, but I believe code review is crucial, so I hope there will be more services like that. I am very much interested in trying out Sider now.

At Heroku, we’re using a code review service, but we didn’t at some of my previous companies. We often built our own similar systems using gems like RuboCop or flay. And while they’re difficult to get right, I think effective code review is crucial, so it’s worth the effort. Ideally, we’ll have many automated services like Sider to take care of that analysis in the future.

Soutaro: I agree that code review is absolutely essential. Thank you for joining us today.

Jonan: Thank you for having me.

Thank you Jonan, for taking time out of your busy schedule to talk with us!!


For more information about Sider, please go to our website.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.