I quit Android Development after 10 years and what I plan to do now(levelup.gitconnected.com)
levelup.gitconnected.com
I quit Android Development after 10 years and what I plan to do now
https://levelup.gitconnected.com/why-i-left-android-development-after-10-years-and-became-a-backend-developer-86ebf3595d43?gi=879b0c1492c9
38 comments
The title says "Android Development", but apparently it's actually supposed to mean "Android App Development". Got me confused for a moment.
Android app development just seems like such a hodgepodge of tools. Keeping Android SDK/NDK, Gradle, Kotlin, and Android Studio (plus all the associated plug-ins for each) working well is a full-time job.
There seems an assumption in the article, that frontend/app development is less technical than backend development, and therefore not eligible for promotions. E.g.
> And honestly speaking, the skillset you develop are of lesser value for principal / staff software engineer positions in most companies.
As a principal engineer with experience in all of those areas, I don't think it's true. I actually think that the average backend development role is far less technical than app development. Most people there are just gluing together a database and an application framework on top of a webserver to build mostly stateless services. There's far less interactivity on the frontend, less concerns about multithreading, etc - which makes it actually easier. Same as on the frontend, the world's favorite framework also changes over the years and now some people use Go and Rust instead of Java servlets.
Both roles will have options to go deeper and wider. E.g. depth-wise, on the backend side some people might write their own webservers and databases, which requires an extensive amount of domain knowledge. On the frontend, some engineers might build libraries for realtime audio or videoprocessing. All roles will benefit from knowledge about debugging (and potentially debugging remotely and at scale).
There's also plenty of things to explore in terms of breadth. Backend developers usually need to understand the how dozens of backened services interact with each other, (continuos) deployment, metrics, alarming, operations, failure modes of distributed systems, etc. A lot of that also makes sense for Frontend/Apps.
And both sides obviously need to understand how the complete system works, and how it fulfills actual customer and business needs. The skillset for a staff/principal role is a lot about the latter: Helping the business and the team, by identifying gaps in and improvements for the product, and helping other engineers to implement it. It will in most cases be a wide role, with a bit more depth in one or the other area - and I would assume that can be either frontend, backend, security, or even something completely different. But it will almost never be a role which is purely about contributing code towards a small subset of the system.
> And honestly speaking, the skillset you develop are of lesser value for principal / staff software engineer positions in most companies.
As a principal engineer with experience in all of those areas, I don't think it's true. I actually think that the average backend development role is far less technical than app development. Most people there are just gluing together a database and an application framework on top of a webserver to build mostly stateless services. There's far less interactivity on the frontend, less concerns about multithreading, etc - which makes it actually easier. Same as on the frontend, the world's favorite framework also changes over the years and now some people use Go and Rust instead of Java servlets.
Both roles will have options to go deeper and wider. E.g. depth-wise, on the backend side some people might write their own webservers and databases, which requires an extensive amount of domain knowledge. On the frontend, some engineers might build libraries for realtime audio or videoprocessing. All roles will benefit from knowledge about debugging (and potentially debugging remotely and at scale).
There's also plenty of things to explore in terms of breadth. Backend developers usually need to understand the how dozens of backened services interact with each other, (continuos) deployment, metrics, alarming, operations, failure modes of distributed systems, etc. A lot of that also makes sense for Frontend/Apps.
And both sides obviously need to understand how the complete system works, and how it fulfills actual customer and business needs. The skillset for a staff/principal role is a lot about the latter: Helping the business and the team, by identifying gaps in and improvements for the product, and helping other engineers to implement it. It will in most cases be a wide role, with a bit more depth in one or the other area - and I would assume that can be either frontend, backend, security, or even something completely different. But it will almost never be a role which is purely about contributing code towards a small subset of the system.
> There's far less interactivity [than] on the frontend, less concerns about multithreading, etc
This really depends on a particular project a lot. Sometimes (often?) it's backend that does all the actual work, while frontend is just a glue for the user.
This really depends on a particular project a lot. Sometimes (often?) it's backend that does all the actual work, while frontend is just a glue for the user.
>just a glue for the user.
This is fairly contradictory. The reason gluing APIs together can be easy is because APIs are (usually) documented, mostly deterministic, have a limited set of operations, are designed to be glued to, and various other complexity-mitigating characteristics that don't apply to humans. "Gluing" with a human is intrinsically complex, so the way we use the word "glue" doesn't really apply.
This is fairly contradictory. The reason gluing APIs together can be easy is because APIs are (usually) documented, mostly deterministic, have a limited set of operations, are designed to be glued to, and various other complexity-mitigating characteristics that don't apply to humans. "Gluing" with a human is intrinsically complex, so the way we use the word "glue" doesn't really apply.
Some UIs absolutely are simple enough to be considered glues for underlying backend.
>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.
Is this true?
Is this true?
The reality is the path towards those levels require scope, and scope is rare due to prices law.
As a principal engineer, my greatest impact was selling stake holders on large projects which created a vacuum for people to level up on.
However, so many companies are highly constrained by either lack of resources or unimaginative leadership.
At those levels, it isn't about technical depth but organizational understanding and strategy to deploy resources.
As a principal engineer, my greatest impact was selling stake holders on large projects which created a vacuum for people to level up on.
However, so many companies are highly constrained by either lack of resources or unimaginative leadership.
At those levels, it isn't about technical depth but organizational understanding and strategy to deploy resources.
Ironically what has put me off was the way Android team deals with their Android Java flavour, how clunky NDK happens to be versus the C and C++ experience on Apple and Microsoft platforms, and that for most apps, the mobile Web is good enough for forms over data.
At least Chrome gets more updates than the underlying Android version.
At least Chrome gets more updates than the underlying Android version.
> how clunky NDK happens to be versus the C and C++ experience on Apple and Microsoft platforms
Also in 2012 there was just gcc support, and by 2015 gcc was deprecated for Clang, creating a lot of extra work for app developers due to that (technical? commercial?) decision.
Also in 2012 there was just gcc support, and by 2015 gcc was deprecated for Clang, creating a lot of extra work for app developers due to that (technical? commercial?) decision.
Officially it was technical, although I bet it was actually the same reason Apple got rid of GCC.
How does the rollout of Jetpack Compose compare with that of SwiftUI, any idea?
I bet our company's app on Compose (shipped with 1.0), and it's been a very positive experience. The teething pains were real, but with 1.2 most of them have been addressed.
The iOS devs I've talked to don't use SwiftUI because it's bundled with OS releases, so they have to use the lowest-common denominator of features for their minimum target. This is less of a problem as time goes on and the framework matures, but it has definitely slowed adoption as I see it.
The iOS devs I've talked to don't use SwiftUI because it's bundled with OS releases, so they have to use the lowest-common denominator of features for their minimum target. This is less of a problem as time goes on and the framework matures, but it has definitely slowed adoption as I see it.
Such a nice post!! Since 2017-18, even I have had the desire to jump into Android Dev, I tried a couple of times, but it couldn't hold my attention for more than a couple of weeks. Also, I think doing Mobile/Desktop development in general is a pain in the ass, as the platforms are very fragmented and they would never arrive at a single platform due to corporate interests. Since working n the industry, I eventually found out that I had more inclination for Backend/Systems Engineering stuff and look forward to develop my skills in these domains.
Don't let this dissuade you too much from doing something you're interested in.
I've been a "sysadmin" for 20 years, and just recently released my first iOS and Android app using React Native. Highly recommend it for cross-platform and code sharing, and it was quite enjoyable to do.
I've been a "sysadmin" for 20 years, and just recently released my first iOS and Android app using React Native. Highly recommend it for cross-platform and code sharing, and it was quite enjoyable to do.
This article really does bring up a valid point about the career path for mobile does seem undefined. How is one expected to advance into principal / staff as a mobile developer? While to do so as a backend dev, whose code affects all downstream, is much more clear.
I mean, they're mostly correct, but it's not like you have to be a "pure Android developer". I contribute to our backend all the time, but my primary role is still Android, and I hit staff pretty quickly. The mindset that you can only contribute to your functional domain is what keeps you from a staff position, and if you work at a place that doesn't share this mindset, there are always ways to contribute outside of your primary domain. It doesn't have to be code, either, and mobile engineers at the staff level should have pretty wide-ranging exposure to design, product management, systems architecture, etc.
I am also an Android developer for over a decade. One thing I dislike about Android development is the fragmented way to do things. There was the support libraries v4, v7 and now the jetpack or androidx.* libraries. My UI is composed of different namespaces like androidx.drawerlayout.widget.DrawerLayout and com.google.android.material.appbar.MaterialToolbar. This is just confusing.
Also you need to choose MVC, MVP, Viper, MVVM, AAC, RxJava, and now Jetpack Compose which completely is different compared to other architectures.
But nonetheless I am excited with Jetpack Compose.
Also you need to choose MVC, MVP, Viper, MVVM, AAC, RxJava, and now Jetpack Compose which completely is different compared to other architectures.
But nonetheless I am excited with Jetpack Compose.
> Also you need to choose MVC, MVP, Viper, MVVM, AAC, RxJava, and now Jetpack Compose which completely is different compared to other architectures.
Insofar as MVC, MVP, Viper, and MVVM - the vast majority of places I know of use MVVM. I can't think of many using MVC or Viper (a form of clean), and MVP is mostly used by older apps. Some places use clean architecture, which MVVM can work in conjunction with since the concentration is on different things.
Also most new projects I know of use coroutines and flow over RxJava, and plenty of RxJava projects are migrating to this as well.
Just like Clean can work with MVVM, so can Jetpack Compose - you just have a StateFlow (or LiveData) in a ViewModel with the UI model of the screen to display. So Jetpack Compose can work with MVVM, it is just a shift in thinking - and unidirectional data flow is being picked up for non-Compose Android projects too as it can make testing easier - instead of needing to fully rely on Espresso to test UI features, you can complement those tests with lots of JUnit unit tests on the UI model feeding into lean lifecycle components. Compose isn't different than MVVM, it can work with MVVM, it just modifies how MVVM is used.
Compose is also similar to reactive UI that other (non-Android) platforms use.
Insofar as MVC, MVP, Viper, and MVVM - the vast majority of places I know of use MVVM. I can't think of many using MVC or Viper (a form of clean), and MVP is mostly used by older apps. Some places use clean architecture, which MVVM can work in conjunction with since the concentration is on different things.
Also most new projects I know of use coroutines and flow over RxJava, and plenty of RxJava projects are migrating to this as well.
Just like Clean can work with MVVM, so can Jetpack Compose - you just have a StateFlow (or LiveData) in a ViewModel with the UI model of the screen to display. So Jetpack Compose can work with MVVM, it is just a shift in thinking - and unidirectional data flow is being picked up for non-Compose Android projects too as it can make testing easier - instead of needing to fully rely on Espresso to test UI features, you can complement those tests with lots of JUnit unit tests on the UI model feeding into lean lifecycle components. Compose isn't different than MVVM, it can work with MVVM, it just modifies how MVVM is used.
Compose is also similar to reactive UI that other (non-Android) platforms use.
I have over a decade of experience in iOS dev and I’ve learned that all of the architectures you mentioned except for MVVM are bad advice.
Clean Architecture is a terribly written book with generic, inactionable advice, and where it makes sense, it makes sense for server-side environments in Java, but would result in over-engineering for mobile OSes which have only become more and more tightly integrated over time, therefore encouraging necessary tight couplings in code (e.g. lifecycles of applications, views, and background and concurrent tasks). I’m afraid I don’t think that mobile developers who are advocating this approach are thinking very critically, and are instead imposing a silver-bullet architecture on problems, instead of letting the right solution or architecture emerge from the right problem.
MVVM is also just an augmentation of MVC but it is still inherently MVC—and especially in iOS, the “view model” is really just a model- instead of a view-controller—so I really don’t understand why there are ever programmers who talk about MVVM as if it is different from MVC.
Clean Architecture is a terribly written book with generic, inactionable advice, and where it makes sense, it makes sense for server-side environments in Java, but would result in over-engineering for mobile OSes which have only become more and more tightly integrated over time, therefore encouraging necessary tight couplings in code (e.g. lifecycles of applications, views, and background and concurrent tasks). I’m afraid I don’t think that mobile developers who are advocating this approach are thinking very critically, and are instead imposing a silver-bullet architecture on problems, instead of letting the right solution or architecture emerge from the right problem.
MVVM is also just an augmentation of MVC but it is still inherently MVC—and especially in iOS, the “view model” is really just a model- instead of a view-controller—so I really don’t understand why there are ever programmers who talk about MVVM as if it is different from MVC.
As far as I know, the biggest use of Clean Architecture in mobile is at Uber with the RIBs architecture, and it’s only applicable there because an app of that team size is closer to an enterprise Java server codebase. Most apps everywhere are not anything like that, and thus should not be using VIPER.
Speaking from experience where a team here has made a RIBS implementation. Stay away, keep it simple. Even at a fang size company it's not worth it
What's the size of the team/app? Really curious what companies out there besides Uber has used RIBS or VIPER. Not sure why they would do that either, other than it was trendy on some technical blogs back in like 2014.
Slack’s mobile team uses a variation of VIPER.
As a long time iOS dev who later took on Android, I share the frustrations of platform fragmentation and messy namespaces. I’ll also add that compared to iOS, on average on Android you’re reaching for third party libraries a lot more often which comes with its own set of frustrations. Not that iOS dev is perfect either, but as a whole I feel far more productive there than on Android.
Haven’t yet tried Compose but it seems promising.
Haven’t yet tried Compose but it seems promising.
I also develop on iOS and I agree with your comment. Example of this is iOS built in URLSession compared to Android’s deprecation of Volley so we have to rely on a third party Retrofit. The thought of that is just insane to me.
> third party Retrofit
For whatever historical reasons, there has been a flow of Android programmers from Google to Square (and from Square to Google). Square libraries are often written by people who came from the Google Android team. Dagger was written at Square but maintenance was handed over to Google. So technically Square's libraries are third party and Square gets some credit for it all, but it's not totally independent.
For whatever historical reasons, there has been a flow of Android programmers from Google to Square (and from Square to Google). Square libraries are often written by people who came from the Google Android team. Dagger was written at Square but maintenance was handed over to Google. So technically Square's libraries are third party and Square gets some credit for it all, but it's not totally independent.
Yes I wonder what’s keeping them integrating Retrofit to Android’s SDK.
Because bundling APIs in the SDK has traditionally led to more fragmentation, not less. Hence the androidx libraries and now Compose, which creates an API surface that mostly works without having to think about OS versions.
I talk with iOS devs often, and most of them do not use SwiftUI because the feature disparity is massive across iOS releases. Bundling features into the Android SDK would be about 1000 times worse because Android OEMs don't update their devices like Apple does.
I talk with iOS devs often, and most of them do not use SwiftUI because the feature disparity is massive across iOS releases. Bundling features into the Android SDK would be about 1000 times worse because Android OEMs don't update their devices like Apple does.
> I talk with iOS devs often, and most of them do not use SwiftUI because the feature disparity is massive across iOS releases. Bundling features into the Android SDK would be about 1000 times worse because Android OEMs don't update their devices like Apple does.
That's largely due to SwiftUI's newness and immaturity, though. Although UIKit gets major new additions each year it doesn't have that problem because all of the essentials have been in place for ages, which means when supporting older releases you can either just use the older APIs or use a combination of old and new with conditionals.
That's largely due to SwiftUI's newness and immaturity, though. Although UIKit gets major new additions each year it doesn't have that problem because all of the essentials have been in place for ages, which means when supporting older releases you can either just use the older APIs or use a combination of old and new with conditionals.
Even as a mere user, I don't think I've ever encountered two Android apps that quite looked or felt the same. It's such a janky platform...
> “The sad truth is that the path of an architect or principal / staff engineer is closed for a pure android developer”
When I worked at Uber as an engineering manager, this was partially the case: at Uber’s scale, there was a path to grow to Staff-level just with pure mobile, but it was a crowded place and difficult to get to as a mobile-only engineer expert in one platform only.
I encouraged native engineers wanting to get to that next level to go broader - venture into areas like iOS or web or backend, to become a more well-rounded engineer and ultimately someone who can lead and influence wider groups.
If you don’t work at a company with large mobile platforms, switching stacks to eg backend typically has more path for growth.
I also wrote a book called Growing as a Mobile Engineer where my advice is basically the above: to grow beyond the senior level, either you’ll need opportunities to work at places with large enough mobile scale - typically ones with mobile platform teams -, or leave native mobile to further your career.
When I worked at Uber as an engineering manager, this was partially the case: at Uber’s scale, there was a path to grow to Staff-level just with pure mobile, but it was a crowded place and difficult to get to as a mobile-only engineer expert in one platform only.
I encouraged native engineers wanting to get to that next level to go broader - venture into areas like iOS or web or backend, to become a more well-rounded engineer and ultimately someone who can lead and influence wider groups.
If you don’t work at a company with large mobile platforms, switching stacks to eg backend typically has more path for growth.
I also wrote a book called Growing as a Mobile Engineer where my advice is basically the above: to grow beyond the senior level, either you’ll need opportunities to work at places with large enough mobile scale - typically ones with mobile platform teams -, or leave native mobile to further your career.