Effective Interviews ⚡️ Jake Wharton
Software engineer @cashapp / @square
⚡️ Welcome to the second Effective Interview ⚡️ a series of written interviews with well-known engineers from the Android worldwide community.
Subscribe to get them in your email 📩
This time, I have Jake Wharton. I doubt he needs an introduction, but still. Jake is a Software engineer working at Cash App. He is the creator and maintainer of many of the most widely adopted open-source libraries for the Android ecosystem. Ranging from good oldies like ActionBarSherlock, Otto, Picasso, Retrofit, or ButterKnife to more modern ones like Molecule, and also libraries unrelated to Android like Mosaic.
🟣 Welcome to the Effective Interviews Jake! 👋 it’s a big pleasure to have you here. Looking forward to knowing more about you 🙌
Thanks, and hello! I enjoyed reading Gabriel’s responses last week so let’s get to it and see what comes out below in mine. Also so sorry about building Otto.
🟣 What inspired you to become an Android Engineer in the first place, and how did you get started?
Money! But not the lucrative money of a budding Android job market as that didn’t exist yet. Instead, it was the money that Google was offering in the very first Android Developer Challenge coinciding with the release of the first public “M3 SDK” of this newly-announced thing called Android way back in 2007. This all happened in my junior year of college and I was determined to win the contest and never have to work a real job.
I decided to do a drawing application with shapes, brushes, layers, image import, etc. For how horrifically naive I was of the work required to build something like this I actually got really far along. Shapes, layers, blending modes, and images were all working after a few weeks. I spent far too much time cleaning up the code, teasing apart libraries, and optimizing the architecture, however, so the app itself was never polished enough to submit in the contest. (Good thing that won’t be a recurring theme that haunts me to this day!)
It would be two more years until I did Android again. I had jumped from Windows Phone to an iPhone 3G which meant my C# skills could no longer help me program my pocket computer anymore. I couldn’t afford a Mac and Windows Phone was clearly dying, so I started writing Android apps in the emulator.
My first app was called SMS Morse which vibrated your incoming text messages in morse code. I did not know morse code, but the fact that you could build something like this which was wholly impossible on Windows Phone and iPhone was amazing. The only way I could test it on the emulator was writing the vibrations to Log.d and praying the real API call worked. I charged $0.99 until I sold enough copies to recoup my one-time $25 fee to publish on the Android Market and then it became free. More on this app again in a second...
Next, I built an app called SMS Barrage which let you repeatedly send the same text message up to 1000 times to the same number with a configurable delay. This was so that when I attended Pittsburgh Penguins hockey games I could ensure my section would win any prize raffles decided by text message count (a thing they did back then). This app was quickly suspended for violating the terms of service of the Market. I found out that by installing a terminal on my jailbroken iPhone through Cydia I could send text messages from the command line (probably via some other Cydia app). So with a quick Bash script, I could still achieve similar functionality on iPhone although with a less desirable user interface. If you were in my section at a Pens game in those years: you’re welcome!
Anyway back to SMS Morse, the app had a loyal following of about 4,000 users. Low by today’s standards, but back then the Android Market’s size was only measured in thousands of apps–not millions. Google did an absolutely bonkers thing and sent every developer with an app in the Market which had 2,500+ users and a 3.5+ rating a brand new Nexus One. So SMS Morse ended up landing me a Nexus One and the timing meant I never upgraded to an iPhone 4. I’ve had an Android phone ever since, and receiving that Nexus One reinvigorated my desire to work on apps on the side and later to make the jump as a job.
🟣 How long have you been working as a software engineer? What stacks have you worked on so far?
I got my first job in 2009 at an international relocation company which helped move people all over the world, usually for big corporations. I spent the tail end of my college years getting good at C# and they were building a C# desktop application to manage everything. It’s hilarious to me in hindsight to think they were moving from a web application to a desktop application when they should have been doing the opposite, but back then just getting paid to do C# was the dream.
Weirdly, though, as the first year passed I ended up preferring the legacy Java server codebase. Everyone was so focused on making the C# desktop application work that I had a near-free reign on the Java server. I moved the company to git and GitHub added the Maven build system, switched to using dependencies from Maven central, and automated deployments to staging and production. It also meant a lot of freedom to experiment in all areas of the codebase. Later I spent a good chunk of my time over the course of the final year migrating from dedicated servers to virtualized infrastructure on VMWare vSphere. It was a lot of fun to get to work on wildly different aspects of an operation.
Through rediscovering my passion for Java at that job and having moved our infrastructure to VMs which had no mobile app to control, I started building an app for it on the side. My vSphere Android app may have never materialized, but ActionBarSherlock was born from that project. That library got me the Square job in 2012 and solidified that my foreseeable future would be spent doing Android. Other than small personal projects with Rust or Docker or Raspberry PIs, I’ve been first and foremost an Android developer ever since.
🟣 How did you start with open-source? what did you find interesting about it?
Just like Gabriel I had TI-83 in middle school and taught myself TI Basic to build apps which would help me on tests. Games like Drug Wars (lol) were becoming popular and were distributed person-to-person in source form which was a great learning tool. In high school, I discovered ticalc.org (which still exists?!?) where I could download and collaborate on others’ apps but also publish my own. I had no idea what “open source” was. It just felt like a superpowered version of the person-to-person sharing.
Throughout both high school and college I was participating in the open-source communities of the software that I was consuming but not publishing anything. I was on a small team that ran LAN parties and so we deployed a lot of Linux and support software for running registrations and matches. I helped run university-local torrent trackers and DC++ hubs for the distribution of… uh… let’s say Linux ISOs. The TVs and computers of everyone who stayed in our college houses all ran VLC and MythTV to access a group samba share. All of that software was open source. We knew enough to be dangerous, but you inevitably run into problems beyond your ability. Participation in those communities was simply because you wanted to try and get your problem solved. It wasn’t out of some philosophical belief in open source. But open source meant I had access to a wider range of people from which to get help, and to occasionally also help others.
GitHub was around by the time I started that first job and I had migrated projects like SMSMore, SMSBarrage, and some other things from a private SVN server to it. I had published some small projects for no good reason other than I saw no reason why they should be private (and probably didn’t want to pay GitHub for private repos). When I started the Android vSphere app I pulled in a ton of open source projects from GreenDroid to Apache commons to an XML SOAP library and more. I got the basic parts of the app working and not looking terrible in like a week which otherwise would have taken months. So when it came time to write a shim between the newly built-in `ActionBar` in Honeycomb on my XOOM (🤦) and the GreenDroid action bar for Gingerbread on my Nexus One I didn’t think twice about it being open source. I thought I could pay forward the help those projects had given me to a few other people with similar needs. Or, as it turned out, many, many, many other people.
I’m sure some would say that I’ve helped them more than they’ve helped me by doing all this open source. But due to the weird economics of the scale of open source, I don’t actually think that’s true. Open source is a cost, but it’s a cost on top of the bulk of the work that otherwise would already have to be done. And so you’re really only weighing that added cost against the benefit of contribution and collaboration with more people than just yourself or your paid employees. In both my personal projects and those I’ve done at Square, Google, and Cash App we have received some epic contributions that I know would never have happened otherwise. Getting those contributions on our projects, being able to give contributions to others, and just generally collaborating with a wider audience to build a better library is not something I would trade away.
🟣 Open source projects can be very draining. People are not always very empathetic with open-source maintainers. How do you manage to stay motivated?
A lot of the motivation behind an open source project I’ll do comes from pure selfishness. Like, I want the thing to exist for my own use and not for the betterment of the community or whatever. This already helps immensely as I’m not striving to appease anyone but myself. It’s still fun when others join in and you get to share working towards a goal, but it helps to not feel so obligated by others.
As for the entitled subset of users whose bugs contain no actionable info but need a fix ASAP and whose feature requests treat you as if you were a subordinate employee, well you have no choice but to learn how to empathize and/or how to ignore. Otherwise, they’ll overwhelm you. The best you can do is try to set expectations upfront and stick to the parts of the project that are fun for you. It’s meant to be fun. If it feels like a burden then something needs to change.
🟣 How do you come up with new ideas for libraries to create?
It’s 100% based on some recurring problem that I have or we’re having when building an app or while building another library. We never set out to build a library for the sake of building a new library, and we aren’t trying to solve the problems of others. There’s no hard rule on what works, though. Over time having worked on so many, you get a feel for what would make for a good reusable tool vs. something that feels too specific. But sometimes we open source the specific thing just because it’s interesting.
🟣 Do you find OSS work rewarding? What learnings would you highlight from it so far?
It’s certainly nice to see the work being able to benefit more than just ourselves. It also affords us the chance to collaborate with many more people than we otherwise would get to work with professionally.
I think the most important thing we’ve learned over time is to keep the library small and focused. Jesse Wilson and I gave a talk on open source once and one of his great gems of wisdom is that we want to include only the code that everyone needs and exclude everything else. Because that 15% of extra code that you want is a different 15% than the next person and the next person. When you try to include all of that you wind up with these massive libraries that are hard to iterate on.
🟣 What is a big challenge you frequently struggle with when working in open-source libraries?
So in addition to just keeping the library small with only the code that everyone needs, the biggest struggle is designing the API in a way that often the user can help themselves solve their specific problem. Examples that come to mind are OkHttp’s interceptors, Moshi’s JSON adapters, Retrofit’s converter and call adapter factories, and SQL Delight’s column adapters. These are APIs that let you extend our libraries in a way that we could not foresee, and in a way that we don’t have to expose a million knobs for customization. With a really well-built core set of APIs and the right hook into which users can insert behavior specific to their app the library becomes a much more powerful tool.
Unfortunately not every library is going to be conducive to having these powerful user hooks. And that’s okay. In order to keep the library small and focused you have to face the second biggest challenge: the will to keep saying “no” to scope creep.
🟣 After a really long time working at Square, you switched to Google, but then you decided to jump back. It was an interesting move from the community perspective. Can you share more about this?
On Cash App, we had been pushing Kotlin on Android hard since about 2014. At the time I didn’t care whether Android would officially support it or not. The death of the Jack compiler meant Kotlin was always going to work on Android (and even if it didn’t, Jill had our backs). I was only an advocate that they test Android Studio and the Android Gradle plugin with a Kotlin project to try and not break the integration as often.
In the months leading up to Google I/O 2017 where Steph made the epic announcement that Kotlin would be added as a supported Android language Romain Guy reached out to let me know that this was possibly going to happen and that there was a potential role for someone to help build whatever Kotlin on Android would look like. Things were great on Cash, but that’s an opportunity that doesn’t come around often.
I flew to Google a week before I/O to interview. Romain came to pick me up that morning in the lobby to escort me inside. As we were about to enter the security gates, Steph and Maxim Shafirov, the CEO of JetBrains, were walking out of them. Steph and I knew each other from this advisory board thing Google sometimes does, and Max and I knew who each other were because of the Kotlin work we did at Cash. We both knew exactly why each other were there, but we were separately NDA’d and standing in a public space. Some awkward “hi”s and “bye”s were all that we could manage and maybe an all-too-knowing “good luck”.
In addition to the interview, a month before I/O I was asked to give a talk with my friend Christina Lee who had also been a big proponent of Kotlin to help lend community credibility. Despite the interview and us preparing this talk, we didn’t find out that the launch was actually going to happen until the day before the I/O keynote.
So I took the role and it felt very natural. I had three years of pushing Kotlin as an Android developer and a laundry list of things I would build if I were Google. Well, I was now Google, and so I just did those things. Style guide, the KTX libraries, nullability annotations in the framework, parcelize work, R8 work, view binding to help kill synthetics (sorry not sorry), and more. In that time, and in the time since I left, many people helped make the language successful within Android and have contributed more than I ever did. Really my greatest success was being one of the tiny dominos at the beginning allowing much larger and greater ones to fall after.
I wanted to stay for two years and then flip back to use what I built. I can’t build tools and libraries outside the context of real-world usage. Some people can, and others seem to think they can. I find you lose too much perspective on the actual problems and whether you’re adequately solving it.
I also started to run into too many limitations both bureaucratically and technically. Whether to make Kotlin the main language or not took months of eye-stabbing meetings only to land on this ambiguous “Android-first” term. Whether to support Kotlin multiplatform took months of other-eye-stabbing meetings only to land on a maybe. I prototyped a port of the collections library to Kotlin multiplatform but Android only builds on Linux so there’s only Linux CI runners. Now what? And since the git repo lives in AOSP the AndroidX team inherits the practice of checking in all of the toolchains and dependencies which becomes dramatically more complicated with multiplatform. It’s been three years and there hasn’t been enough movement.
So much of AndroidX is held back by still living in a monorepo, living in AOSP, using the Android OS’s CI system, and being gatekept by infrastructure which only exists to try and work around the first three things in this list. There’s myriad leafs within the AndroidX tree that would be better suited in their own repo on GitHub. You only have to look at the KSP project for a glimpse of how every AndroidX library/library group could be developed and released. Ugh, it’s hard not to endlessly rant about this because it was frustrating then and remains so to this day. This section is getting really long so let’s end it. Also #FreeCompose!
My parting message when I left Cash was “I’ll be OOO for a few years”, and so after 2¾ of them, I went back to enjoy the fruits of my Google labor.
🟣 What is your current role at Cash App? how is a normal day at work for you?
My primary responsibility is the Redwood project, which is a multiplatform Compose runtime that targets the native UI toolkits of each platform it supports. This allows us to write common Compose code that runs on Android, iOS, and the web while targeting Android Views, iOS UIViews, and the HTML DOM. It also does not preclude the use of Compose UI or Swift UI.
While Redwood can be compiled natively to each platform, we have another project called Zipline I help maintain which embeds the QuickJS engine into our Android and iOS apps. Zipline basically lets the Kotlin/JVM and the Kotlin/Native inside a host application transparently talk to Kotlin/JS code running inside the JS VM using kotlinx.serialization to cross the boundary. And inside the JS VM is now where we run Redwood’s Compose code. The output of the Compose, a series of granular diffs for the UI, is sent to the host application and applied against its native UI toolkit in real-time.
It’s a really cool setup because we can update the Compose code in only a few seconds during development, but also publish updates to apps in the wild without going through the app stores.
Aside from those two primary projects, we have other smaller projects like Molecule, Turbine, Licensee, Retrofit, and SQL Delight that I either maintain or help maintain with many other talented folks. While we have a lot of code that integrates all these projects internally, I’m still very lucky that the majority of my work time is spent on open source projects.
My days aren’t super structured. I usually spend an hour or two in the morning triaging internal and external issues and pull requests that have come in. The rest of the day is a mix of picking off a few small tasks I can complete in their entirety vs. making incremental progress on whatever large overarching task we’re working towards.
🟣 You are a family father, like me. Do you feel like your life priorities changed a lot after having kids? Did your perspective on life change?
I’m not sure my priorities have really changed. It did change my perspective to have this otherwise helpless thing become intrinsically attached to you. Their success in the world, at least initially, is tied to your actions. It can be humbling, challenging, fun, and extremely exhausting. Ultimately it’s pretty hard to screw up, but I try to keep learning on how to be better at it.
🟣 For the parents out there - Having kids is absolutely incredible in many ways, but truth be told: it requires lots of time. How do you manage to stay performant?
Well if our back-and-forth about my progress on this interview is any indication then maybe I haven’t!
It certainly is a juggling act of increasing complexity. Time has become a much more valuable resource than it ever was before. As a result, I am fairly ruthless in protecting it from others. I have very few recurring meetings–only the most essential things directly related to my work. Unfortunately, we use Slack at work so I just keep it closed 90% of the time. Even when Slack is open I really only check about three rooms.
The easiest way to get my type of work done is to be unavailable for large blocks of time where I can just focus on the work. Between those blocks of time is when I check issues, pull requests, and the nightmare of Slack to make sure no one is blocked on me. I’m constantly trying to manage the expectation that my availability is asynchronous. But equally as important is messaging that my reliance on others for things like replies and code review is also asynchronous.
For working on side-projects I simply try to bite off smaller chunks. Taking five baby steps towards something over the course of a week is better than failing to make a huge jump five times. It also really forces you to consider which projects get your time and whether they’re worth your time. Given unlimited brain power and time then yeah sure I’ll pursue every random side-project that pops into my brain. But when your mornings and evenings completely disappear and the need for good sleep has gone up, those fleeting two hours you might suddenly have on that day goes up 10x in value. Spend appropriately.
🟣 Your career path until today. If you look back now, would you change anything? What would be some advice you would give to your younger self?
I thought about this question for a while. I used to tell myself that I would have moved to San Francisco earlier since I enjoyed that time so much. Or that I should have started Android development professionally sooner. Or maybe even that I wouldn’t flip over to work at Google.
Anymore my answer is a simple “no”. I wouldn’t really change anything. I’m in a place where I’m really fortunate to work on fun things with good people and that’s a result of everything that came before and a whole lot of luck. Why mess with it?
For advice, I think when I was younger it was easier to get swept up in believing in a product vision too much. As a result, your own feeling of accomplishment can get tied to the ups and downs of the product. I’m much more focused on the people around me and finding challenging technical problems to solve now. Products are fleeting whereas those things endure, and it’s far easier to find reward in them. Realizing that sooner would have been nice. I still care about the product a little, but now only transactionally in a way that Don Draper would approve of: “that’s what the money is for!”
🟣 Did you take any manager roles in your career? Did you like it? If you did, would you recommend people to try it? From the outside, it looks like you’re probably a great Individual Contributor.
The closest that I’ve come to managing someone is taking on an intern for a quarter. Nobody told me I was getting an intern until the first day of their arrival at the office. Surprise! Two weeks into their stint, the prototype product we were working on was shut down and we were left in limbo for a few months with no real work to do. Double surprise!
I suggested that this person take a look at all of the existing database libraries for Android and compile a report on them. On the next project we worked on we could then decide which one to invest in, or whether to build our own. That was in 2014. SQL Delight, the best database tool for not just Android, is the result of that effort. It’s hard to imagine a greater success for me having done so little.
Alec, the author of SQL Delight, eventually joined full time. He is an actual manager now doing actual real managerial things and making mine and my coworkers lives much better. He also still keeps SQL Delight awesome, along with a bunch of really other great contributors.
It’s hard to see myself managing others, but I don’t completely rule it out as a possibility long-term. For now, I’m more than happy being an individual contributor.
🟣 What do you enjoy more, platform or feature teams?
I enjoy platform work in the context of feature teams. I’m not here to solve problems in academic-like isolation and then throw it over to a feature team to deal with integrating. Even now that I’m on a platform-like team we still own the shared spaces of the app which are themselves considered a feature. This means we support ourselves directly in building those shared spaces, but also that every feature must integrate with us to be displayed and thus also use what we’ve built.
🟣 Dagger 1 vs Dagger 2. Which one do you prefer in terms of features/flexibility?
I think both were the right choice for their time.
Dagger 1 got us off Guice which was so slow and only getting slower as our app grew. But more importantly, it demonstrated compile-time graph validation was an essential feature as graph sizes and team sizes grew. Like Guice and many other injectors, Dagger 1 was built on top of a service locator with which it performed the automatic dependency injection. This has severe limitations about what can be optimized at compile time and runtime.
Dagger 2 came with the novel ideal of computing the entire graph at compile-time and generating direct links between source and usage. It was fast as hell as a result, and since it’s otherwise normal looking code so much of it could be optimized away.
In the larger community, I think both suffered from the bad architecture guidance and libraries of Google. None of their stuff is built for inversion of control and their API design encourages layering violations. Dagger, or any dependency injector, works best when used with clean layering and relatively plain objects encapsulating behavior. Those then can be injected and wired into integration points like the activities and fragments of the world. If you’re actually putting logic inside an activity and fragment and not glue code, you’re going to have a bad time. You know what’s easy to test? A constructor-injected POJO with a lifecycle you can drive. You know what isn’t easy to test? A fragment that member injects itself by reaching into the enclosing activity and wants to also display UI. Yuck.
Nowadays I hope people are using Anvil. Or Hilt, if you must. But it really should be Anvil.
If you’re a fan of automated dependency injection but fancy yourself some Kotlin multiplatform be sure to check out Eva’s kotlin-inject project.
🟣 Any project coming up that you’re really excited about?
Zipline is currently based on executing Kotlin/JS in the QuickJS runtime. We do a lot of tricks to make this execution as fast and efficient as possible like actually using a QuickJS-internal bytecode instead of actual JavaScript source. But we’re ultimately held back by Kotlin/JS’s lack of support for ES2015 output and JavaScript’s lack of a 64-bit integer type.
With Kotlin/WASM coming online, we’re eager to start testing out the switch to a WASM runtime instead of a JavaScript one. WASM can run in all the same places, but being a native bytecode format the opportunity for efficiency and optimization are that much greater than a text-based format. And because Zipline already hides the JS behind Kotlin interfaces, a switch to WASM bears no impact on how you use the library (just how you load the code).
🟣 What other hobbies do you have? I think I’ve seen you posting stuff about cars sometimes.
Yeah, I’ve been into cars and racing games since college, but it never quite dawned on me until recently that nothing prevents me from also doing it in real life. I attended a BMW 2-day M school with some Android friends a few years back and that has led me to now having both a street car that I take on the track and a dedicated track car. I’m currently just doing a few open track events and high-performance driver education (HPDE) events a year for now. Once the kids get a little older I may go for a competitive race license, but it’s plenty fun racing against your own times for now.
Aside from that I consume my fair share of movies, TV, and books. Ceding control over the narrative and pacing of something is such a refreshing change from programming which feels like the complete opposite. The last movie I watched was The Lobster, the current TV show is Arcane, and I’m reading Dune Messiah.
🟣 What is your opinion on meetings?
Meetings are a great way to move progress forward on a project with synchronous discussion and decisions. We occasionally have these epic meetings about open source where a bunch of us plan out a ton of work and coordination that has to happen and then we go and execute on it for the next six to twelve months. These are great because they’re rare and everyone is motivated to make them as useful as possible. In that time between, individuals coordinate and communicate mostly asynchronously.
In stark contrast, there are also a lot of scheduled, recurring meetings which undermine how effective a good meeting can actually be. And it’s not like nothing good ever comes from those meetings–it can. But those types of meetings rarely go away and instead accrue on your calendar like stains you can’t wash off. Instead, we go through the motions hoping this will be the one that pays off rather than feels like a looming interruption throwing off hours of your day despite being only 30 minutes long.
I prefer to collaborate as much as possible asynchronously. That’s long-form discussions, issue trackers, pull requests, and the like. It shouldn’t matter if you’re across many time zones, coming back from a long vacation, or have sporadic availability daily because of other life responsibilities–everyone should feel included and able to participate.
Some short-form communication can be okay, but you need to facilitate it with good tools that surface active discussions and allow grouping and rearranging as topics shift. Unfortunately, we use poorly-designed short-form chat tools like Slack that are nary more than linear chat with lazy threads. You really see tools like Zulip shine here in the Rust and WebAssembly communities and I wish it was used more.
🟣 This is a question I like to ask, now that I am writing a book about soft skills. Many people hide the fact that they face burnout. Did you ever experience burnout or some of its symptoms? How did you combat it? Do you have advice for this?
Definitely symptoms, but never a hard burnout on anything.
I have three tools that I use:
I always try to have more than one thing that I can work on at any time. And it can’t be a simple thing, like just another task within the feature I’m working on. Something that’s a hard left turn. Our culture and the things we work on affords me that privilege. There’s so many different libraries, languages, and platforms in use that I can jump around for a few hours, a day, or sometimes even a month to keep being productive. Unfortunately, the ability to do this simply does not exist everywhere. It takes a long time to build up this as something you can leverage.
At least prior to kids, I try to work flexible hours based on how I’m feeling. A lot of programming is a creative endeavor and it can be hard or simply impossible to force that. In fact, by trying to force it you might be doing more damage than good. Walk the dog. Go see a movie. Play a video game all day. Do this during work hours and don’t tell anyone. If you’re in the zone, however, then go ahead and work twelve hours straight. Just be sure to balance that out by not working the next day or something. Only you can really effectively manage you, but a big part of this is ensuring that your employer stays happy in your work and coworkers are satisfied with your availability.
Finally, bank easy tasks for a rainy-day-like fund of things you can do to remain productive but without requiring a lot of hard work on your part. This can be used so that others see you as productive while you mentally unwind. It can also be used to help you regain a sense of progress after feelings of burnout. Use it how you wish. The hardest part here is finding the right tasks that you can pull off but aren’t such low-hanging fruit that they disappear by the time you need them.
I’m sure someone will read those and say “WTF I can’t do any of those!” and that’s sad. It means the culture and environment around you may be setting you up for burnout, and no amount of tricks from me or anyone else might be able to stop it. Or maybe you simply work differently than I do. After all, if there were a silver bullet it would not be such a recurring problem in our industry.
🟣 Not sure who doesn’t know already, but. Where can readers find you?
I’m on Mastodon at @jw@jakewharton.com or come see me in person at KotlinConf in a few weeks!
🟣 Thanks so much for sharing with us Jake, it’s been great 🙏 See you around! 🙋♂️
More interviews lining up already 🔥 if you want more, check the last one published, with Gabriel Peal:
The limited course offer 💸
We mentioned Jetpack Compose in this interview. If you are interested in mastering Compose, you might be interested in the latest offer for a slot in the next cohort-based course. Starting on May 1. Please use the link in the following post.
More interviews lining up 🔥
If you like this type of content, consider subscribing to this newsletter and joining the other 1200+ people that already read it every day 🚀
You can also consider following me on Twitter 🐦 and Mastodon 🐘