28. An Interview with Raúl Raja Martínez

Written by Enrique López-Mañas

Raúl is a co-founder and CTO of 47 Degrees and a member of the Scala Center’s Advisory board. As a functional programming enthusiast and experienced engineer, he is a creator, maintainer, and frequent contributor to many well-known open-source libraries. He frequently speaks at technology conferences around the world and has developed free training assets to help ease the learning curve of a variety of programming languages and their related toolsets.

Connect with Raúl

Twitter: @raulraja

LinkedIn: /in/raulraja

Website: 47deg.com/team/raul

GitHub: github.com/raulraja

Interview

You’re an influential voice in the industry. You co-founded 47 Degrees, and you’re a contributor to the open-source community as well as several different projects. What are you reading or listening to these days?

I do a fair amount of both. I listen to most of the Functional Programming podcasts. I listen to three or four podcasts a week, and I do a lot of reading online. As I am developing and looking for documentation, I get interested in a topic. Then I go down the rabbit hole. When I see a new book that interests me, I pick it up, especially if it’s about Idris, Haskell, Scala, or coding. I also read a lot of short stories and comics.

What podcasts or books have had a lasting impact on your work?

When I was a kid in Spain, I read a book in Catalan called, L’esquelet de La Balena by David Cirici. It’s about a near-future when teenagers are stranded in the forest and technology helps them survive. As a teen reading this book, I realized there was a lot more out there than my kid’s world. That got me interested in technology and learning more about computers.

As far as podcasts, I love the Scala podcast. The host is from the same company that I used to work for, and she does awesome work interviewing people from the Scala community, talking mostly about Functional Programming. There is another great podcast if you’re interested in Functional Programming called Scala Love with Oli Makhasoeva. This one touches on different topics and more different languages as well, so it’s not just tied to Scala or a language in particular. Sometimes they touch on Category Theory. There are a lot of great podcasts for people interested in our field.

How would you explain Functional Programming to a newcomer?

Functional Programming is coding with functions and creating pure functions. Pure functions are those that, given an input, always produce the same output. They are deterministic in their behavior, and they produce no observable effects on the external world. For example, if you insert a record in a database, every time you load the function and insert the record, it’s going to produce an effect in the world. That would be an impure function. If you wrap that same computation into a data type, that function would no longer produce the effect. Instead, it produces a pure value to get a reasonable path around composing these other pure values. Finally, it executes safely when you’re ready. That’s what Functional Programming is about. It’s about programming with pure values that are composable, and they are created out of pure functions that produce no side effects.

That’s abstract, but if you’re familiar with functions at all, thinking of a function producing an effect or not is going to help you. You’re organizing yourself in a way where all your functions produce no effect; that is, they return a lazy computation you can defer invocation for instead of performing its effect eagerly.

Someone said, “I like Functional Programming because it takes people more talented than I am and makes them unemployable.” It seems that Functional Programming has been relegated to academia despite being a smart programming choice. What’s the relevance of Functional Programming for the commercial development environment?

If you’re one of those supposedly unemployable people, you should come work for 47 Degrees. We are hiring those kinds of people. At one time, Functional Programming was a small niche, but something great has happened. Languages like Scala, Kotlin and many other mixed languages in the space have taken over teams and companies all over the world. Now, people are doing Functional Programming more than ever before. There are entire industries in which hundreds of people are coding banking and web services, older systems, orchestration processes, and so on. They’re using Functional Programming. In the last five years, the rise of systems like Spark for distributed computation has brought broader adoption of languages like Scala. That has inspired people to learn Functional Programming.

In the same way, some industries are critical in terms of computation or numerical precision. They use libraries like Spire, libraries which employ Functional Programming, or are oriented towards the immediate use of the data. Streaming libraries like Rx lead to the development of Android. They have brought the functional combinators such as flatMap, map, filter, etc., which have been widely adopted and they are now in almost every language.

What was true five years ago isn’t true anymore. It’s time for everyone to move on. Functional Programming is increasingly adopted in backend development, and it’s increasingly relevant to frontend (React) and even Android development (Rx).

Functional Programming is taking the Trojan Horse approach of assimilating everything that is around it and infecting those languages that are not functional with functional features. Anyone mapping an Observable today is doing Functional Programming. If you know how to do that, I don’t think you’re unemployable. There are a ton of companies that need you today.

