Welcome back to the Effective Interviews ⚡️ a series of written interviews with well-known engineers from the Android worldwide community.
Subscribe to get them in your email 📩
Today we talk to Pierre-Yves Ricau, also known as P-Y!
P-Y is the master of memory leaks. Not because he causes them though, but because he automated how to prevent them. P-Y is the creator of LeakCanary, a widely adopted memory leak detection library for Android.
🟣 Welcome to the Effective Interviews P-Y! 👋
Bonjour! I hope I’ll get the job.
🟣 How was your childhood?
class PY : Application() {
override fun onCreate() {
super.onCreate()
readBooks()
buildLego()
}
}
🟣 When and how did you start with Android development? How did you get interested in it?
In 2009 I was interning at a software contracting company. My boss lended me his HTC Dream and asked me to learn Android and build an app for SugarCRM, and two weeks later I released sugadroid. I loved being able to push code into a device in my hands instead of some abstract server, I was instantly hooked!
🟣 You moved from France to the US. Did this process feel daunting back then?
Not really! I had no plans to move to the US until Jesse Wilson reached out. I interviewed, got an offer, then Square’s lawyers did all the paperwork. A few months later I was in the US with a suitcase, $2,000 in cash in my pocket, and a friend hosting me for a few weeks. For me, it was more of a fun experiment, I definitely didn’t think I’d still be there 10 years later.
🟣 Living in SF. People criticize this city a lot lately but I’m sure there are also great things to highlight. What do you like the most about living in a town like SF? Is it something you would recommend to other people?
SF has a lot to offer! You can meet a lot of weird and interesting people from many different backgrounds. The parks are really nice, the sea is right there and you’re only a few hours away from the mountains. The restaurant scene is amazing. I would absolutely recommend living there… keeping in mind that the cost of living is really high.
🟣 You created LeakCanary, thanks 🫶. It became the de-facto standard to keep memory leaks under control in Android, so congrats! 🥳
What did you learn with this project and what is your perspective of it after many years?
I learnt many things from building LeakCanary! In no particular order:
I used to think that LeakCanary should avoid having external dependencies (Jetpack, Okio) to their latest versions, as it could create annoying upgrade work for consumers of LeakCanary. But newer versions of Jetpack libraries sometimes break backward compatibility in the generated bytecode, so maybe keeping dependencies up to the latest isn’t so bad after all.
LeakCanary is a tool that gives expert powers to non-experts. Making tools easier to use for non-experts often translates to simplifying by removing all the details, in turn making the tools useless. With LeakCanary, I learnt that a better approach was to identify which information experts use and what they do with it. Then the tool automates that manual expert work, communicating which information it looks at and what it concludes from it. You could use a similar approach in the performance profiling space.
When you don’t answer issues for a few weeks, some people will get mad and comment that “Square has abandoned the project” or comment “+1” to hell. Open Source is draining, random people expect you to work for them yet most projects don’t have dedicated full-time teams. Take away: do it on your own terms, at your own speed.
Many scary software things turn out to be fairly simple code at the core. Parsing heap dumps? A while loop where you read a few bytes at a time. Graph path finding algorithms? A while loop that leverages a Queue (nodes to visit) and a Set (nodes visited). And interestingly the Mark-and-Sweep GC algorithm is very similar (Sweep = delete nodes never visited).
When you create a tool that helps with debugging, people will file issues asking for help to fix their own app bugs, even if you insist that they shouldn’t. Inspired by OkHttp, I created a special honeypot issue type: “🐤Leak in your app” which catches people in the moment and redirects them (try it here).
Over the years LeakCanary has caught many leaks in the Android Framework, and today these tend to be caught in the preview releases. Unfortunately, there’s a whole category of temporary leaks that still plague the Android Framework: binder leaks. It’s when binder objects in charge of Inter Process Communication can’t be garbage collected, even though they’re not used, until the other process runs its own GC.
My perspective on LeakCanary is that I’ve still barely scratched the surface of what we can learn by analyzing memory: LeakCanary could show what’s impacting the memory footprint, beyond just detecting leaks. And leaks are here to stay anyway: for example, we just fixed a really bad leak caused by merging flows. Compose & coroutines don’t make leaks go away, they’re just harder to detect.
🟣 How do you face a project of such magnitude? how do you plan your work on it?
I don’t think about the magnitude too much, I focus on making LeakCanary useful. If you’re hesitating to open source a project: just go for it! There isn’t much downside, in the worst case no one pays attention. I don’t do much planning: I go through GitHub notifications every few weeks, following up on issues, writing everything I’m thinking so that I can load up the context again later. When I’m in the mood, I make a batch of changes then make a release. I just started laying the foundation for LeakCanary 3, and I just work on whatever I think about, it’s fun! We’re expecting a 3rd baby in July and Square offers 4 months of paternity leave, so after a while I’ll probably scratch my programming itch by moving LeakCanary 3 forward in between 2 diaper changes. We shall see!
🟣 You are a family father like me. What do you think is the best from our industry when we have kids?
We don’t talk about family all that much in our community, even though most software engineers end up having kids! As we gain experience, a lot of the business value we provide has nothing to do with typing on a keyboard in an office during business hours. Healthy work environments are flexible on where and when the work happens and as a parent of young kids, that flexibility helps, and where our industry can really shine.
🟣 Apart from your amazing open source work, your role at Square is “Distinguished Engineer”. Is that somewhere above Sr. Staff Engineer? What does your work consist of on any normal day?
At Square, we don’t have titles. So people just make up their titles. After my last promotion, I decided Distinguished Engineer would be my title! My job is to support Square’s mobile organizations, and currently I’m mostly focusing on performance & reliability. My days are always different and never boring. Over time I got pretty good at identifying problematic patterns and iteratively crafting solutions, originally from a technical standpoint but today I also apply this to how our orgs work, to UX, product, etc. I alternate between writing guides and teaching, talking to many people to gather context on an issue, investigating complex bugs, helping teams work together better, writing tools, etc.
🟣 A remarkable number of key libraries of the Android ecosystem today were born at Square. The company seems to really support open-source work.
How does this commitment exactly work? is it part of the roadmap for the involved teams? is it like internal projects that you eventually ask for permission to make public? What is the company's goal for supporting open source?
Early on at Square our Android team hired a number of engineers with a strong Java background and experience open sourcing software. The Android Framework APIs were rough so we wrote the infrastructure software we needed, and we open sourced it. And we’ve kept doing that since. Square has no company goals, roadmaps, or teams in charge of Open Source: it’s an emergent property of our engineering culture, a practice that we nourish and celebrate. Our libraries are maintained by key individuals who care a lot, have deep expertise and make all the decisions. Square just gets out of the way: open sourcing raises the bar for the quality of the infrastructure software we write, it gets engineers excited, and it helps a lot with recruiting.
🟣 You post pictures of you skating sometimes. What other hobbies do you have?
During the pandemic, I rekindled my love of rollerblading when I discovered a new kind of practice: people dancing to music, on skates. I’ve been learning dancing & figure skating tricks and having a lot of fun... until I broke my fibula in January when twisting my ankle during a spin. I was lucky that it was a clean break, and I’m back dancing already! In the meantime I got really into baking, trying to make desserts that not only taste good but also look good. Check out these Android desserts!
🟣 How do you see the current state of Android development (i.e.: Android SDK, AndroidX libraries, etc)? What is something you think the Android teams should work on?
I love that Google doubled down on AndroidX, the teams are doing phenomenal work! One area where Google is under-invested is observability, i.e. the ability to track & understand the runtime behavior of our apps in production. The current stance is “every app is different so do whatever works for you and use vendors”. Leadership at Google seems focused on unambitious things like large screens, while completely missing that observability drives quality, especially as apps get more complex. Most observability vendors today come from a backend background and their mobile libraries are deeply lacking. And even if that wasn’t the case, Android lacks core observability APIs so implementations track the wrong things or resort to crazy hacks. JankStats is a timid first step in the right direction. My dream would be AndroidX libraries that do all the heavy lifting so that vendors could just focus on building backend services.
🟣 Tell us that story about when you stumbled upon a stranger in your house at midnight. Did it scare the hell out of you? 😱
Haha, I forgot that I shared the video on Twitter. I randomly stumbled upon someone stealing my bike from our garage. In the heat of the moment I didn’t think too much, they clearly seemed scared and just wanted to leave so I let them go after asking to see the content of their bag (which included a knife 😱).
🟣 How much is remaining of that little boy you were in your childhood, back in France? Do you miss him?
I still get lost in books, love assembling bricks (mostly software & tartlets), and say important-sounding things. I don’t know that I ever really made it into adulthood, I’m still very much that boy 😏.
🟣 Where can readers find you?
Skaters can find me in Golden Gate Park! And if you ever want to debate and bet a coin on dependency injection vs the service locator pattern, ping me on social media! All my links are at p-y.wtf.
🟣 Thanks so much for sharing with us Pierre 🙏 see you on the internets 🌏
If you want more, check all the interviews published so far 👇
If you like this content, consider subscribing to join the other 1700+ people that read it every day 🚀
Jetpack Compose and internals training
The current course edition is already 🔥 SOLD OUT 🔥 and running, but you can join the next cohort now for a reduced price and also get access to the Effective Android community for life. Find all the details here.
Compose animations training
I recently posted about how I loved Material 3 on Twitter. The tweet went viral 🔥
Many people seem to find it especially hard to replicate the UI / UX we see in those fancy videos from the official Material Design guidelines using Compose. Well, it can be done, and I will teach you. Register for this course if you want to become a master of Compose animations. There is an early-bird price for the first 20 🏃♂️🏃♀️🏃
These interviews are great reads, I am making a switch into mobile development and learning about these awesome people is so fun 😁