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.
I quit Android Development after 10 years and what I plan to do now
31–39 of 39 posts
Re: I quit Android Development after 10 years and what I plan to do now
#32There 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.
Re: I quit Android Development after 10 years and what I plan to do now
#33The title says "Android Development", but apparently it's actually supposed to mean "Android App Development". Got me confused for a moment.
Come on
My day job involves working on an operating system for smartphones, so I may be biased, but that really wasn't obvious to me at first :P
Re: I quit Android Development after 10 years and what I plan to do now
#34There 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 ave…
> 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.
Re: I quit Android Development after 10 years and what I plan to do now
#35There 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 ave…
> 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.
>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.
Re: I quit Android Development after 10 years and what I plan to do now
#36>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?
Not at all, I work at a well-known company that has Staff and Principal Engineers for iOS and Android as well as backend.
and what will those Staff / Principal Android Engineers do if they quit?
Re: I quit Android Development after 10 years and what I plan to do now
#37Ironically 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.
> 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.
Officially it was technical, although I bet it was actually the same reason Apple got rid of GCC.
Re: I quit Android Development after 10 years and what I plan to do now
#38Re: I quit Android Development after 10 years and what I plan to do now
#39Earlier quoted context omitted.
> 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.
>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.
Some UIs absolutely are simple enough to be considered glues for underlying backend.