6. An Interview with Paco Estévez GarcÍa

Written by Enrique López-Mañas

During his career, Paco has experimented with early prototypes and bleeding edge software, at-scale video services, and a bit of video game development. These days, the challenges he faces revolve around applying functional concepts to improve development experience workflows, learning and efficiency.

Connect with Paco

Twitter: @pacoworks

GitHub: github.com/pakoito

“Code is not always the hardest part of the job… The primary challenges are still interpersonal relationships, communicating with stakeholders, and gathering information.”

Interview

What are the three books that have positively influenced you?

As a kid, I was influenced by Terry Pratchett’s books. My favorite is Night Watch, and you need to have read some of the previous books to get all the references. Generally, Pratchett presents a way of living that was completely different from my life in Spain. A couple of decades later I’m living in London and I have a raison de vivre that is completely different from people in my home country.

A technical book I recommend is Functional Reactive Domain Modeling by Debasish Ghosh. When I was starting doing functional programming I was working in isolation. Reading this book helped validate my approach.

Another book I really like is How to Make Friends and Influence People. This book describes how people’s behavior hasn’t changed much despite the technological revolution. People are still people at the core, and they tend to click in the same ways. That book gave me good ideas about how to interact with other people and how to be the best version of myself.

Writing code is not always the hardest part of the job, and the hardest problems haven’t changed. The primary challenges are still interpersonal relationships, communicating with stakeholders, and gathering information. Those kinds of problems are still front and center.

You have a great reputation in the functional programming community. For those on the outside, the functional programming world seems like a magical universe. How would you explain functional programming to a developer that doesn’t have any experience with this world?

Functional programming can be thought of in terms of constraints. It’s an approach to programming that is very structured. When learning programming you were told you could do anything you wanted. On the other hand, what functional environments offer is a limited set of approaches to solving a problem, that you have to compose together into a larger solution. Those limitations are actually liberating. Instead of potentially endless options for how to create a program, functional programming, or FP, defines a set of tools that work in combination. Think of FP as more like putting a puzzle together rather than sketching or inventing a world from scratch.

How would you explain the relevance of functional programming to someone developing software to manage a database or an interface? How can they benefit from functional programming?

The books that I read and the processes that I follow are the same across multiple languages, and they’ve been consistent for many years. When I approach a corporate codebase, I find that there are twenty different ways of doing twenty things. On the other hand when I’m working in a functional codebase, or when I’m approaching a functional language, I know what the available constructs are as well as which ones I’m going to use. That means I can move fast in a codebase that uses Java, JavaScript or Lisp, or F#. All of them have a set of commonalities. These restrictions are the pieces that you’re building your program from.

If you’re a corporate developer, you’re more worried about frameworks, which are specific to each company. Those skills may not be transferable and may make it difficult for other engineers coming into your team to be proactive.

This is one of the biggest advantages of this paradigm, and at the same time it’s the largest adoption barrier. It seems counterintuitive that you need to spend time unlearning dogmas that are widespread through the industry in order to unlock your productivity. Still, since you can apply functional programming in so many environments you start seeing the job of coding differently. Many people think of functional programmers as programmers with special knowledge of big or abstract concepts. The concepts aren’t big or abstract, instead these programmers have reshaped the way they think about code. Functional vocabulary makes it possible to communicate in a consistent way with any programmer who understands those concepts. On the other hand, if you’re a Java developer talking to a JavaScript developer the differences may seem insurmountable.

Having a single set of abstractions that are consistent and common across every platform would be very beneficial to many companies. For one thing, it would make hiring easier. You would need fewer instructors, fewer evangelists, and fewer people thinking about this because everybody would be writing pretty much the same code across different languages. Sometimes you want fast languages and sometimes you want expressive languages, and for both you’d still have the same core set of constructs.

Programming languages today are evolving, all of them, in the direction of unification. Java is getting pattern matching and structs. Rust is a huge success in the C++ community, and it is mostly ML (meta language) which is the base of OCaml and F#. We are coalescing. Even JavaScript is adding new features based on those languages!

Standardization may evolve slowly, but it’s what’s coming in the next ten to twenty years.

What’s the best way for inexperienced developers to learn functional programming?

There are multiple approaches to this question. Some people like to take a class or follow a book. Others prefer to be thrown to the wolves and figure it out. An approach I would recommend starting today is to stop using re-assignment so that the only place where you can assign things is on creation and initialization. Impose the restriction on yourself that you can’t assign anything to a variable afterward. With that simple restriction you’re going to start finding necessary patterns.

For example, you’re going to iterate through a list and aggregate the results. Because you can’t assign a variable to the new list of values outside of that loop you’ll be forced to find a way to write the pattern. Next, you’ll discover abstractions like folding a list. To do that, you’ll apply a function in order to change all the values in a list. That function is called mapping.

By avoiding reassigning, you’ll start thinking about these functions. That’s pretty much at the core of it. Everything else is just how you compose those at scale. When you get to composing for a larger scale, books can be helpful because people have experimented with this for many years. We already know the most efficient ways of combining simple functions to prevent assignment. If you have the time, avoiding re-assignment is a great place to start learning functional programming.