How do Kotlin and Scala compare?

Kotlin and Scala are syntactically similar. Kotlin came after Scala. It copied a lot of the features that Scala provides. For example, in Scala or Kotlin, data classes and case classes are essentially the same. Sealed classes in Kotlin are the same as Sealed in Scala, for the most part. The features and syntactic sugar are very similar.

The differences are mostly on the Type System side of things. Scala has a more powerful Type System and can do a lot more in terms of path-dependent types, for instance. You can’t do that with Kotlin today. Kotlin provides a different approach to some of those problems. For example, there are receiver functions or extension functions, which eliminate the scope of referring objects with dot notation. You can scope any block to an object, and then “this” pointer becomes the object reference, and therefore, you can access all its functions and properties with direct syntax. Scala does not have that ready, at least not yet. It will once they have extension functions, too.

In that sense, they both try to solve similar problems in different ways, when it comes to dependency injection or scoping. Scala uses implicits. Kotlin uses extension and receiver functions. Aside from that, Scala is less powerful in one thing. Kotlin has a suspension system. The suspension system allows you to encode IO continuations. That currently makes IO potentially faster in Kotlin than in Scala. We are trying to prove that in Arrow. I can talk about that later. In summary, there are things that Kotlin programming language has that work better than Scala, and there are things that Scala has that are more functional than Kotlin.

Kotlin is more oriented towards effects, and Scala is more about a Type System and being able to support polymorphism, higher kinds of types that in Kotlin are less of a problem. Once you have a suspended system, you eliminate IO. IO obeying Scala is the same as a suspended function in Kotlin. This eliminates the wrapping and the need to map, flatmap, and so on because you can just operate over imperative syntax suspended. That is huge for Functional Programming because you eliminate F. All of that is possible with Kotlin, but it’s not so much in Scala because you are more guided towards the syntax of the type systems and suspension is effect suspension is not baked in the language.

Those things make Kotlin things easier in terms of F being oriented to effects. When it comes to being oriented to polymorphic derivation, generic programming or type-level programming, Scala is apter. I make money with both as a consultant, and both are great for different communities and purposes.

As developers, it’s very important to keep an open mind because every few years things change. Kotlin is relatively new, and maybe in four years, we’ll have something different. It’s bad to marry any technology.

This is not politics. You don’t have to take sides.

You are the maintainer of Arrow, a library for Typed Functional Programming in Kotlin. What are the spaces where a potential developer can find Arrow helpful?

Arrow provides a toolbelt for functional programmers. It includes type classes and data types alongside many utilities to make your code pure and composable. You have the guarantee that unless explicitly denoted, all Arrow APIs are pure and principled in terms of the algebraic laws that govern Functional Programming as a technique.

Arrow’s goal is to provide a lingua franca—“One ring to rule them all.” It’ll be a single API composed of about fifteen different functions. Once you learn those functions, you can compose any program that can be written with those data types and those abstractions. You no longer have to depend on learning third-party framework APIs like Rx or whatever comes next.

Arrow tries to give you that math-fundamental language in which program composition is based upon. You can go full wild and do everything polymorphic, or you can use the Data Types that you care about. Arrow has small articles. It teaches you how to apply them to your daily programming and provides you the instructions to do so.

It’s not an elitist framework like you would find in some languages. You can use it however you want. The foundations for each data type and the laws that it abides by are there. You don’t have to use all of them.

You served as the CTO for 47 Degrees while you remained active in the developer community. How do you find the balance between being in a position of leadership and being a developer?

Once you’re in management, you have the power to influence where money and time go. Any company that invests in open-source is going to attract the developers it needs as resources, and those developers are going to make money. That money is going to generate more means for resource acquisition, and so on. If your company doesn’t have a balance, your capacity is limited.

A CTO in the tech industry has to be involved. You’re going to sell consultant services for things that you are building—things that the community cares about—and that community that cares is going to help you build. The CTO can’t stay in the corner punching a keyboard. A CTO has to manage resources for the company to keep it stable, healthy, and honest. It’s all a matter of strategy, and at the same time, it’s a matter of doing what you like and making that impact. Doing what you like and making money at the same time is awesome.

How would you advise a developer that wants a career path to a CTO role?

