Coinbase rewrote both their Android and iOS apps in React Native, and are happy with the end result.
My takeaways from their writeup (thread)
1. It's hard to hire good lots of native mobile engineers. Heck, this is what was probably a major trigger for their whole transition
1. (Cont'd) Coinbase had a strong React team, and not enough native engineers... and thought they could solve two problems at once. Fewer engineers, higher efficiency. blog.coinbase.com/announcing-coi…
Sounds like they might have succeeded with this (at least for now)
2. It takes a *lot* of investment to ship any mobile app at scale, RN not different. This is a post from Nov 2020 on the performance challenges their team needed to solve: blog.coinbase.com/optimizing-rea…
3. RN is not a great choice to build cross-platform *features*: it's no alternative to e.g. shared native code via KMM or C++. If you do it, going all-in is what makes most sense.
4. You can make any technology work at scale if you have enough resources (people) to iron out its kinks. PHP to run for billions? Facebook ✅quora.com/Is-Facebook-st…. RoR at scale? Shopify ✅
Coinbase did a LOT of under the hood work with RN as well.
5. Choosing a mobile technology will significantly impact who you can (and want to hire).
Airbnb saw they were able to attract fewer native engineers & this was a contributing reason they eventually went back on RN as well medium.com/airbnb-enginee…
For Coinbase: not an issue now.
6. What do I think about the "best" mobile technology to choose? Full native? Flutter? React Native? Kotlin Multiplatform? RIBs? Something else?
I cover all these in mobileatscale.com (free as a PDF for another 2 weeks).
It's all tradeoffs: just like on the backend & web.
Tell me which is the "best" backend technology to build at scale. Go? Java? .NET? Node? Rust? RoR?
You can make it all work, even exotic ones like Erlang (e.g. Whatsapp).
The same is true for mobile frameworks. Choose based on your constraints and needs. Avoid blindly copying.
• • •
Missing some Tweet in this thread? You can try to
force a refresh
I am hearing several senior engineers in hot fields in the EU getting +50-100% in compensation offers from US startups and tech companies... and many of their current employers matching, or partially matching them as counter-offers.
My theory on what's happening (cont'd):
1. COVID made remote work an everyday thing 2. Funding for certain startups is very strong in the US 3. These startups struggle to hire anyone good for $200-250K/year in the US 4. But they can hire *amazing* people in the EU, who are just as good professionally
(cont'd)
5. These EU companies are doing the math & realize it will be a lot more expensive to backfill the person leaving, as the market for sr engineers is moving up (see #2 & #4) 6. They make a counter to not lose the institutional know-how 7. Many of these people actually stay!
3. Once you get an offer, you can *always* do a round of negotiation. Don't commit on the spot: but ask for time to review it.
4. If you don't have competing offers: get data on what the company or competition's range will be. Blind, levels fyi are good sources, and I'll also publish data points for EU here: pragmaticurl.com/salary (WIP)
More than five years ago I decided to take tech blogging more seriously, and started The Pragmatic Engineer.
This year I’ve made more directly and indirectly from writing books than my comp would have been at Uber. None of this would have happened without starting that blog.
I get questions from people one day hoping to do something similar.
A few things: 1. I never planned for it. I quit my job at Uber for a variety of reasons, and enough savings to get by for a few months, while I write @EngGuidebook, that is a bucket list item of mine (cont'd)
2. Few people give away quality resources for years, consistently. My blog did this, helping many people in various ways.
3. Distribution is the biggest barrier for writing any book. The fact that I had a large group of people who trusted me (see #2) made a large difference.
7 mobile eng industry predictions after months of research for my book, Building Mobile Apps at Scale:
1. Kotlin Multiplatform will become the de facto *native* way to share code between iOS and Android. KMM is maturing rapidly & is easy for iOS engineers to also pick it up.
2. Flutter will become the most popular way to build cross-platform apps.
The only downside is having to learn Dart. Otherwise, it's fast & tooling is solid. Google has gone all-in, building many of their own apps 100% Flutter. Cannot say the same with RN & other alternatives.
3. Full-native mobile development is not going anywhere with large apps with millions of users.
Having full control of the UX & the ability to immediately make use the latest APIs will be key for many apps and platforms.
Flutter, RN, and others will not take over all the space.
The two-sided marketplace nature of job seekers/jobs, how you should use it to your advantage, and how the explosion with remote work (in software engineering) is changing this balance for juniors & seniors.
Thread for anyone job searching now, or in the future.
The job market *always* starts from the companies who hire. They have the budget, and need someone with a specific skillset. They post a job, and get (and often also source) qualified applicants.
There's a huge difference between popular & unpopular ones though:
The job market is a "sellers market" when there are a lot fewer jobs than qualified ppl who want to apply or change jobs. Recessions are good examples of this (in software: 2001, 2008, and some sectors now).
When this happens, even less popular companies see a lot more interest.