In doing this, you could keep using your previous language, right? This is possible in any platform, technology or language—to work without an FP library or any language similar to FP.

Correct. The only difficulty might be with original C. The language used has to have a feature called closures. Closures mean that your lambda, an anonymous class, or any similar construct can capture variables from an external context. That’s the only requirement. If you have that you have an entry point for FP.

Aside from being a software engineer at Facebook, you’re also a contributor to Arrow, which is the FP library for Kotlin that is being developed by you, Raul Raja, and others. The consulting and development firm 47 Degrees is actively supporting this work. What is this library contributing to the world of Kotlin? How will people working in that world benefit from this library?

We’re thinking of the ways the library will benefit people coming from both directions. As learners start needing composable functions they’ll start writing them themselves. They’ll be able to check the library and reuse it. In other words, for beginners it’s a way to move up the learning stack. Learners will get these abstractions and be able to read and understand them from their mechanical implementation.

For experienced users, we’ve opened up the Kotlin language to people who have historically used Scala, F# or OCaml, or even Clojure. These developers didn’t even have access to mobile phones.

You can’t develop an application in Scala for any scale due to hardware limitations. However, you still want the same toolset that you had in Scala. Because this is not a language-specific approach, we put everything you’re expecting in your day-to-day toolbox in Kotlin. For people who know what they want they only have to search in which package to find it. Where is my optics library? Oh, it’s here. Even if you feel that you don’t need it, there it is just in case for when you do. People are happily telling us that the functionality is the same as the best parts of Scala. That’s it. The syntax is somewhat different, and the expectations are exactly the same.

You’re an active contributor to open source code. What are the main difficulties you find in contributing to open source projects?

First, there are people who lack the confidence to contribute. They need encouragement and a guide. This is something you have to care about. I’ve learned many of the things that I know about programming, engineering, and computer science from collaborating with other people in open source. Through their code and their interactions with the community they showed me how I could improve myself. I pay that forward by teaching other people and getting them into this ecosystem. Some companies don’t like it, and we should continue getting people into that open source sharing mindset.

Other common barriers of entry is snobbism and community gate keeping. This is somewhat common, where people believe that only a few big companies with huge backing, money, and rockstar engineering should be doing the important things. These people advocate for only using things built at scale for solving big problems, or those built by the best engineers. This is obviously a fallacy, usually pushed by internal incentive models that force employees to compete for attention. The best you can do is ignore them and focus on providing the best experience to your users and contributor colleagues.

It’s on each of us to be the ones taking that first step to make sure that your specific community is welcoming, that you’re getting people from every avenue of life, that you’re teaching them. Don’t think of it in terms of what you’re doing for them. Think instead that you’re building something together. You’re not better than others just because you are working on this massive big project within a mega corporation, neither as an engineer or a person.

For those people who are not contributing yet to open source, how would you recommend they get started? How can we spark their interest in being effective contributors?

There are two ways for people to start programming. There’s the university path, where you show up to class one day and now you’re a programmer because you have written some code. That’s going to be your new work life. Others feel motivated to learn programming by themselves and sit down with a book or with online resources and start developing.

That same drive that you have to learn programming is the one that you can apply to open source. You just have to show up and find the project that you can contribute to.

Now, not every project is right for every developer. Some long-running projects may not welcome contributions from day one. One case would be, for example, the Linux kernel or the Android OpenSource Project. If you try to contribute there and it’s less than pristine, there’s a good chance somebody’s going to take issue with it. That’s a bad experience, and it makes people afraid to try.

What you want is a nurturing community focused on something you care about or something that you know you can contribute to. Don’t be afraid to ask whether a group is willing to take contributions and don’t feel discouraged if they don’t. You can also use conferences, meetups, and your day job to find people interested in starting a new project together.

Once you find a group of people you’re happy collaborating with, or a project that takes contributions, you write the code, and make a pull request. You’re an open source contributor now!

How are you so productive and able to contribute to so many projects? Do you have any sort of routine?

I’m awake when everybody else is asleep. I’ve been lucky that most of the companies that I’ve worked with allow for a flexible schedule. Most people wake up early, get the day started, show up in the office, and work until they’re done. I come to the office around noon, work, and then take a three- or four-hour break to have dinner and catch up with friends. And then, after midnight, I have another three hours of uninterrupted productivity.

Sometimes in those three hours I can solve one open-source problem. Or maybe I take a look at the documentation, read through it, and find an improvement. Or I can review a couple of pull requests. There are no notifications. There’s no WhatsApp, no Messenger chats or anything happening at that time. That’s my approach to productivity: by shifting my schedule by several hours I have uninterrupted time every single day, at the expense of some daytime activities.

How do you keep up to date on all the new trends and developments in our field. How do you keep learning?

