18 An Interview with Gabriel Peal

Gabriel is an Android engineer at Tonal where he works on bringing strength training into the 21st century. He also maintains Lottie for Android, an animation library used by tens of thousands of companies as well as MvRx, an Android architecture library built on top of Android Jetpack. Prior to Tonal, Gabriel was an Android engineer at Airbnb where he worked on a variety of Android product and infrastructure projects. Gabriel was also one of the first engineers on Android Auto. On Android Auto, he owned a variety of projects including assistant, system UI, music and phone calls.

Gabriel Peal

Connect with Gabriel

Twitter: @gpeal8 LinkedIn: /in/gpeal

Interview

You are a very senior developer, having worked for some of the big companies in the Bay Area in California. What kind of leadership have you had to show in your role?

Making decisive decisions can be challenging up front but pays dividends in the long run. One example was the decision to sunset React Native at Airbnb. Even though many teams were successfully using React Native and we had some groundbreaking projects in the pipeline, it was clear that React Native was never going to gain significant traction beyond what it had already captured. Fortunately, we made the hard but unambiguous decision to sunset it. This required working with many teams using React Native to reduce the impact on their roadmap while communicating broadly and without ambiguity that React Native is being fully deprecated at Airbnb. It would have been easier up front to reduce our investment and allow it to continue organically. However, the result could have been hugely detrimental to the developer experience internally and the quality of the product externally.

What is your leadership philosophy?

A high-functioning team is greater than the sum of its parts. However, a toxic culture can grind an entire organization to a halt. Also, many people in tech are truly passionate about their work and make it a part of their identity. In doing so, a positive or toxic team culture can bleed into every aspect of their life. As a leader, you have to recognize the unique personality of every single member of the team to maximize their potential and enable them to do their best work. As soon as personality clashes and conflict start to arise, it is important to be direct and approach the problem head-on before it grows and affects more people on the team.

What is something you had to learn on your own that you wish someone had told you back when you started in this industry?

The code you write doesn’t have to be perfect the first time you write it. When writing something new, I often like to write it a few times, making a huge mess in the process. In doing that, I’ll try several different approaches, freely throwing away code and refactoring things until something feels right. Only once I have a full picture of what I want to build will I clean everything up and make it presentable. From my experience, useful insights emerge during the building phase of any project that would have made a meaningful impact on the original design phase. Constraining the building phase to the limited set of information you had during the design phase inevitably leads to a local maximum solution and prevents explorations into new approaches that may become clear while building.

In drawing insight from other resources, which do you prefer: podcasts or books?

I am a huge fan of podcasts. I think they strike a great balance of polish, relevance, depth and variety. I also find them highly practical because I can listen to them sped up while at the gym or driving. I have always aspired to read more but struggle to read more than a few books per year. It is really easy to stall on reading in general when you lose interest in a single book. Recently, I have gotten better at giving up on books that I am stalled on and am both enjoying reading more and finishing more books than I used to.

What are the three books or podcasts that have had a lasting impact on how you do your work?

I started listening to podcasts in 2005. One of the first podcasts I listened to was This Week in Tech, hosted by Leo Laporte. This Week in Tech was my first foray into tech. It got me thinking about the world of consumer electronics and helped me paint a picture of the state of the world.

More recently, I have been listening to Masters of Scale with Reid Hoffman. His podcast has an stellar lineup of guests who share their experiences scaling businesses. Not only do you get insights into the incredible things many of them have done but you also get to see how humble many of their beginnings were or how they recovered from serious missteps along the way.

One book that has stuck with me and is on a very short list of books I would reread is How to Win Friends & Influence People by Dale Carnegie. I have even set up a recurring daily notification for each chapter title such that I get one each day to focus on.

One major shift the book helped me internalize was how to shake the egocentrism with which we all view the world. There is so much stress and anger in the world built up around the fact that somebody overestimates their importance in a situation. Learning how to contextualize and frame why other people behave the way that they do is something that can have compounding positive effects on relationships and stress levels.

