This isn't high school, and you're not going to give me homework just for the chance to work for you. And I use the homework analogy intentionally, because just like with school, this doesn't scale. I can't interview at, say, 10+ companies all of whom are expecting me to put in paying-employee-level work just for the interview while also holding down my regular job. And I'm not going to go with a significantly shortened list of candidate companies just because their interview process is so onerous that I literally don't have the time to talk to more.

Again, I know not everyone can do this, but realize that companies try to exploit you during the interview phase, too. You need to also have standards for what you're willing to put up with.

The way I implemented it was to have each beacon transmit on I think 1s (might have been 5s to save power) intervals, and some python code on an RPI that listens for them, with a timeout for each. If the listener gets a ping it immediately forwards it to mqtt as a "home" ping, using the beacon id to set the topic. If it doesn't get a ping within the timeout then the rpi generates and sends an "away" mqtt message for that beacon. My expectation was to have it alert me within ~2-3 minutes of a vehicle going from "home" to "away". In practice:

- BLE beacons aren't very popular really, most of them are made by small foreign companies who don't sell them in places like Amazon. The ones Amazon does sell are kind of crappy. Setting them up usually involves downloading a vaguely-sketchy app to your phone (I haven't figured out how to configure them from the rpi). They all seem kind of janky honestly.

- Bluetooth and Wifi use the same (some) hardware on an rpi, meaning if you start rapidly scanning for BLE tokens your wifi performance will drop to the point of the rpi being unusable (ssh sessions timing out). I fixed this by buying a separate USB bluetooth dongle, although even that was a pain to get working in the pybluez module - in general bluetooth under linux along with the python bindings are finicky and crap out easily, it seems.

- I have my dmesg and syslog spammed with "Bluetooth: hci0: advertising data len corrected" when using bluetooth scanning, I managed to find a couple bug references to it and other people complaining about it but no fixes over multiple system updates.

- It's just... Not reliable. I don't know why. I've tried really hard to make it reliable, and maybe the problem is the RPI-as-bluetooth (maybe if I used a microcontroller as the receiver it would work better?), but I've tried all variations of scanning windows and such and dug down into the code for Bluez without figuring out either what I'm doing wrong or where the issue is. Beacons will supposedly not ping for minutes at a time despite being on a 5s interval no matter what I do, and this is for beacons maybe 6 feet from the receiver (although ones further away do timeout more).

The last thing is what finally killed the project for me. I had it (still have it) all setup in HA with notifications and schedules and such, but I just turned off all the automation for it until I get a chance to tear it down. Failed experiment.

The whole article is extremely thin on facts and very fat on speculation and breathless rhetoric.

And I'd further counter that: yeah, actually, you and your company ARE special. Every company is. There is no One True Way of running a business, or any individual aspect of that business. Everyone's triangulating around resources, people, industry, corporate vision, etc. If anything I'd say the argument that "you are not special" is the fallacy, as it leads directly to the kind of cargo-culting that you see so many failed companies do.

Finally, when we see successful companies, how often is it because they just mimicked what everyone else was doing? Not very frequently, as it turns out. Well-behaved companies seldom make history.

a) No, it's not what people want. It seems convenient in concept and even in practice, until the moment they encounter something that makes clear to them just how much a third-party companies knows (and can divulge) about their life, and they immediately start trying to turn this stuff off.

b) It's not what people need. The fact is most of these services are problems looking for solutions, and offer an overabundance of data for a user who simply does not need it and can't use it. Traffic jam ahead? Thanks for the heads up but not like I could modify my plans or route, so that's useless. Can't remember someone's name? What, am I going to take a picture of them and then whisper 'hey google who is that person' discretely into my phone? Need to remember the name of that great (elided) last time you were in the area? Chances are you could just look it up and in the process discover other interesting things - and I'm not even sure what you mean here, like, is Google going to show me a list of everyplace I went when I was there?

Why do you think so many so-called personal assistants just keep getting used for the same thing? How many things need to tell me the weather today, or traffic conditions?

c) These things don't work and what you're essentialy are advocating for is that we give up our privacy and personal data in exchange for broken systems (sorry, "growing pains" - nevermind Google's been pitching these things for years and they're still mostly used to set timers and answer silly trivia questions - poorly) that may someday offer something we don't need (see a and b). That's a garbage deal if ever I heard one.

I think you want people to want these features because they comport with your idea of the future. But the fact is reality is not playing out like that.

What he did was speak heresy. I’m sorry that it sounds like I’m a butthurt male but the fact is diversity is dogma in these companies and you either buy in wholeheartedly, constantly, to the exclusion of all other priorities, or you’re ex-communicated.

I heard as an aside that the London Philharmonic parts of the soundtrack were commissioned and recorded because Disney didn't have confidence that Carlos would finish her work on time (or at all, the relationship was a little strained), and using both was a decision made only afterwards.

See we can both play the no proof game.

I think the biggest conflict here is scale of the services involved. For smaller scale - which is what most people are familiar with - monolithic architecture can offer distinct advantages. At scale though? Monoliths have been relentlessly excised for years because of all the very real scaling and maintenance problems that go with them.