Several years ago I drank from the fountain of social media, followed papers, watched all the talks, went to all the conferences, read all the books and everything you could think of. At some point your brain gives up. You can’t keep up with everything that is going on. You have to be selective to the things that are important to you. For some people that means mobile development. Maybe for you, it just means following a single framework, and whether it has some deprecations in the next release. You don’t have to follow everything. Once you’re selective with your time, you can enjoy the things you’re actually catching up to.

I prefer to watch talks that are about general concepts. I’m very rarely going to watch a talk about version 2.0 of the framework. I will have plenty of time to read through the documentation, go through the examples, and write the code myself for that once I start working with it.

What I do need is somebody telling me about their experience. What approach did they take to a problem? Why did it work or not? I feel less affinity to frameworks and monolithic approaches than to general suggestions or explanations of how people tackle problems. And this also applies to my own projects. In the case of Arrow we’ve tried not to be prescriptive about architecture, or which parts of the library or patterns are required to be “pure functional programming.”

I also try to give the same type of talks that I like to watch. I prefer not to be dogmatic about architecture or approaches. My talks have a lot of information about how I am tackling specific problems. I tend to address the steps that I took, my thought process, and implications of time and scale. You’re free to take that information and apply it to your own frameworks. I think that’s helpful for many people because sometimes you don’t have the benefit of having a breadth of approaches in your codebase.

What do people underestimate in this industry?

The importance of empathy. I know it’s a bit of an overused word, yet still, I’ve found that some of the biggest problems in our industry center around communication, especially with regard to mismatched needs. Say somebody is working on their own product’s code and they find a big conceptual problem at the core of it. Maybe it’s the theming, the UX, or a piece of the logic that’s incomplete. They complain about it, and they get very angry and passionate about why this is a problem that has to be fixed by somebody else. At that point a very confused team fails to see the value, which creates a loop of bad feedback. It’s easy to contribute negativity and detract from the general value, both for the reporter and the person receiving the reports.

It’s the same for people working in new libraries or frameworks. I see a lot of condescension directed toward users, that they’re dumb or just not as good as engineers and get easily confused and will not learn further than what’s taught in university. That lack of empathy shows often in internal meetings between maintainers, especially at large tech companies. This is something that our industry could definitely work on.

How can we encourage folks to develop more empathy?

One proactive way would be calling out bad behavior. Be argumentative but not confrontational with the people that are not being empathic, in a way that is empathic itself. Don’t return aggression with aggression. Kill them with kindness.

I like the idea of killing them with kindness. Is there something that you didn’t know when you started in this business and you had to learn the hard way instead?

Yes. What I learned over time and what we are trying to teach people when mentoring them is that it’s not always about the code. The code is a really important part, and it’s a really fun part, but if you get lost in the code sometimes you lose that connection to your users and the needs of your company. You have to balance mentoring, interviewing, reviewing code from other users and gathering information. All of these are necessary parts of being a great engineer.

Also, it’s not always the best coders whose careers advance the most. That’s a paradox. There’s the archetype of the isolated technical genius who nobody wants to work with. They’re assigned to specific projects that keep them separated from the rest of the company. They’re prevented from progressing because the moment that they interact with all people, they detract from the global productivity. People like that are a net negative contributor to the outcome of the company. That happens sometimes, and you have to try not to be that guy.

You may be asking yourself why. How is this guy who is so productive on his own contributing negatively to the productivity of everybody else? And it’s simple math. You want to be the person that is actually doing 90% for yourself and lifting the rest of the team to 120% for each one of them. As your team grows the overall output would be great, and those other people will go and help others. If you’re the guy that is putting in 120% but you’re the only person on the team who is growing, that doesn’t correlate with progress, success, or getting the best projects in the company. Instead people start to resent you, to the point where you may even be driven out of the job.

What would you recommend to a junior software developer who is currently starting their career?

There’s no single correct path. Everybody whom I’ve spoken to comes from a different avenue of life. The commonality between most of them is hard work. You have to sit down and do the work. The work is not writing code. The work is everything that is required without burning yourself out. I can’t emphasize it enough—how important just doing the work is.

It sounds very abstract. It’s important that others perceive you as being a good worker and an honest, capable and open person.

It’s not so much about your coding output. Many people are going to be better than you at that. There’s always going to be somebody that is better than you. It is about showing that you can do the work, and showing that you take pride in what you do. For me, that’s what’s most valuable.

Any final words of advice?

Keep mentorship in mind as you’re progressing through your career. Check yourself for elitist attitudes and beliefs. Share information. Don’t alienate anyone. Be nice to everyone as you don’t know what they’re going through or who they’re going to become. They may impact your long-term trajectory more than you can do just by yourself! Stay open and help others.

Paco’s Recommendations

• Structure and Interpretation of Computer Programs | Harold Abelson and Gerald Jay Sussman

• Domain Modeling Made Functional: Tackle Software Complexity with Domain-Driven Design | Scott Wlaschin

• Functional and Reactive Domain Modeling | Debasish Ghosh

“Simple Made Easy” presentation | Rich Hickey | infoq.com/presentations/Simple-Made-Easy/