A daunting thing about mobile development is just how poor the tooling landscape is in 2021.
I suspect Apple's decision in 2010 to basically ban code generators - bankrupting dozens of startups overnight - is a huge reason.
It could happen again. It's a risk to be priced in.
This is true for backend-driven mobile apps as well: the App Store Guidelines are very vague.
It's why e.g. hot reload on RN is something any sensible company steers clear of in prod. Yes, it works: but it *could* get your app banned. For good.
It holds back the ecosystem.
I do wish that Windows Phone would have succeeded in staying relevant because it would have led to *much* more competition.
Microsoft was dev-first in their mobile approach. Their A-team was building the dev tools.
Apple - let's be honest - is consumer-first, developer-last.
The 2012-2013 Windows Phone development experience & documentation is well ahead of Apple in 2021.
There seems to be some improvement at Apple... but, let's be honest, they don't need to improve.
iOS is where the money is: developers will (have to) put with what is there.
The tragedy with Apple is that - unlike Microsoft - they ban solutions wanting to offer (better) tooling to what Apple does.
A telling story is Windmill for iOS and Mac: a tool to iterate faster on apps. Rejected for... being too similar to TestFlight. qnoid.com/2019/07/29/Win…
And thus it's full circle. Customers are on iOS --> devs are as well.
Apple tools need improvement --> but they can (do) shut down efforts for improvement.
And so the iOS dev experience is what it is. Put up with it. Build internal tools to work around (just don't tell Apple!)
Android tooling is another story. It's better and more open. Good job, Google.
But in the US and Western Europe... it doesn't matter. iOS brings in easily 60-70+% of iOS/Android revenues for many businesses.
You support Android, but iOS is the cash cow on these markets.
• • •
Missing some Tweet in this thread? You can try to
force a refresh
Uber's CTO, Sukumar Rathnam stepped down just 12 months after joining the company.
I left Uber shortly after he joined as CTO, and here are my thoughts on this departure, from the sidelines. A thread
1. This was never meant to be an easy job. SK joined after the 2020 Uber engineering layoffs, low morale, and sinking stock price.
By the time he was in, attrition was high, and he had large shoes to fill that Thuan Pham, Uber's CTO of 7-years left behind.
2. Uber was also without a CPO at this time: Dara stepped in to fill this role. One more challenge.
3. The tension with what engineering wanted (build for the long-term) and Uber's business needs (get to profitability the short- or medium-term) were always at odds.
The tech hiring market has never been this hot: not even during the Dotcom Boom. I talked with dozens of tech hiring managers (from managers to CTOs), swarms of people switching jobs to answer:
Why this is happening, and what are companies doing who keep growing?
A thread:
1. Covid-19 being the tipping point of companies going all-in on digital. Not just e-commerce, but all industries are investing *big* money to move to digital.
What are Platform teams, why are they important, and why do (almost) all high-growth companies and big tech have them? A thread.
1. The easiest way to visualize Platform teams is blocks of specific types. Other teams (called Product/Program) use these "blocks" to build.
2. Platforms are focused on a technical mission, rarely have cross-functional engineers (e.g. mobile & backend folks) on the same team, and customers are (usually) internal engineering teams.
Examples include infra-like Platform teams and Product Platform teams.
3. Why even have a Platform? Could we not just... do what we do?
Platforms own very specific goals, often tied to non-functional capabilities like performance, reliability, compliance, security etc.
Yes, you could do without them: and every single team would need to own these.
I'll share the draft write-up with those indicating interest.
The most unexpected result is how the *only* places where people rated satisfaction with a 1 or a 2 was... places where dedicated project managers or product owners ran the projects.
Places where engineers, tech leads, or EMs did so showed higher satisfaction.
Sw engineering is one of the few industries where just by having ~8-10 years experience in the field+some demonstrated leadership (eg projects) opens up engineering manager opportunities.
All because of the very high growth: most places can’t keep up just hiring EMs externally.
Internally “promoting” engineers to managers is a great thing: *when* these new managers have the right support during this transition.
Some of the very best line-managers I’ve known have been internal promotions. They often became the manager they wish they had.
I became a manager this way (leading projects/teams and we made it official later). I also tried to empower people on my team to lead, being transparent about what managers do, advocating for engineers in my org to become managers. Many have done so: I’m glad they did.
It's been over a year since Uber laid off about 20% of it's engineering organization. In my observation, the layoffs - and how they were done - were one of the biggest mistake the company did: and something other tech companies should learn from.
Thread with my observations.
(Note that most of this thread is my take, but I've talked with several Uber engineering leaders who were there at the layoffs at the time)
1. The plan, as I understand was simple and finance-driven. Cut the cost of engineering by X%. This mandate was passed down to each eng org
2. Alarm bells were rang early at each level on what this would mean. Leaders warned that by cutting 20% (even if it's the "bottom" 20%) this would have terrible consequences:
- Top performers would leave
- Hiring would become difficult, if not impossible