Thread by @championswimmer

1/ So it has been 9 years now I am tinkering with Android, and close to a year working at @Zomato - an app with 100M+ downloads and close to 5M active users on most days. Here is a 🧵 thread 👇🏼

@Zomato 2/ There have been multiple learnings, re-learnings, obliteration of firmly-held-on practices over the years. The differences between working on 6 month old codebases and 9 year old ones, and between 1-screen apps to 50-screen ones.

@Zomato 3/

First of all, the concept of "at scale" on frontend is always very different from backend. You are not spinning up AWS instances here as the traffic hits. But scale matters here. Especially when you need to support 500+ different devices from 50+ OEMs.

@Zomato 4/ Also the "scale" of the codebase matters. If you are working on 3M LoC project, no one person has visiblity of everything, everything very fast turns overwhelming.

@Zomato 5/ When StackOverflow founder @spolsky said "Never rewrite your codebase", he wasn't kidding.
joelonsoftware.com/2000/04/06/thi… .

@Zomato @spolsky 6/
The older the codebase, the more the number of people who have had been contributors to it, the more impossible it is to actually ever rewrite "everything" and ever get finished.

@Zomato @spolsky 7/ Every once in a while there comes that "big rebranding" or that big 1.0 version update that aims to "change the whole app". As engineers everyone starts salivating at the prospects of a rewriting, because everyone is tired of *this shitty codebase*.

@Zomato @spolsky 8/ If you are an EM, TL, #resist. Do not give in to this.

The codebase, even if 10 years old, isn't *entirely* 10 years old. It is a ship of thesus, being rewritten in parts and pieces over the years.

@Zomato @spolsky 9/ Even if you want to revamp the entire user-facing part of your app, you'll still start off with copying entire modles like your analytics lib or your network lib. So it won't even be a rewrite 🤷🏻‍♂️

@Zomato @spolsky 10/ The other big problem, especially with bright and young (but not battle-worn) developers, is the "shiny new thing" syndrome. Please go with "tried and tested" over "latest and greatet" 10/10 times.

@Zomato @spolsky 11/ Keep working on small side projects to stay abreast of everything by using them in your small projects. RxJava, Kotlin, Arrow, Flow, Coroutines, Dagger, Koin - being aware, and having used all of this is a great asset for any developer.

@Zomato @spolsky 12/ But for big projects, the single greatest strength is the *absence* of too many dependencies.

@Zomato @spolsky 13/ If your users are in tens of millions, please just stay away not just from betas and alphas of any tools & libraries, but also from the latest version. Be 1 version behind the latest stable release.

@Zomato @spolsky 14/ You are simply at a scale where no one else most likely has used those libraries/tools before. The author of those libraries/tools has not yet fathomed as many corner cases as your app will expose it to.

15/ Also remember there are never any "silver bullets", and *abstractions have costs*. These days coroutines are the new thing being touted as "silver bullets". They aren't. Everytime you encounter a line of code that doesn't update the UI, do not blindly dispatcher.launch{} it

16/ There are lots of tasks that will take 1ms on main thread to perform, but the overhead of the coroutine mechanism to dispatch your work on a different thread and maintain the safety mechanisms of scopes, will hit your main thread by 5ms.

17/ In fact if we are discussing Kotlin - please inculcate the habit of frequently viewing your Kotlin bytecode and the decompiled Java counterpart whenver you write Kotlin files. There are often dragons in the Kotlin desugaring to be aware of.
For eg: jakewharton.com/public-api-cha…