bmurphy1976

You need the right sized coin. A nickel works best. Anything else doesn't fit right and tears up the plastic or slips out.

I have a bunch of Aqara sensors and they stay connected most of the time, but if there's an extended power outage, usually about 1/3rd of them won't reconnect. It's annoying having to hunt them all down and reboot them. Sometimes the button won't work either and I have to fuss with the battery to get them situated.

I had issues with my garage fridge last year. Took a while to figure out, but there was a small box at the bottom that was occasionally keeping the door from closing completely. The Zigbee sensor was great tracking what happened when and helping me narrow down the cause.

Google isn't much better. I have them all over the house. Ask a question to the living room speaker, skips that, skips the one in the kitchen, answers from the one in the bathroom upstairs or one in the basement. Then you get a notification later asking "was this the right device?" which is doubly infuriating since responding to that never actually improves anything.

Yes, that's my point. Fridges don't need all this functionality built into them.

Is it really an Elephant in the Room situation? Are there upvoted ticket/issues or community threads asking for it? I don't really know, it's an honest question.

As somebody with a pretty extensive Home Assistant based home automation system AND kids, I've never once felt the need for this. I can certainly see the utility of it, but Home Assistant is already complicated enough. I'd prefer effort be spent improving the UX, simplifying the system, improving reliability and adding more (optional) integrations.

To be fair, the MCPs of 8 months ago are not the MCPs of today. You had to mess around with headers and .env files and local npm proxies and other bullshit only cli jockeys would tolerate. The MCPs of today are fully remote, stateless, oauth enabled, and integrated much more nicely into the the user experience. Click a button and it works.

I do agree, the "MCPs are dead" narrative was overblown, but there were legit reasons we weren't ready to go all in on them back then.

It's not just the screen. Microchips and sloppy firmware are everywhere.

My 2015 Jeep Cherokee had a freakout one day: the power steering stopped working mid-drive, on the highway. I was 50 minutes from my house, had to turn around and drive back home (an exhausting exercise given that modern cars are not built to function without power steering). I got to the dealer, parked in the lot, turned the car off, wait 30 seconds, turn it back on, everything worked fine.

That never happened again, but once is enough to put somebody in a dangerous-to-life situation.

It's not just the infotainment system we should be worrying about. Most modern cars are now distributed computer systems.

My idea of a smart fridge: a fridge with Zigbee Temp/Humidity sensor connected to my Home Assistant automation system that alerts me if things get out of whack.

My idea of a dumb fridge: a fridge that updates firmware, bricks itself, and lets all my food spoil.

Get a Unifi system. It's built in. Works great!

You have to start somewhere.

Interesting. Because I have a much harder time typing on my Pixel. In fact, I hate it. I wish I had a blackberry.

When I use iOS devices, it feels better but I don't use them enough to have used them in anger. Ok, well, yes they have made me angry but for other reasons than the keyboard hence why I'm on Android lol.

I've been running Hermes inside a remote docker container connected to Slack bound to a Codex account. It's actually pretty great, I prefer this approach for a lot of things. Because it's in a Docker container I have 100% control over the configuration. It may do some crazy stuff, but I know it's not going to start exfiltrating my AWS SSO tokens or SSH keys from my laptop.

I'm frequently listening to music or a video in the background. Join a zoom call early because I don't want to be late, instant AM radio. You can argue I shouldn't do this, I'll argue that it shouldn't matter and should just work. It's 2026, not 1926.

That's not true at all of the corporate world. If your team is mass producing slop and you don't have processes in place to get it under control, you've got a big problem on your hand.

If any engineer sent me a 20,000 line refactor I'd immediately reject it and tell them to go back and start making changes incrementally at minimum. More likely I'd force them to have a whole design discussion with the team to make sure that what they are doing even makes sense.

What happens if they push out slop that significantly increases your infrastructure costs? What happens if they push out slop that significantly increases the number of bugs or outages? What happens if they push out slop that has no observational metrics, dashboards, or tooling?

In every case you push back on the team and make them fix their shit. I don't care if they are using LLMs or not. They are responsible for their work being sufficient quality. If they aren't meeting those standards, then they need to step it up.

