CTO at Config (https://config.com)
Personal website: https://krieger.io
[ my public key: https://keybase.io/cjk; my proof: https://keybase.io/cjk/sigs/ItSjdGcDzRZHDPvBRf-EIRP4QOJEdA26KPBHvi7f3Nk ]
- cjkI worked with the author of Fil-C at Apple while on the Safari team, and he's easily one of the brightest folks I've had the pleasure of knowing. Fil-C looks extremely cool.
- Yes, the US Mint sells all of the coins in the American Innovation set to the public. Previous years’ coins can still be bought if they are not sold out.
- I've had IPv6 with the last three ISPs I've had across California and Nevada. I can't honestly remember the last time I _didn't_ have IPv6.
- 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.