I actually worked on an App for a company that made home appliances. Originally they made everything local, so direct App to Washing machine communication. They had a really hard time with that approach for a number of reasons.
The first, and most obvious, reason is that getting your phone and (all) your appliances on the same network is non-trivial. Especially for a novice user. Sometimes the washing machine is in the basement and can't connect to your WiFi. Or maybe you're simply outside your house in your car and can't connect to your local network. The cloud approach solves this.
The other, not so obvious reason, is that the manufacturer made a ton of devices. Some of them a decade old, with very rudimentary interfaces. Originally the App had to handle special cases and workarounds for dozens of devices. This became a problem once they tried to port it to multiple platforms. For Android and iPhone they started with a shared C++ library. But that quickly became a problem, once they wanted to interface with popular home network and automation solutions.
To solve all this they decided to build a cloud API that would resolve all these problems in one go. A single, unified API with a modern HTTP interface and available via the internet. That solves the workaround and compatability issues by having a single abstraction layer (instead of one per app). It solves the "on the go" problem when you're not in you local wifi. It enables you to control devices outside your home network in a true IoT sense.
I totally agree with you that, if you're not in an urban environment with good internet and cell coverage, the advantages dwindle away. Also, of course, there is the privacy concern that is very real. At the end of the day the cloud solution is selected for the same reason companies select Electron. It saves development time and is very easy for the average end user to use. At the expense of performance and privacy.
Many things in this article, especially about the problems with the Data Science role, resonate with me (low value work with low expectations for quality). Funny thing is I have never worked in Data Science. Rather I've worked in Software Development. The summary at the bottom about Data engineering seems like the dream job to me. But I don't think it's because I'm interested in doing Data engineering specifically. I think it's because doing things that actually have an impact day to day is fullfilling. The last job I had totally lost me after ignoring security problems in favor of surface level things like updating CTA labels or similar. Have other Software Devs had this experience?
Sadly there are a number of functions in the PHP standard library that literally never can return true. Often they return a resource or false, for example. In those cases the `false` type is more accurate than boolean. That's the reason for the distinction.
Think of it this way: It's a social contract between the company and the employee that you will spend your time on something valuable to both the company and you. In larger organisations it can also help to answer the question "What is your team working on?".
I have in fact experienced employees (peers) that will simply slack off and say they "weren't told what to do" when asked. It's infuriating to work with those kind of people. Those have been exceptions though.
From my experience as participant in these kind of systems, this is what I think:
These systems have the goal to create buy-in from the employee to perform at a certain level. Since you create these goals yourself there are little excuses why you can't reach them. It creates an incentive for the employee to work hard all year long and lessens the burden on the company to continuously check if you're being productive.
I guess another way of saying it is: You define what you're getting paid for year over year. What value you're providing for the company.
The first, and most obvious, reason is that getting your phone and (all) your appliances on the same network is non-trivial. Especially for a novice user. Sometimes the washing machine is in the basement and can't connect to your WiFi. Or maybe you're simply outside your house in your car and can't connect to your local network. The cloud approach solves this.
The other, not so obvious reason, is that the manufacturer made a ton of devices. Some of them a decade old, with very rudimentary interfaces. Originally the App had to handle special cases and workarounds for dozens of devices. This became a problem once they tried to port it to multiple platforms. For Android and iPhone they started with a shared C++ library. But that quickly became a problem, once they wanted to interface with popular home network and automation solutions.
To solve all this they decided to build a cloud API that would resolve all these problems in one go. A single, unified API with a modern HTTP interface and available via the internet. That solves the workaround and compatability issues by having a single abstraction layer (instead of one per app). It solves the "on the go" problem when you're not in you local wifi. It enables you to control devices outside your home network in a true IoT sense.
I totally agree with you that, if you're not in an urban environment with good internet and cell coverage, the advantages dwindle away. Also, of course, there is the privacy concern that is very real. At the end of the day the cloud solution is selected for the same reason companies select Electron. It saves development time and is very easy for the average end user to use. At the expense of performance and privacy.