How do you handle them? I'm not facing this problem as the team I work with is very senior and have good taste and discipline. But I can imagine it will be a problem at some point, and I frequently have to personally tell Claude to rewrite it's vomit in English. That's probably step one for people submitting poorly written PRs, reject them until they are written clearly and concisely. And if they are too big, also rejecting them and telling them to go back to the drawing board and submit smaller more focused change. But I'm not int his position so I'm taking an educated guess.

Maybe. I don't have enough context, but maybe that's what he wanted to do? Whatever you may think about it, I'm pretty convinced Ozzy wanted to go out with a big concert. Nobody had to push him to do it.

~$4000 USD each on Amazon, $175 for the cable.

Maybe. It's been what I wished Java was since the beginning, personally.

I'm not sure I want another layer of indirection personally, and I'm guessing an updated Claude model will reign this in at some point. I have however created a skill I call "deslop" and I invoke it to clean up Claude output when it goes off the rails. Here's the skill if anybody is curious:

https://gist.github.com/bmurphy1976/47ad81a842ab4b1628ef5974...

A small preview:

    *Meta commentary.* Sentences about the document, the diagram, the reader, or the
    writing itself ("the split across this diagram is the whole point", "a reader who
    assumes X will be wrong", "as we'll see below"). Delete the frame and keep the fact
    it was wrapped around. If there is no fact underneath, delete the sentence.

This doesn't change the fact that those soft skills are necessary to use LLMs effectively. You need a mixture of hard and soft skills.

Engineers who have avoided learning the soft skills are going to have a harder time adjusting.

Tracing what it actually did. Who would have thought that's a good idea, instead of trying to obfuscate everything.

I hate fighting with the AI to get a good summary. Reading the good summary is great. Getting to it is the challenge.

First attempt: mountains of meta conversation and not answering the original question.

Second attempt: shorter and more concise, cuts out some of the nonsense, but terribly written.

Third attempt: goes off the rails, misunderstands what you are asking and tries pushing the work onto you.

Fourth attempt: finally something that's concise, reasonably well written, to the point and passable.

He was showing how complex and expensive a data center is and giving them real-world visceral experience that inefficient code has real-world implications.

Do you have SLO/SLAs defined? Are you monitoring performance? CPU usage? Cost increases?

You should have plenty of data to review regularly and push back on any teams that are causing problems. That's a process problem and you need a process for it.

Trace the increase back to specific deployments, call out those teams, and make them fix their shit.

All the more reason to block Facebook completely.

The parent didn't go into any detail. I can. Homebrew has a history of ripping out your foundation underneath you. One day you are on Python 3.8, then next day you are on Python 3.10 and all your packages are broken. MacPorts doesn't do that.

Now, whether you should you be using the Homebrew Python is a completely different question. YMMV for other platforms managed via Homebrew.

I've traditionally used MacPorts for dev tooling and Homebrew for everything else, but with more aggressive adoption of tooling like uv an nvm I'm not sure the different really matters for me anymore.

I want to see a graph or flame graph or something akin to how Temporal renders workflows in real-time. I want to follow along as all the different sub-agents and tool calls do their work. I also want to know how much this is costing me at each step.

Just like with a Temporal workflow, I don't care how things work 99% of the time. But that last 1% when I really need to dig in and understand how and where things went sideways this type of view would be invaluable.

My comment is dismissive because the parent comment is also dismissive. But you are right, advice is helpful. It's in my comment, but it may not be obvious to everybody, so here it is:

Work on your project management, communication, and mentorship skills. The AI tools are much more like a team of sloppy but capable junior engineers and not a reliably consistent fabrication machine. Change your perception that one simple prompt is going to magically solve a hard problem the first time. Learn to break projects down, organize them into sub-projects, and implement them in steps. Learn to communicate more clearly, define your requirements more rigorously, and adapt around your "team's" strengths and weaknesses.

We want these things to be rigorous and flawless but reality is messy just like working with a regular team of engineers. They are good at some things, terrible at others, constantly changing, and unreliable. But we've historically built tons of reliable software on unreliable actors by focusing on process, collaboration, and communication.

AKA, not just the hard technical skills, but the soft skills that allow unreliable software teams to thrive. They don't know what they don't know and it's your job to manage that.

You don't need a "blog post." You need experience managing projects, tracking progress, coordinating conversations, mentoring less experienced engineers, etc. That experience comes with practice and time.

If you really need something to latch onto, there's plenty of educational material available about how to be an effective scrum master. Start there.