In 2018, you published one of the most-quoted articles in the IT world, “React Native at Airbnb,” where you relate your experiences using the framework with Airbnb. The dichotomy of developing a native app versus using a multiplatform framework has been ever-present in this industry. What are the key advantages and disadvantages of each aspect?

Picking the right mobile framework to use for a new project can be daunting. At this point, there has been enough native, React Native, and Flutter projects to find confirmation or disdain for pretty much any framework. At a high level, React Native and Flutter excel because they truly let you write most of your code one time and both support hot reload. However, the relative immaturity of each platform means inventing solutions that have been done many times on Android and iOS.

React Native and Flutter are also easier to learn than Android or iOS. I have seen teams with very little mobile experience ship Android and iOS apps that would have been completely impossible to deliver natively with the same engineers and time constraints. Also, all cross-platform frameworks still struggle when introduced into a large existing app.

In migrating from a native architecture into a multiplatform, one brings not only technological changes but also organizational ones. What are the most significant technological and/or organizational changes you have observed?

Organizational alignment is an extremely important quality of a high-functioning team. You may find that a cross-platform framework has some technical advantages but members of your team actively don’t want it, so be prepared to deal with those issues indefinitely or consider whether the approach is right for your team. You don’t have to turn existing Android and iOS engineers into enthusiastic supporters of cross-platform before starting. However, a level of respect and cooperation will be required from the get-go.

How would you recommend a company tackle those changes effectively?

Tackling the organizational challenges of introducing a cross-platform framework requires an open and honest communication channel. If the introduction is painted as a top-down silver bullet that will fix every problem, it is bound to fail. However, approaching it with balance and as a pragmatic experiment where the pros and cons will be considered within the specific context of your organization, things are much more likely to go over smoothly.

It seems that the industry demands of us to change our development paradigm every few years or even months. What advice would you give to a software engineer or developer on navigating through all these changes?

Being an engineer can be exhausting. There are new libraries, architectures, and frameworks all the time. When deciding whether to introduce something new into an existing codebase, it is important to think about its implications not just within the context of what it will be used for but also how it will interact with the rest of the codebase and will affect other engineers on the team.

Considering the holistic picture is particularly important when introducing a new framework or architecture. I have heard of product teams at large companies who want to introduce something like React Native into a codebase because it will help them move faster. However, they fail to consider the impact on other systems such as build tools, internationalization, experimentation, and sharing state with other features.

However, if you are excited about something new, it never hurts to spin up a side project or convert some existing code to something new. Simply using something will give you more perspective than reading a dozen blog posts and tweets. Also know that if you don’t use the latest trend that everybody is raving about, it doesn’t make what you are doing today any worse.

What recent industry or technological change or trend do you find the most exciting or promising?

I love the trend toward reactive programming. Nearly every platform is moving in that direction. React, which is aptly named, have proven that reactive programming is an effective way to scale a maintainable and testable codebase. You now see similar reactive patterns being used in Flutter with StatefulWidget, and on native Android with MVI and other libraries such as MvRx. In my experience as an engineer and mentor, reactive codebases tend to be easier to learn and become productive with. The simplicity of most reactive frameworks is a testament to that. The API surface area of components in React, StatefulWidgets in Flutter, and MvRx on Android are almost entirely consumed by setState, getState, and subscribe, and it is no coincidence that their life cycles are vastly less complex than they are for native Android and iOS development.

Are there any trends that you feel are just plain wrong?

I think there is too much emphasis on testing up-front versus building out a robust metrics platform to track metrics in production. While testing can be crucial in specific and considered use-cases, I have yet to see their value when applied broadly when you consider not just the safety they provide but also the opportunity cost of writing and maintaining them. Some of the best and most stable codebases I have worked in have had close to zero tests while some of the worst and most error-prone codebases have had nearly complete coverage. On the flip side, it is incredible how few metrics people collect and actively monitor their users in production. You can have broad test coverage while leaving major features broken for some or all of your users for release after release.

What would you suggest as an alternative to this trend?

