Androider

There's usually a few core systems like the CRM, the marketing suite, ERP (in bigger companies) that cost literally magnitudes more than your Slack's and G Suites. Even in a small company you may be spending most of your SaaS budget on just the first two.

Not that companies tend to have a SaaS budget, it's more like a Sales budget, a Marketing budget, Engineering budget etc. That's why sales and marketing doesn't mind spending 5-6 digits on their software without sweating it if there's clear ROI. Hey, it's probably still cheaper than a single rep or two. If anything, Engineering seriously undervalues their time and overvalues building their own worse versions of popular SaaS software (no, your ad-hoc Lambda function hooked up to send an SMS is not better than PagerDuty), I see it all the time. Software that saves you an hour a month is probably worth at least $1K+/year as an engineer in the US, and most engineering tools are way cheaper than that.

Could you could state that the newly reported issue is both duplicate and that the original report was closed as N/A?

Not applicable typically means the reporter is free to try to argue that is in fact applicable, but by stating it's both duplicate and N/A neither the second reporter nor the company will spend further time arguing back and forth, as even if the issue was applicable the credit would go to the original reporter.

Stripe themselves are also doing it now https://stripe.com/capital

The sums are pretty small right now, but the basic model is there.

Simple, when you go visit someone in a private office you can close the door and have a long conversation about your topic and really hash out the details. If you turn around and start blabbering to one of your teammates in an open office plan, everyone within hearing distance will want to murder you. If you're not aware of this, I guarantee everyone within 30 feet of you is already wearing headphones and hates you.

So now you have to coordinate on Slack to go to one of the shared team meeting rooms instead. At that point you might as well have your conversation in Slack, even if the person is sitting right next to you. And that's the state of open offices today, co-located but void of any actual collaboration.

I've worked in single person offices, 2-3 person offices and open offices. 2-3 person offices where everyone works on the same thing is the best, by far. Remote work is the new private office, not quite as good as a 2-3 person office, but infinitely better than an open office.

I remember thinking when the RH deal was first announced, IBM should pull a NeXT/Apple and just let the Red Hat executives take over the new company.

It's interesting how differently you can look at things. I would consider the best time to start a React Native project to be sometime next year, and after 1.0 ideally.

It's exactly when you jump on the bleeding edge that you end up with cuts and bruises. For every new shiny thing you'll be trading your current known problems for a set of unknowns and the inability to even Google-search for the solution. Let the tinkerers do the bleeding, and only once they've buffed the sharp parts can you as a company like Shopify start to bet on it.

It seems module and library handling was just revamped in React Native (not a user myself yet, perhaps next year), so thank you for your sacrifice. Developers picking up RN today will hopefully have a smoother experience.

Microsoft has been building Word on Windows since the 80's, so it's never going to be re-written. I'm not that familiar with the Mac version of Word, but I find the Mac Excel version lacking compared to its Windows counterpart.

For Word and Excel for iOS and Android they use... React Native [1].

[1] https://blog.appfigures.com/microsoft-goes-all-in-on-react-n...

The Facebook app is like Microsoft Word. Everyone only uses 20%, but it's a different 20% for each. The app is a hojillion megabytes, and serves literally billions of users. There's features in there that addresses some specific niche in Africa for "only" 50 million users, that some sub-team of a sub-team is tasked with maintaining.

I wouldn't class this as political problems. Is Facebook having a gazillion developers on their app a political problem, or necessary given what they want it to do? How is replicating that for each platform a good solution, in any sense (political or technical)?

Tech companies core competencies are the service or product that they provide. Making it N times for N platforms is a hurdle that doesn't improve on the core, it's a cost of the fragmented market. I'm arguing that it makes perfect sense both technically and politically to focus your vast majority of developers on your core, and only having specialized platform teams were necessary as a cost of doing business. How is developers re-implementing every UI screen and feature across iOS and Android helping Shopify customers sell more merch?

But the question was why large companies use platform abstractions. Because they are large in headcount, by definition. Because the apps are already large. Because they have massive platform specific teams, and they would like not to. Because the teams are geographically spread out, for a myriad of reasons.