I don’t know how you can climb to CTO from being an employee because I haven’t done that. Being a CTO means being in a primary management role while staying current with technology. You have to be adaptive to everything in the communities you are working with, and you have to be looking for ways to do things that get people interested. If you want to be a CTO, you’re going to have to do pretty much whatever it takes, and that depends too on the company.

You’ve worked for Boeing, one of the biggest companies in the world, and now you’re CTO at 47 Degrees, which might be one of the smallest. How do the environments compare?

I worked on the 787 at Boeing. I worked with great people whom I’m still friends with. There are many reasons why I left, including bureaucracy. Bureaucracy is a part of every big company, and it makes it hard to get things done. That was my biggest problem there. That’s not something you have in a smaller company. That’s the main difference. At really big companies, you can never follow your own destiny. You might be there because they pay you well or you’re working on something that interests you. Climbing the corporate ladder is something that I’m not really interested in. I’m interested in technology, and a small company is a better place for me. At a small company, I can create a bigger impact and work on what I like. In a bigger company, I couldn’t.

“I dislike all the startups and companies that emphasize entertainment… When companies try to create a culture, it limits the types of people who want to work there. I think it’s better to attract people by other means.”

Some people say life at a corporate institution is easier.

It’s about the individual. For example, I dislike all the startups and companies that emphasize entertainment. Everything is about game rooms, and trying to keep everyone inside all the time. I value individuality. A lot of the problems that you might find in socializing as an engineer may be because your work requires you to be in front of a computer for so much time. I like the kind of company where people are just on their way. There’s not this startup, millennial-style culture. When companies try to create a culture, it limits the types of people who want to work there. It’s better to attract people by other means. Open stores, or build compensation packets, or whatever it is, rather than entertainment rooms.

Being able to contribute to open-source or being able to work remotely is also one of the big things today.

Remote is the future. People that are offered the option to work remotely tend to know the best way for them and tend to be very productive. I like to work remotely when I need concentration time without distractions.

What are the views of remote work at 47 Degrees?

We started remote work when we grew about 6–10 people. Then we went to fifteen, and at some point, we had one or two remotes. More people joined, and many of them were remote. Mostly, we went that direction because we got into Kotlin. Several of the coding guys we had in the company were trained in Scala from scratch. Many of the coding guys came in knowing Kotlin. For that reason, we hired different remote positions. We find that most people who live close to an office location work at the office a few days of the week so that they can get together with co-workers and share in-person, and they work remotely other days. Of course, there are some other people that are remote the whole time, and then they come to visit the office throughout the year. So far, it’s been working great.

What was the hardest thing about starting your company?

We started in September of 2010. 47 Degrees was founded by the engineering team at our previous startup that closed. At that point, we decided to do it on our own and try to save the team. We took 50 bucks, got our business license in the city of Seattle, and decided that we were going to start doing work for free. We worked for free building websites and small projects until we developed a portfolio, at which point we started charging. That’s how we got our financing. We worked for four or five months without getting paid. Once we had built a name for ourselves, we started getting contracts. We’re unusual because we never took a loan or investment.

That is an unusual case. Did you have a plan B?

I have never been afraid because thankfully, until now, being an engineer has paid well, and it’s been easy to find a job. I left for the U.S. with no money and tried to make a living there with my wife. Her parents helped us. What I’m saying is if you have some back-up plan, whether it’s family or your job situation, you can always find another job. You can take those risks. Don’t be afraid. If it doesn’t work out, there are still many places looking for engineers.

How do you plan your workday?

I try to plan my weeks ahead of time in terms of meetings. I usually work during the evenings and in the mornings in random chunks of three or four hours. When I have meetings or things planned, then I follow more of a straight routine. At the end of the day, being a part of my family’s routine is where my happiness lies. In terms of work, I think about what I’m trying to accomplish and by when. What resources do I need? I can plan all of that ahead, which gives me the freedom to move my routine for the convenience of my family. This gives me a good work-life balance.

How do you define success?

Success is being able to do whatever is important to you. If you’re taking care of your family, that can be a success. You don’t have to have a dream job. Your internal sense of satisfaction in life is what makes you happy. In terms of work, do what you like, or do what allows you to do what you like. I would say those two things together equal success. As well, try and help others. Your success shouldn’t depend upon others’ failures.

Raúl’s Recommendation

• Essentialism: The Disciplined Pursuit of Less | Greg McKeown