Why I quit Android Development after 10 years and what I plan to do now

In this article, I’ll talk about why I left Android Development for good, after working for almost a decade in the industry. Before I start, let me tell you something about my career in this particular field.

Good ol’ time

I started in 2013 with Android Development, when Android 4.4 was the hot new thing. When AsyncTasks were still the standard, when we had OttoEventBus, and other horrible things. I witnessed the architecture trends going from MVC to MVP / MVI, then moving to MVVM, and finally having a mix of MVVM / MVI.

I remember when RxJava was the new thing on the block, everything was suddenly reactive and a stream. I remember the l33t Android Devs (Hi Jake Wharton) talking about that new underdog language called Kotlin. I remember Kotlin raising up and taking over the Android industry. I remember Coroutines popping up and at first appealing to be the big “RxJava”-Killer (Hey, you can write now all the async code in a sync way! No need for streams!). Charming idea, yet it turned out quite fast to be just a nice idea. Therefore low-level async primitives such as Channels became the Rx-Way for Kotlin. Oh hey, turns out many people are shooting their legs away with Channels. The idea of lean Cold Streams and Hot Streams had to be re-introduced, may I present you: StateFlows and SharedFlows. In the end, we’ve got a light, Kotlin idiomatic version of RxJava2 with Coroutines support.

I remember having all the fun conversations with my colleague David about States and Events. What is exactly a State and what is an Event? What does an Event do to the State and Vice Versa? I remember staying up the whole night to learn Dagger 2, years before it got replaced by Koin and Dagger Hilt. I remember reading Clean Architecture by Uncle Bob for the first time, one of the most eye opening moments in my Android Dev career. Now I was able to design and write almost all Apps without having to think about MVVM/MVP/MVC or any other platform specific details. I learned why testing is important, I tried TDD and loved and hated it. I learned about DDD and BDD.

Has my train reached the final station?

(I picked this subtitle because I am writing this article right now in a train that goes from Switzerland to Germany)

With time, I suddenly was in a position where I lead teams at big enterprises such as Porsche or IBM. It was a great ride, though I felt like after 6–7 years of experience I reached what I wanted to reach. I worked on complex applications with heavy E2E encryption, communication with sensors, NFC chips, BLE beacons, high traffic chat applications and not to forget apps such as the legendary todo list apps.

After ~6 years I started joining projects as a lead android developer. I learned to identify the core technical problems most projects I’ve worked on suffer from (architecture and team members having different understandings of certain patterns). I learned how to teach the team enough to solve those issues and how to finish projects successfully. Everything new that was waiting for me now was learning new API changes / frameworks to solve the problems that we’ve been solving for years already. Only that this time the new framework / api handles it better (no more manual lifecycle handling, handling of fragment transactions, XML layouts, …).

My previous Backend experience

I had the fortune that in my last 4–5 years I was able to work on the backend side of my customers projects (upon request). I spent a lot of time to understand the ins and outs of backend development, writing concurrent code, creating a distributed system, scaling vertically and horizontally, handling distributed transactions, writing configurable code that behaves as expected on different environment stages, different types of databases (graph, relational, document) and what database should be used for what kind of data, docker and k8s. I refactored Java EE systems into Go. Looking at the resulted binary that is compiled by Go, its memory usage and almost non-existing memory footprint I understood why Go is so amazing. The problems I’ve been solving as backend developer were not to compare with the challenges I’ve had on Android (I’ll talk about them shortly). The problems I’ve been solving as a backend developer had a bigger and deeper impact than pushing around pixel on Android.

Really Android, that’s it?

Eventually, I became tired of all the meetings with UI / UX Designers and explaining the fundamentals of Material Design or why we can not trigger “just like that” behavior X in application Y, which was not done by us. I remember talking for hours about designs which lead to my brain eventually shutting down. This happened at multiple projects, of which some held a certain degree of complexity.

Once the team understood Clean Architecture and Domain Driven Development, we managed to write the domain + data layers within very short time. Once you demystify the different auth flows to the team, handling proper token refresh logic becomes a piece of cake.

The main challenge becomes almost always the UI Layer, which changes continuously due to evolving framework API changes. The UI Layer was heavily influenced by the UI / UX Designers + POs. Lately, almost all of my projects converged into day to day job where it was less about engineering, but more about business and then execution, which was almost always playing around with the Android API. In the best case, you’d have a refreshing task such as writing a custom View and use some linear algebra but in general — almost always — it was something dull. Reflecting all of it I ask myself: What’s in it for me? I made good money — sure. But I am about to become 30 years old, where do I see myself in the next years?

As an experienced Android Developer, I’ll only be usable for Android Positions. All my skills were built around developing maintainable, clean code that works correctly on the Android Platform. Code that gets killed by the Garbage Collector as expected and Code that survives it because it’s intended to do so. What if Android should vanish soon? Looking at great technology such as Flutter, also having worked on some great Apps with it, I wouldn’t start any new project as separate native iOS and native Android applications. And honestly speaking, the skillset you develop are of lesser value for principal / staff software engineer positions in most companies.

Sunsetting Android Development

I finished my last project with success but it was now time to change something. I no longer wanted to be in multi-day discussions about CardView borders or recurrent non-sense such as whether we use radio buttons or check boxes. I no longer wanted to learn new android libraries to handle the android lifecycle better or handle navigation just so they get replaced again within the next 12+ months. I’ve done this several times already within my last 10 years . Every new generation of developers brings new developers that feel like they have the calling to write a new library to handle your UI state or a new navigation library. Tests? Nope. Sadly, there are many developers who pick those libraries up. Android development is slowly being absorbed by the chaos that swallowed web development (Have you tried installing create-react-app? You’ll download thousands of libraries, including some vulnerable ones).

Luckily, I worked on the backend side on several projects in my last years which put me into a position to transition into Backend development. The idea of leaving Android for good and focusing now on developing systems that handle hundreds of thousands of users per second became very charming to me. There are now new things on the roadmap that I had not as a capped-out android developer: Get k8s certifications, become a master of multiple clouds, learn the inside-outs of specific databases, become profound in DevOps. I feel like the mystery of programming has sparked me again, there are complex engineering problems to master — and this is exciting.

The sad truth is that the path of an architect or principal / staff engineer is closed for a pure android developer. The pure android dev simply won’t have the required skills to fulfill those positions. It was a great ride for me, but I’ll never work on a project as android developer again.

Dear you, thanks for reading this article. I would love to hear your opinion in the comment section

Feel free to hit me up on Twitter

Level Up Coding

Thanks for being a part of our community. More content in the Level Up Coding publication. Follow: Twitter, LinkedIn, Newsletter.
Level Up is transforming tech recruiting ➡️ Join our talent collective