The large companies are what they are, and you cannot apply the same type of thinking to their problems as if you were designing the organization from scratch. There's problems they have, and the team structure they would like to have, and based on that the technology choice to favor abstraction makes sense.

React Native could very well fall out of favor in the next 10 years, but the amount of companies using it today means there is a sufficient base to share the maintenance burden with, of which Shopify could potentially carry a large amount because of the significant overlap with the rest of their tech stack. If Google becomes disinterested in Dart, could Shopify step up and maintain it? Seems unlikely, and why on Earth would they want to, it's nowhere close to the rest of their competencies?

If for one technology you can extrapolate from today out to the next several years at least, and the other's path is effectively entirely opaque and at the whim of another party, it's a company-killer level risk to bet on the latter. Put it this way, if Google drops Dart/Flutter tomorrow, Google will be just fine as they have very little skin in the game so to speak. Technical reasons one way or another are completely overshadowed by the business risks, as the landscape is today (which will change over the years, but Shopify is making their decision today).

Shopify CEO expressed his thoughts on the matter quite succinctly https://twitter.com/tobi/status/1222551057798090752

Headcount is the biggest expense in almost all companies. Larger companies also have larger and more complex apps, so while a small company may have a small iOS development team, large companies have massive iOS development teams. Massive team * number of platforms = serious money.

You also get into all kinds of platform and feature parity issues. "Why can't we do X on Android but only on iOS?", "Well because they're two different teams, with different PMs, developers and release schedules. And please don't ask about the web team, who are in <different city>".

Using abstractions you can have one massive "core" team, and several smaller platform expert teams. On the face of it, it makes sense.

In the unlikely event that Fuchsia ever makes it out without being strangled by the rest of the Android organization, or someone high-up waking up and taking a look at it (eye of mordor style)... absolutely nothing? For the next 5-10 years at least as Android devices are slowly replaced in the marketplace with Fuchsia through device turnover rates alone. You think Android version upgrade stats are abysmal today? And you want to replace the whole base OS? Good luck with that.

It would be pants-on-head insane for a company like Shopify to go all-in on Flutter. Is Flutter going to be around 10 years from now? Can Shopify support Flutter on their own if nobody else is using it 10 years from now? I don't mean that technically the license would allow them to, but can they in practice field the manpower and skills to do so across all the platforms they need.

You can also partition your major resource into smaller sub-units to decrease contention, increase parallelism and improve throughput. E.g. separate your bathroom from your toilet.

When cooking I often find myself pondering that food prep has a very similar space-time tradeoff [1] to CS algorithms. Protip: Sprawling over to non-kitchen areas for mixing bowls and whatnot can provide a significant speedup vs moving things around in a limited kitchen workspace.

[1] https://en.wikipedia.org/wiki/Space%E2%80%93time_tradeoff

Another strange thing to me is the ridiculous number of bedrooms in new single family homes, and the assumption that more is better.

Sites like Zillow don't even let you put an upper limit when searching. Agents can't believe you don't want a bigger place. I don't mean cheaper, I mean I don't want all those rooms and stairs. In my area, you perversely have to go to the ultra-luxe range of the market to get a high quality 2-3 bedroom single family home, while 5 bedroom new constructions are a dime a dozen. That makes no sense.

That goes for a lot of other media as well. Fox News has on average 2.5M viewers. In a country of 327 million (never mind the world), you can round that 0.7% viewership down and say that in practice nobody is watching Fox News. There are more daily viewers on Twitch than that, and far more viewers in total.

The type of problem that TypeScript solves is not the type of problem that I have.

In my 15 years of engineering, exceedingly rare is the case where the underlying cause is due to using wrong types. I could count the number of times types has been problem on one hand. Instead, almost all issues are due to logic errors and missing or poorly understood business requirements.