I think engineers should consider how to measure the performance and reliability of features in the wild. One reason measuring analytics gets less consideration than tests is that tests can be done entirely within the scope of a codebase. You can write code and immediately write tests. However, monitoring analytics requires continual effort. However, building out a proper data and analytics pipeline requires stepping outside the comfort zone of many engineers. Doing this right usually requires learning new tools, integrating with new services, or even building out new pieces of infrastructure on AWS.

Multiplatform frameworks have been ever-evolving: Flutter, React, Kotlin/Native. It is difficult to take a bet on a single platform. But what are your views on this? Should we, as developers, bet strongly on any of them?

It is too early to bet the farm on any multi-platform framework. The mobile community is large enough to support multiple large frameworks. It is very possible that native, React Native, Flutter, Kotlin Multiplatform, and yet-to-be-built frameworks can all live in tandem. To date, each framework has brought new ideas to the table. The more smart people you have contributing new ideas, the better the outcome will be. When writing Airbnb’s blog post series about sunsetting React Native, my biggest fear was that if it came across as too negative, it could have a detrimental impact on the size and morale of the cross-platform community. This would have been a disservice to everybody. Great ideas can come from anywhere. We used some of the best parts of stateful and immutable programming from React Native as the inspiration for MvRx which is now the de facto way of writing native Android code at Airbnb.

With all these changes, how do you keep yourself up-to-date with your skills or career?

Twitter and YouTube and Medium are excellent sources to stay up-to-date in the Android world. My Twitter account consists of nearly 100% Android engineers so I find an incredible amount of high-quality content and collaboration there. I have also found that the Android community on Twitter is Twitter at its best. Start by following a few Android developers, then follow their retweets and Twitter’s suggested followers to gain a broader reach within the community. Twitter will then become your source to discover the rest of the high-quality content that exists whether it be a conference talk on YouTube, a Medium post, caster.io course or anything else. The beauty of Twitter is that it is also a two-way street. You can use it not just to consume but also to share and build connections with other people in the community.

In working on your projects, how do you start your day off with a bang? Do you have any secret morning routines that set you up for success?

I treasure my morning shower. There is a r/Showerthoughts subreddit for a reason. Somehow, because of a combination of the warm water and a clean separation from all technology, I do some of my best thinking in the shower. I then try and arrive to work at least an hour before most of my coworkers. Head-down coding time is precious and it is amazing how productive you can be if you sit down with a specific goal and can work without distractions. This becomes an order of magnitude harder once the normal work day starts and the routine of meetings, Slack messages, and conversations fragments your workflow. On many days, I get about as much coding done in that first hour as I do in the rest of the day combined.

How do you stay highly productive for long periods?

There is nothing more satisfying than sitting down with the explicit goal of creating something and then achieving it. This simple fact is hard-wired into our brains and incentivized by the dopamine boost you get after achieving something. Luckily, the tangible nature of programming is perfectly geared to give you these dopamine kicks after fixing a bug or finishing a new feature. When I work, I like to set a clear series of goals for myself. This process of creating incremental and achievable goals can be so rewarding that hours and hours will fly by before you realize it.

Overall, what would you recommend to an aspiring software developer to get started in their careers?

Pick something you want to build and build it. You will learn more and be more satisfied building something you care about with the wrong tools than building something you don’t with the right ones. It can be overwhelming to try and pick the perfect language, framework, and architecture of a project before starting. As you gain experience, it will be easier to anticipate the pros and cons of different approaches ahead of time but even years into your career, these types of choices will still not be black and white.

While using something for the first time, don’t stress out about getting everything perfect. Writing code is an iterative process. It is easy to refactor things later. Accepting the fact that you will write imperfect code that you can refactor later is critical to getting over the writer’s block that kills many ideas too early.

Gabriel’s Recommendations

• The Consciousness Instinct: Unraveling the Mystery of How the Brain Makes the Mind | Michael S. Gazzaniga
• How to Win Friends and Influence People | Dale Carnegie
• Unbroken: A World War II Story of Survival, Resilience, and Redemption | Laura Hillenbrand