cjk

Before I left Apple ~10y ago, it was pretty common to drop linked-on-or-after hacks into AppKit and UIKit to keep popular software chugging along. Assuming they're still doing that sort of thing, this was either missed or deemed not high-enough priority to add such a check (or maybe one was added, and the only reason this issue has been noticed is because Electron and Electron apps are now being built against the macOS 26 SDK).

Visual Studio used to be as bad as modern Xcode, if not worse. Having used VS2022 a bunch for the last handful of years, I’m pleasantly surprised. Apple could take a page out of Microsoft’s book here.

This exact same phenomenon bit me at a previous job. We hired a couple of really smooth-talking grifters, and it took a tremendous amount of time to get rid of them. Vibes matter.

I believe it. It had started to wane even by the time I left in 2015.

I know there are still a ton of good people there, but it's a way, way different company now.

This is one of the things that I’ve tried really hard to impress upon engineers new and old while working on various projects, and IMO it applies to just about every layer of the stack; ultimately everything flows up into the UX.

This vibe was pervasive at Apple and could be taken more or less for granted, but elsewhere it’s all over the place.

And, like, sure, there are projects and industries where this doesn’t matter. But giving a shit and feeling it can be a major differentiator.

Thanks for Monodraw. I've used it for years and thoroughly enjoy it.

We manage mise itself via homebrew. Sometimes when upgrading mise itself, it doesn’t seem to handle being upgraded gracefully, and loses track of installed runtimes even if we manually kick it in our upgrade scripts. Restarting the shell entirely seems to be the only way to fix it.

That, and with Ruby, Node, and at least one other language/tool IIRC, when support for those things moved internal, we had to make a bunch of changes to our scripts to handle that change with effectively no warning. That involved checking to see if the third-party plug-in was installed, uninstalling it if so, and then installing the language based on the built-in support. In the meantime, the error messages encountered were not super helpful in understanding what was going on.

I’m hopeful that these types of issues are behind us now that most of the things we care about are internal, but still, it’s been pretty annoying.

We've been using mise since it was called rtx at $DAYJOB, and it's caused many a headache (mostly around upgrades/backcompat/etc.). We use it both on dev machines and in CI. In spite of that, it’s decent at what it does, and I wouldn’t soon replace it with individual version managers, given that we have similar needs.

However…more than once we've seen language runtimes that used to be available exclusively via plug-ins be migrated to be internal to mise, which broke everyone's setups in strange and hilarious ways, and caused countless hours of debugging.

Less bad overall than using individual runtime version managers for sure. But the next time mise costs us a bunch of hours fixing multiple engineers' setups, I intend to find another solution, even if that means writing my own. It’s burned us nearly one too many times.

I don’t think it’s quite that black and white. If it’s a matter of “we’re going to be insolvent if we don’t hit this deadline”, and you want to keep getting paid, long hours can be justified. That’s not to say it’s not a failure of leadership that led to that situation, but I really am talking about exceptional circumstances, not arbitrarily-imposed deadlines.

I’m really only talking about existential threats to the business and things of that ilk. 99% of the things people consider to be “exceptional” are not.

Yeah, I’d be taking the buyout.

As a hiring manager, I _vastly_ prefer hiring someone that values work-life balance over this grind culture bullshit. YMMV, but in my experience, the folks that care about balance tend to be more focused and productive during the hours they are working.

Of course, exceptional circumstances exist where long hours are required. Not disputing that. But making that the default for the company culture is insane.

I made the same switch recently. Results from Kagi are night-and-day vs. Google.

I do hope Kagi eventually has enough revenue to offer a more generous free tier, though (and without logging in). I fear it will remain a niche thing otherwise.

The author makes some good points, but native apps can absolutely provide a better experience than web apps in certain scenarios.

Bloated web apps with megabytes worth of JavaScript and CSS, crappy rendering performance, etc. are all too common. Far too many web apps are unusable or broken if you have any content/ad blockers enabled, which are almost a necessity in order to use the modern web.

Conversely, you download a native app once, and update it infrequently. Load times can be instantaneous. Offline support is far more robust.

To completely write off native apps just because some of those apps abuse the trust of users seems silly. Plenty of web apps have piles and piles of invasive ads and trackers as well.

What an absolute clown show this administration is. We’ve had enough pandemics for one lifetime, thanks.

The midterms can’t come soon enough. That is our only hope of putting some real checks on this administration any time soon.

Agreed, CI-managed build numbers are a good way of handling this. I've done the same thing at my past handful of jobs.

I disagree that a timestamp is a “build number”. Additionally, injecting dates/times into builds is bad juju from a reproducibility perspective.

The bit that’s fascist is that birthright citizenship is guaranteed in the US Constitution, and the current administration is openly flouting it.

Absolutely gutted. I regret never seeing him live. RIP Brian.

Anecdotally, I have seen some engineers totally give in and start using LLMs to do 90%+ of their work, and the atrophy in their critical thinking skills is readily apparent. It's both shocking and entirely predictable.

I'm extremely worried about how this phenomenon is going to affect junior engineers and folks getting into programming from here on out. It's not hard to imagine an entire generation of “engineers” that can't program their way out of a paper bag without assistance from an LLM.

I spent several years at B&W prior to the Sound United and Masimo era, so this news makes me incredibly sad. I hope Samsung doesn’t run the company into the ground.

There are lots of good people left at B&W. If they are afforded the autonomy they deserve, everything will be fine. If not…I guess we’ll see.

Give me a break. Supporting a free Palestinean state is not the same thing as supporting Hamas. See all of the folks in Gaza protesting Hamas over the last few days, for example.

I hadn’t realized this about NUT. I just started using it as part of TrueNAS’ built-in UPS monitoring support and haven’t had any issues thus far, but this gives me pause.

I buy that there is room for an alternative tool regardless of how crashy NUT is, but the technology choices for this are a huge turn-off IMO.

A lockfile with 10k lines of deps and bundling a whole-ass Node.js runtime is truly bonkers for a system utility like this. The JavaScript ecosystem exhausts me.

Yup. Well-said. I experienced exactly this type of thing during every NMOS planning/brainstorming session I was a part of.

As a former Apple employee that left in part due to declining software quality (back in 2015!), and the relentless focus on big flashy features for the next yearly release cycle, I could not agree more.

I recently had to do a full reinstall of macOS on my Mac Studio due to some intermittent networking issue that, for the life of me, I could not pin down. Post-reinstall, everything's fine.

This “gather provisioning inputs” step completely prevented me from building a project of mine yesterday. I let it sit there for over 20min with no movement. No amount of rebuild attempts worked, nor did restarting Xcode. Only a full reboot of my machine fixed it. I didn't see any network issues at the time this was occurring.

In an era of microservices-and-k8s-all-the-things, Rails monoliths are a breath of fresh air. For stuff that's really performance- or latency-sensitive, tacking on a satellite service in Go or Rust works great.

Between the back button issues and the horrible sluggishness on many repo and pull request pages, the React switchover has seriously degraded what used to be a great experience. Not just on mobile, but on desktop as well.

This is indeed the way.