For me, the time spent resolving TypeScript specific issues (missing type definitions, lack of support in third party libraries, general finickiness etc.) does not make it a worthwhile investment. I also did Scala for several years professionally, and while it instils rigor, I feel much the same that the price you pay isn't remotely worth the benefit you get. Conversely, I think one of the best investments you can possible make into tooling is to reduce the edit-compile-view cycle time, and you should aim for seconds at the most if not instantaneous updates. That speed of iteration will pay dividends.

The small visitor center at the Amazon Spheres in Seattle has a whole bunch of them.

If companies could, they would just send your browser a binary blob. From a business point of view, exposing your inner workings / modules is a no-go. Same for local apps using Electron, there's a (perceived at least) business need to obfuscate the code into a big ball of mud that is continuously changing with every build so external patches cannot be applied, e.g. Slack doesn't want you to have the ability to read or modify your local Electron client.

CVS doesn't care if you buy Tylenol or Advil or which one works better, and makes no additional money depending on your choice of product. In fact, the brands pay CVS for the privilege of being featured on an eye-level shelf vs at the bottom.

I think it was a great article. Like it said: To succeed, an offering must create value for all entities involved in the exchange—target customers, the company, and its collaborators. And value is literally measured in dollars, so you're either saving or making money for someone, otherwise it's just a fun project.

They've also distributed security notices through the MOTD. I find it useful.

The FAA just did a simulator test and more than half of the pilots failed to follow the intended procedures in case of failure. These pilots were specifically trained on the 737, and know they're participating in a trial. I think I'll stay clear!

https://theaircurrent.com/aviation-safety/pilot-procedure-co...

"One day when I was a junior medical student, a very important Boston surgeon visited the school and delivered a great treatise on a large number of patients who had undergone successful operations for vascular reconstruction.

At the end of the lecture, a young student at the back of the room timidly asked, “Do you have any controls?” Well, the great surgeon drew himself up to his full height, hit the desk, and said, “Do you mean did I not operate on half the patients?” The hall grew very quiet then. The voice at the back of the room very hesitantly replied, “Yes, that’s what I had in mind.” Then the visitor’s fist really came down as he thundered, “Of course not. That would have doomed half of them to their death.”

God, it was quiet then, and one could scarcely hear the small voice ask, “Which half?”

Press the "Aa" button and the row of icons goes away.

Based on the title, I was dreading checking this out but... I kind of like it; Keyboard accelerators for dropping in and out of the various block and list modes, quick action for code etc.

That's just the current payment model, but that is orthogonal to the underlying technology. I can imagine a Spotify Free version of Stadia (yes, with ads or other limits) and a Premium all-you-can-play version. Game demos can be replaced by "Play now" buttons on YouTube, literally dropping you into the game in seconds.

What the platform promises is to match the ease of use of YouTube or Netflix. If it can actually deliver on that, I'm sure we'll see a lot of different business takes on the same technology. As someone who started gaming on an Atari and still maintains a top-of-the-line PC, I see a streaming model as inevitable since games need to compete with the Netflixes of the world for your attention. As a new dad, the barrier (timewise) to actually playing something these days is prohibitive, so Netflix wins by default for me when I have an hour.

I love the backwards compatibility that Stripe provides. Thank you so much!

We launched a SaaS product on the 2016-03 API version. Since then[1] the API has basically changed completely around subscriptions (even the top-level objects aren't called the same anymore), to the point it would probably be easiest to just start a rewrite from scratch (which probably would take a week or two). But the fact that the old API continues to work to this day and that we have been able to rely on it and focus on other things has been amazing. New customers get to enjoy the new API while our business continues to chug along with zero modifications to the payment parts. That is impressive from both a technical and from a business point of view, and ensures we will keep using Stripe forever.

[1] Stripe provides a very detailed and customized API upgrade guide based on your current API usage https://stripe.com/docs/upgrades?since=2016-03-07#how-can-i-...

The Sift report is based on your email address, among other things. My email box is full of random people's insurance quotes, medical and electric bills, birthday greetings, and welcome emails to services I've never heard of. We all know the company is going to spend approximately zero time to sanity check or sanitize that data firehose. Turns out the movie Brazil was a documentary.