---
title: "inessential"
generator: "opmlToMarkdown v0.5.14"
---
## [Tuesday, September 22, 2026](2026/09/22.md)
### [That About Wraps It Up for Stock Mac UI](2026/09/22/that-about-wraps-it-up-for.md)
The latest macOS is a nice step toward a good-looking Mac UI, but I do wish it had gone farther.
I am in particular not a fan of how Mac toolbars look. I don’t like the full-height sidebars and I especially don’t like the Liquid Glass buttons.
I looked around at what other Mac apps are doing. I asked [on my microblog](https://micro.inessential.com/2026/09/21/now-that-were-a-year.html) which gets [syndicated to Mastodon](https://indieweb.social/@brentsimmons/117310475883194321) and I also looked at replies to [Isaiah’s similar question](https://mastodon.social/@isaiah/117299199842156790) from a few days ago.
What I found should be no surprise: many of the apps people think look good are not using stock UI.
You already know this. I don’t think I need to prove it. But one app may serve as an illustration: [Things](https://culturedcode.com/things/).
Things is a perennial callout for its design and for its Mac-like-ness. But it is not really a stock Mac app at all. The toolbar is not at the top of the window (not an NSToolbar) and it’s not customizable. There is no hint of Liquid Glass style translucency anywhere in their main UI. The content doesn’t slide under the sidebar, for instance. (The one place I can find anything obviously Liquid Glass is the toolbar buttons in the settings window.)
I’ve long been a devoted proponent of using stock Mac UI for, I always thought, good reasons: users are already familiar with that UI and it’s less work to create and update every year.
### Plot twist
I think those reasons (user familiarity and developer effort) may not stand up entirely. At least not these days.
Users have shown — again, I don’t need to prove this — that they don’t think about a stock Mac app vs. custom. Do they dislike Things for not having a toolbar at the top of the window that they can customize in the usual way? No. (The only people who think that way are longtime Mac developers like me.)
Are users able to understand the UI to popular Mac apps — to Things, Slack, Craft, OmniFocus, NotePlan, Bear, Reeder, Telegram, Acorn, Tapestry, Obsidian, Audio Hijack, etc. — without much trouble, no matter how stock or not-stock they are? Yes.
Do they know when an app is an Electron app? Nope: they don’t even have a concept of Electron apps and they wouldn’t care if you explained it to them. (Why should they?)
Users may be already familiar with stock Mac UI (and maybe not, actually, depending on what apps they use) — but I don’t think that matters at all anymore.
### So what about developer effort
The idea was that by using stock Mac UI you the developer would be carried along — you’d get most of the macOS changes every year mostly for free or with not *that* much work, since you’d kept up every year.
But my app NetNewsWire has a very stock Mac UI, and Liquid Glass adoption last year was a lot of work. Using stock Mac UI didn’t save us much — in fact, we had more work to do compared to the apps with more custom UI.
I’ll go back to Things. I’m not picking on them, to be clear. Quite the opposite! I very much respect their work, even though I have in the past wished it were more Mac-like (again, in the way only a longtime Mac developer would).
Here’s their blog post from a year ago [on adopting Liquid Glass](https://culturedcode.com/things/blog/2025/09/things-for-os-26/). They did some work, for sure, at their usual high level of quality. And I’m not denigrating that. But it looks like a lot less work than we had to do on NetNewsWire.
And that’s my point: the level of developer effort was *higher* for the stock Mac app.
### The secret third reason for using stock Mac UI
To recap: the reasons for using stock Mac UI are 1) user familiarity, which we’ve known for a while just isn’t a thing, and 2) hoping to be able to expend less developer effort, which we’ve seen can work against you.
But there’s another reason: the stock Mac UI is designed by Apple, the best designers in the world, and do you really think you can do better? Really?
The app world is full of people who think they’re better and they’re really, really, really not.
Well, I still think Apple has the best collection of UI designers in the world, but, for whatever reasons, the guidance from above on how the Mac UI should look is missing the mark. I’m not blaming the people doing the work — they’re doing great work with the direction they’re given.
So this — bad direction — is where the secret third reason falls down. And we’re left with no real reason to stick with stock Mac UI (except for wanting approval from longtime Mac people like me, and you really shouldn’t care about that at all).
### Messing around last night
With this in mind I wondered how far I could get in removing the parts of Liquid Glass I don’t like in NetNewsWire. Turns out I could get pretty far, though it comes at the expense of using NSToolbar (as predicted).
Note: this stuff is just on a branch. One night of play, not real design or consideration. (But this is code, not mockups.) It’s not about to ship this way. But I’ll share anyway, because it does hint at some possible ideas for NetNewsWire’s future.
Click the small version to get the big version.
(Note that the column view in the second screenshot is going to ship in 7.2. That part’s already done, and it has nothing to do with Liquid-Glass-or-not. Also note: the article theme in use is part of the standard NetNewsWire app right now, not a new thing.)
The obvious first best thing I could do to improve this is to add some color to the toolbar icons and spread them out better. Maybe add some ability to customize, even though it’s not a standard Mac toolbar.
Of course you might look at this and think “Blech! Looks so old! Spare me!” Totally fair!
But it felt cute. Might delete later
## [Wednesday, August 26, 2026](2026/08/26.md)
### [After Fixin’ the Bugs](2026/08/26/after-fixin-the-bugs.md)
Fixed ’em. Fixed ’em all. Well, almost all — down to 10 bugs on the NetNewsWire bug tracker. (See the [Mac 7.1.3 release notes](https://github.com/Ranchero-Software/NetNewsWire/releases/tag/mac-7.1.3) and [iOS](https://github.com/Ranchero-Software/NetNewsWire/releases/tag/iOS-7.1.3-7206) for the big list of just-fixed bugs.)
This means I’ve gotten the app to the place I’ve wanted to get to for a long time, where the bug count is manageable and close to zero.
So it’s 10 bugs at this writing — and 556 [feature requests](https://github.com/Ranchero-Software/NetNewsWire/issues?q=is%3Aissue%20state%3Aopen%20type%3AFeature). Bug fixing never ends, yes, but the good news is that we can *finally* get going on these feature requests.
## So many feature requests
Some of the feature requests are obviously popular: custom smart feeds, content filtering, thumbnails in the timeline, traditional layout on Mac, and similar.
Other requests are less obviously popular but would be appreciated by a number of people: more syncing systems, appearance settings, sorting options, etc.
Some other requests are very small, would take just one or a few lines of code, and seem like an easy win — like [ignoring elements](https://github.com/Ranchero-Software/NetNewsWire/issues/3501) with the `.instapaper_ignore` class.
There are also the feature requests that are fairly niche, which would be a bit of work and not likely to benefit very many people at all, such as a [horizontally flipped layout](https://github.com/Ranchero-Software/NetNewsWire/issues/5395) or [app-specific proxy settings](https://github.com/Ranchero-Software/NetNewsWire/issues/478). But we consider these seriously too — I’ve been surprised when things like this are *way* less niche than I thought or somehow more important than I guessed.
And these days there are the AI feature requests too, mostly for content filtering and summarizing. We will not be doing any AI features, even local AI features, any time soon. I’m cautious about this kind of thing and I know how difficult it is to remove features, and I don’t know right now that AI is right for this app or how it might be right. We’ll see.
### How do I decide which features to do when?
It’s not as simple as just picking the most popular items and doing those first.
One thing to consider is which features depend on others: for example, showing thumbnails in the timeline depends on adding support for enclosures and Media RSS to the feed parsers, which is a separate feature request, which has its own value besides the thumbnails in the timeline.
(Some feeds — Mastodon feeds, notably — include their images as Media RSS enclosures, which is weird but true, and the article display should show those images.)
Another consideration is NetNewsWire’s job in supporting the web. Which features advance the goal of interoperability and making the web itself the social network? This is why NetNewsWire exists, after all.
Other considerations — besides how many people would benefit, besides the web — include how much work, how hard to test, how risky the changes, and any cognitive and anxiety load it may place on users.
And then there’s also my personal whim! I tend to favor features that existed in NetNewsWire of Yore (NetNewsWire 3.3.2, which we’re still chasing in some ways). Some random feature might compel my attention — maybe it’s an interesting challenge, a thing I’ve wanted to do for 20 years, something I’ve wanted to learn about, or maybe I can’t explain why I want to do it, but I do, and that’s that.
You can follow along if you like. I organize [future releases as milestones in GitHub](https://github.com/Ranchero-Software/NetNewsWire/milestones?sort=due_date&direction=asc). Just note that I make changes all the time — nothing is set in stone until it actually ships.
## [Monday, August 24, 2026](2026/08/24.md)
### [Tech Choices](2026/08/24/tech-choices.md)
Of course it’s okay to criticize people for their tech choices — [for returning to X](https://ticci.craft.me/explanation), for instance, as MacStories recently did.
I’m not on X and there’s no way I would return. Fuck that place and fuck Elon Musk. (Yes, there’s a brentsimmons there, but it’s not me. I deleted my account.)
But it’s not like my tech choices are free of fascists and collaborators — and yours almost surely aren’t either.
Do you have an iPhone? A Mac or iPad?
Do you order from Amazon, buy groceries from Whole Foods, or use any of their other properties (Prime Video, Twitch, Audible, etc.)? Do you use AWS or any websites that rely on AWS?
Do you use GitHub or Office or Windows or Azure or Typescript? How about DuckDuckGo, which uses Bing?
Do you run Linux, which now includes AI-assisted code? Do you use Claude or ChatGPT or any of those?
Do you use any Meta social networks (Facebook, Threads, Instagram)?
Do you write Ruby code? (Which features DHH prominently on [its home page](https://www.ruby-lang.org/).)
Do you have an Android phone or use Google search or Gmail or write code in Go?
(Etc.)
* * *
I use Apple stuff and write apps for Mac and iOS, after all, which means my work benefits Apple, which is doing far, far worse things than the MacStories folks could or would ever do.
And yet here I am continuing to write apps for Apple platforms.
Again, yes, it’s not just okay but proper to criticize public people for their tech choices, but I try to remember my own imperfect choices before I do. And, more importantly, I try to remember who the actual enemies are. (Trump, his oligarchs, ICE, Stephen Miller, every single Republican politician, etc.)
These days we need all the righteous fury we can rally — and we also need the clarity to know where to focus it.
## [Friday, August 14, 2026](2026/08/14.md)
### [James Dempsey’s Breakpoints Jam in Seattle Aug. 20](2026/08/14/james-dempseys-breakpoints-jam.md)
One of the highlights of any year for me is when I get to play in a [James Dempsey](https://jamesdempsey.net/music) Breakpoints Jam — and we’ve got one coming up in a few days!
It’s this Thursday Aug. 20 at Stoup Brewing in Ballard. Start gathering around 6 pm to hang with fellow Apple nerds. The show will start around 7 pm.
See the Xcoders post [James Dempsey and the Breakpoints Jam — More Details](https://xcoders.org/2026/08/14/james-dempsey-and-the-breakpoints.html) for the full scoop (including details on where at Stoup, the food truck, etc.).
This year’s band, the conditional Breakpoints, will be me, Laura Savino, and Ken Case. We’ve played together in various configurations before — the Seattle band works. 😎
If you live in or near Seattle, I really hope you can make it! And say hi. I’m friendly. So’s everybody in the band. 🏝️
## [Thursday, July 23, 2026](2026/07/23.md)
### [New NetNewsWire Crash in iOS 27 Beta Has Made Me a Bit Salty](2026/07/23/ios-27-nnw-crash.md)
I returned from a lovely summer vacation (family, beach) to find that iOS 27 beta has fucked up the transition between split view and compact — I’ve got a boatload of crashes, mostly on Pro Max devices and a few on iPad.
Here’s a [representative crash log](https://github.com/Ranchero-Software/NetNewsWire/issues/5371). The feedback in TestFlight all talks about rotating the phone.
Here’s the thing: iOS app development (and Mac, but to a lesser extent) is just constant churn. I thought I was getting a year off this year! But nope. There’s always something.
My theory is that the automatic split view collapsing, which NetNewsWire uses, is just no longer an option, and I’ll have to specify a separate compact view controller.
So that’s just a bunch more work and testing, including testing on previous iOS versions (we go back to iOS 17), and *not* improvements like performance enhancements and new features. It’s just treading water. It’s a waste of time. For what reason? Why?
**Update the next day (24 July 2026):** This bug appears to be have been fixed by Apple in [iOS 27 beta 4 build 24A5390f](https://betawiki.net/wiki/IOS_27.0_build_24A5390f), released July 20, before my report here. I can confirm that I’ve not seen this crash in this new build.
Thank you to the team that prioritized and fixed this!
## [Monday, June 15, 2026](2026/06/15.md)
### [NetNewsWire Status](2026/06/15/netnewswire-status.md)
It’s been a year since I retired — my [last working day](https://brent.writersweb.org/2025/06/06/retirement-day.md) was June 6, 2025 — and I like being able to say that I’ve spent the year adding nothing, not one penny, to shareholder value. 🌴
* * *
My hope for retirement was to get a lot of work done on [NetNewsWire](https://netnewswire.com/).
A year ago it was in sore need of modernization, tech debt pay-off, and bug fixes. People were asking for features, but the foundation needed a ton of work before I could get on to adding new rooms.
Here are some highlights of what we’ve done with 2,188 commits in the past year:
* Adopted Swift structured concurrency and async/await
* Adopted Liquid Glass UI while still supporting recent OSes
* Ported our XML, HTML, and date parsers from Objective-C to Swift
* Fixed a ton of bugs, including crashing bugs
* Reduced battery use, memory use, hang rate, scroll hitch rate, and disk writes
* Did a bunch of performance enhancements, including (especially) finding places where the app could just do less work
* Did a bunch of hygiene things — got GitHub CI running again, started using SwiftLint, turned on treat-warnings-as-errors, started work on localizability, switched to Logger, added tests
* Simplified and refactored code, deleted code, renamed things, etc. — gained clarity in a bunch of places
* Added support for Cache-Control headers for feeds, so publishers can tune how often NetNewsWire checks their feeds
* Optimized iCloud syncing (still more to do on that one)
* Dealt with deprecations (switched to `NWPathMonitor`, for instance)
* Added diagnostics and error reporting to the UI — [iCloud Storage Stats](https://netnewswire.com/help/optimize-icloud.html) and the [Error Log](https://netnewswire.com/help/error-log.html) are shipping, and more like these are currently in beta: [Dinosaurs](https://netnewswire.com/help/dinosaurs.html), [Current Activity](https://netnewswire.com/help/current-activity.html), [Activity Log](https://netnewswire.com/help/activity-log.html), and [Account Stats](https://netnewswire.com/help/account-stats.html).
A list of highlights means I’m glossing over — or not even mentioning — things I really want to tell you about!
For instance, at one point I got frustrated with how I was handling Mac crash logs, so I wrote a little system that downloads them from my server and does symbolication. It’s simple but it makes a big difference — and it means *not* migrating to some commercial system, and having to add their SDK to the app, for this.
* * *
That last bullet point, the one with all the links, is all about giving users insight into what’s happening so that, when the app doesn’t behave as they expect, they can see what’s going on.
Even when they can’t fix the problem themselves, they can at least then copy-and-paste and tell me what’s up so I don’t have to guess. Between this and various bug fixes and improvements I’m able to spend less time on support, which means more time for coding — and, eventually, more time for the new features people are asking for.
* * *
We’re not done with foundational work, but it’s getting close. It’s so much nicer working on this app now than it was a year ago, and I’m so glad we spent the year this way.
I say *we* on purpose — I may contribute the most, but we have a bunch of [other contributors](https://github.com/Ranchero-Software/NetNewsWire/graphs/contributors?from=6%2F14%2F2025), and I thank them all for all their much-appreciated help. Our most prolific contributor after me is [Stuart Breckenridge](https://stuartbreckenridge.net/), who did the Liquid Glass work (among other things) — and who has a new browser-based [RSS reader named Gobbler](https://gobbler.press/) that you should check out!
* * *
PS In the past year we also switched from Slack to a [Discourse forum](https://discourse.netnewswire.com/), so support and discussions can be on the web instead of hidden away. 😀
## [Thursday, June 4, 2026](2026/06/04.md)
### [Seattle Xcoders Presentation by Justin Miller Tonight](2026/06/04/xcoders-justin-miller.md)
I’m psyched for [@incanus](https://mastodon.social/@incanus) Justin Miller’s presentation tonight at Xcoders on “Swift Result Builders Case Study: Parsing.” I like writing parsers, and I’m very curious about Swift result builders. Should be a good one!
See this [post on the Xcoders blog](https://xcoders.org/2026/06/01/xcoders-presentation-with-justin-miller.html) for more details about the talk and for when and where to be.
## [Tuesday, March 3, 2026](2026/03/03.md)
### [I Tried to Explain What I Do](2026/03/03/i-tried-to-explain-what-i-do.md)
I’ve known for decades that most of family and friends (except for family and friends in tech) have no idea what I do — they just think it’s math-heavy and mysterious.
Well. It’s definitely not math-heavy and it shouldn’t be mysterious. So I figured I’d write up [What I Do](https://inessential.com/what-i-do.html).
Even if I never actually send this page around to everybody — because that would actually be kind of weird, like giving them homework to understand *me*, me who suddenly (suddenly?) seems like a complete narcissist — it was a good exercise for me to do anyway. Especially the part about explaining why I write NetNewsWire.
## [Monday, March 2, 2026](2026/03/02.md)
### [Seattle Xcoders Talks This Week Considered Unmissable](2026/03/02/seattle-xcoders-talks.md)
The title is a little over the top, but barely — we have two fantastic talks this Thursday (March 5) that you should go to. (I’ll be there!)
[Laura Savino will present](https://xcoders.org/2026/02/27/xcoders-talk-by-laura-savino.html) “Learn Out Loud”:
> As devs today, we’re supposed to demonstrate immediate skills in tools whose configs change once a fortnight, while shipping cutting-edge features in long-standing apps (that may still have a legacy bug or two). Laura is a trained teacher and Photoshop engineer who brings humor and solidarity to today’s dev environment with concrete advice on the mechanics of real learning and change, including encouraging without proselytizing, being vulnerable about what you don’t know, and staying curious amidst existential dread.
If you’ve seen Laura talk before, then you know how good she is, and you know how you come away with insights and ways to be a better engineer and better human-who-works-with-people. Every single time.
This is one of those very rare chances to see Laura in a small setting before she does this talk at a conference keynote. Like seeing the Beatles in a small bar in Liverpool, only it’s Laura in Seattle. 🎸
[Jake Savin will present](https://xcoders.org/2026/03/02/xcoders-talk-by-jake-savin.html) a talk on using Claude to do a really big ambitious job — rebuilding UserLand Frontier as a modern app:
> It’s a huge job and Jake’s made a ton of progress — and he’s learned a lot about how to use Claude to make these kinds of projects work. As we learn to use LLMs to do more and more ambitious things, we’ll be walking in Jake’s footsteps. Jake will provide a map of this new territory.
I’m not the only one to have a try — more than one try, actually, as recently as last year — at rebuilding Frontier. It took Jake and Claude together to make this work (and it’s not done yet, but *far* advanced from any previous try).
I’m so ready to have Frontier back in my toolbox — and ready to learn from Jake on how he’s making this happen.
What’s Frontier?
> UserLand Frontier is [Dave Winer](http://scripting.com/)’s app from the ’90s, and it was with that app that Dave invented and/or fleshed-out and popularized much of the open web that we take for granted today: blogs, RSS, podcasts, and web services, for starters. This is a historically important piece of software, and Jake is bringing it to the modern age.
Anyway — here’s the scoop on where and when to be:
**Where**
North Seattle College
9600 College Way N
Room LB 1106 in the library
**When**
Thursday, March 5, 2026
6:30 pm — gather and mingle
7:00 pm — watch Jake’s and Laura’s talks
For anyone who wants to hang out after — we go to the nearby [Watershed Pub and Kitchen](https://www.watershedpub.com/) (all ages friendly).
## [Friday, February 27, 2026](2026/02/27.md)
### [Why Objective-C](2026/02/27/why-objective-c.md)
[In my previous post](https://brent.writersweb.org/2026/02/18/why-not-objective-c.md) I talk about how I got rid of hundreds of thousands of lines of Objective-C code while at Audible and I explain *why* keeping Objective-C code around is a terrible idea. And I explain that…
> I’m not stuck in the old ways; I’m not the guy insisting on the supremacy of Objective-C despite the obvious evidence against. I’m the guy who got rid of Objective-C — with glee and (oops, sorry Audible marketing team for the screwup) wild abandon!
Then of course I wrote some Objective-C code recently and really, really loved it.
### Command line app
I wanted to replace my homegrown static website/blog generator because I no longer wanted to use the language it was written in, for reasons.
I took it as an opportunity to learn Python — but it turned out that my heart wasn’t in it (not Python’s fault; great language) and I ended up screwing it up. (See [Blog Fuckup](https://brent.writersweb.org/2026/02/01/blog-fuckup.md)).
I thought about some alternatives: Swift, which I know well; Rust and Go, which would have the advantage of helping me branch out from the Apple ecosystem; and good old C, my happy-go-lucky friend who still sprints faster than every brash new language.
Of those I was leaning toward C because speed is an issue. I wanted to make rendering this blog, over 25 years old and with thousands of posts, to happen in under one second. The system I was replacing took a few seconds. But I wanted more speed (personality flaw).
And then I thought, I swear just for a split second, about how great it would be if C had something a little nicer than C structs for modeling my app’s data — and oh well too bad there’s nothing like that.
And then I remembered Objective-C, which is C plus some things a little nicer than C structs. 🎩🦖
### Objective-C looks insane
Anyone new to Objective-C thinks it’s difficult and maybe a bit harsh because `[[those squareBrackets] lookInsane:YES]`.
Once you get past that, which takes a day or two given a good-faith effort, you’ll realize how small a language it is, how easy to hold in your palm and turn around and understand all sides of it. And you’ll appreciate how easy it is to make good decisions when you don’t have a surplus of language features to choose from.
And you’d be reassured to know that Objective-C is probably never going to change, which means tech debt will accumulate much more slowly than with newer languages. (Unless, of course, you count Objective-C itself as tech debt. You don’t have to, though.)
It’s a cliché to call Objective-C a more elegant weapon for a more civilized age. It’s better thought of, these days, as a loaded footgun.
But I did absolutely love writing this code! So much fun. And now I’ve got another little thing brewing, also in Objective-C, coming soon-ish.
PS [The website/blog generator app is called SalmonBay](https://codeberg.org/brentsimmons/SalmonBay). I really don’t expect anyone else in the world to use it, and I expect no contributions, but it is available as open source. (I put it on Codeberg, for reasons.)
PPS SalmonBay does a clean build of this blog in under a second. 🎸
## [Wednesday, February 18, 2026](2026/02/18.md)
### [Why Not Objective-C](2026/02/18/why-not-objective-c.md)
At my last job, at Audible (hi Audible folks, if you’re reading this!), I led the effort to port our remaining Objective-C to Swift. When I started that project, Objective-C was about 25% of the code; when I retired it was in the low single digits (and has gone even lower since, I’ve heard).
Why do this? It was working code! Don’t we all know not to rewrite working code?
### Why get rid of Objective-C
Well, we knew a few things: one was that our Objective-C code was where a lot of our crashing bugs and *future* crashing bugs (and bugs of all kinds) lived.
So it was working code, yes, but we knew there were crashes hidden in there, and that some of those crashes were ambush hunters, playing the long game, waiting for years before pouncing. Best just to rewrite it all in Swift, the safer language.
A second thing we knew was that having to interoperate between Swift and Objective-C is a huge pain. It often means dumbing-down the Swift code and not using modern features, which limited our options for good Swift code.
And a third thing we knew was that very few of our engineers had a background writing Objective-C. Maintaining that code — fixing bugs, adding features — was more expensive than it was for Swift code. (Duh, right? When you have many engineers working on a project, it’s best if the language you use is one everybody knows well.)
### Not that this went perfectly
This is still risky, by the way. Rewriting code is always risky.
At one point I was responsible for a bug where we sent an integer to some API and it should have been a boolean — because the original code was using NSNumber and it wasn’t obvious which it should be. This caused a partial outage of push notifications, which I estimated (very roughly) to have cost the company a few hundred thousand dollars.
(Really? A little bug like this? NS-fucking-Number cost all this money? Yes. Audible scale may not be Facebook scale, but it’s far beyond the scale of indie apps. Before Audible I always worked for smaller companies with smaller audiences — working on something with many millions of users was enlightening and terrifying.)
But here’s the thing: this proved my point. Someone trying to maintain that code as Objective-C might have easily made the same mistake and caused the same outage. The Swift code we replaced it with is type-safe: it’s unmistakably and clearly a boolean and not an integer (once we fixed it; other way around at first). Replacing Objective-C code with Swift is clearly a win.
### Goodbye to all those square brackets
I didn’t count how many hundreds of thousands of lines of Objective-C my project was responsible for rewriting (and sometimes just deleting). It was a lot. Multiple entire apps could fit in those lines-of-code counts.
And if you look at [NetNewsWire’s code](https://github.com/Ranchero-Software/NetNewsWire), you see that it’s almost entirely Swift, with just a little Objective-C for the various parsers and FMDB. It’s not just a Swift app but a modern Swift app that uses async await and structured concurrency. (Mostly modern — there’s still some code to update to async await. Work continues.)
I say all of the above to show that I’m not stuck in the old ways; I’m not the guy insisting on the supremacy of Objective-C despite the obvious evidence against. I’m the guy who got rid of Objective-C — with glee and (oops, sorry Audible marketing team for the screwup) wild abandon!
I want you to know all the above in advance because in my next post I’m going to talk about how I wrote some new code in Objective-C and loved it.
## [Sunday, February 1, 2026](2026/02/01.md)
### [Blog Fuckup](2026/02/01/blog-fuckup.md)
I’ve been working on my blog software (a static site generator) and I managed to screw things up enough that random old posts got published on the site and in the RSS feed.
As soon as I saw the issue I fixed it, but I’ve been getting email from folks about some of the posts, so I know they got picked up by some RSS readers.
Those posts are ancient! Sorry for the confusion.
## [Wednesday, January 21, 2026](2026/01/21.md)
### [Email from Family in Minnesota](2026/01/21/email-from-minnesota-family.md)
Our family in Minnesota knows we worry about them, and so yesterday they sent a family-wide email.
This is surely one of many thousands like it. Maybe you’ve written one of these. Maybe you will write one of these.
Below is the email from Jen (with permission and with original formatting):
### Update from MN
Hello family and friends outside of Minnesota,
Many of you have reached out to see how we are doing and Pete and I both thank you for that. We appreciate it. As middle-class White people, Pete and I are largely ok. Technically, speaking. And I cannot believe that is a sentence I just typed in the year 2026. But here we are. Our neighborhood is relatively quiet. For now. We are doing what we can to support those that we can. We are speaking out and calling our representatives. So far 20,000 people in this state have taken conscientious bystander training. As actors, Pete and I have created/rehearsed monologues or responses if we find ourselves witnessing the illegal doings of these "agents". The people here are subdued, but not hopeless. Defiant, but not violent. We are doing our best to protest peacefully as this is what our constitution allows.
Why do I write to you of these things?
For a few reasons:
1. Depending on what media you are seeing you may be getting no coverage on this or varying degrees of truth to outright propaganda. I thought it best you hear it from someone who is actually living in MN right now.
2. No matter where you fall on the political spectrum I believe we can all agree that we have rights in this country: free speech, the right to peacefully protest, the right to due process to name a few.
3. Any support we can get, even if it is simply trying to combat disinformation with truth, from within our country or around the world is helpful and important.
4. If you wish to do other things, this is a good website which compiles many places/groups that are trying to help combat this situation. [https://www.standwithminnesota.com/](https://www.standwithminnesota.com/).
Now to some things that are happening here:
In addition to Jonathon Ross murdering Renee Good, the very same day they went to a high school and attempted to arrest students and staff. One day after this, 6 men with guns kicked in the door of someone's home **without a legal warrant** and dragged the husband out in cuffs. He is an American citizen. Today local law enforcement in and around the Twin Cities held a press conference calling out these "agents" in breaking the law. They are now targeting and attempting to detain off-duty officers. Every single one of the officers they targeted are people of color. It is straight up racial profiling. They are smashing car windows and tear-gassing people including toddlers. *People are carrying their passports and birth certificates around with them* and often they are not even allowed to show these "agents" their paperwork before they are beaten and/or abducted.
I have a dear friend who passed her citizenship test 6 years ago and is now carrying her documentation with her wherever she goes. She did everything "the right way" yet she is worried. Frankly, because she doesn't look Hispanic or African she will probably be ok. Again, I can't believe I just typed this sentence. Our nephew's elementary school (in a very affluent, predominantly White suburb) canceled their school's International Night for fear it would draw Immigrant Enforcement to the school. Pete and I are witnessing field trips to the Science Museum cancel left and right because schools are afraid they will target the children.
These people are not targeting the "worst of the worst" as they claimed they would do. They are not following the law or allowing due process. Minnesota is under siege. They are now telling observers who are giving witness and recording these crimes that "they should learn a lesson or they will be next." Currently, these "agents" outnumber our local law enforcement 4 to 1. Donald Trump and Noem have particularly targeted Minnesota even though our state falls far behind other states in the amount of undocumented workers. Everyone is on edge. No one is untouched by this chaos.
I don't know what is going to happen. I don't know what has happened to empathy and humanity. I do know that I wouldn't be here if it weren't for my ancestors who immigrated here from Sweden, England, Ireland, and the Netherlands. But they did. So for their legacy and for the little kids who deserve to live without fear I will continue to show up and help where I can.
Thanks for taking the time to read this and feel free to share this with those who may be curious to what is actually happening in Minnesota.
Love to all of you. Take care of each other.
Jen and Pete
## [Wednesday, November 5, 2025](2025/11/05.md)
### [NetNewsWire 6.2: RSS Plus Markdown](2025/11/05/rss-plus-markdown.md)
On the NetNewsWire blog I’ve just announced NetNewsWire 6.2 for Mac and iOS.
This release is almost entirely bug fixes — but it does add a couple small features and one potentially interesting one: it now supports Markdown in RSS (via the `source:markdown` element). [Read all about it](https://netnewswire.blog/2025/11/05/netnewswire-for-mac-and-ios.html) on the NetNewsWire blog.
(And now we’re working on NetNewsWire 7, which [will adopt the new Liquid Glass UI](https://netnewswire.blog/2025/10/07/the-liquid-glass-plan.html).)
## [Saturday, October 4, 2025](2025/10/04.md)
### [Why NetNewsWire Is Not a Web App](2025/10/04/why-netnewswire-is-not-web-app.md)
[Tim Bray writes](https://indieweb.social/@timbray@cosocial.ca/115311601617081367), on Mastodon, I think correctly:
> The canceling of ICEBlock is more evidence, were any needed, that the Web is the platform of the future, the only platform without a controlling vendor. Anything controversial should be available through a pure browser interface.
This is not the first time I’ve had reason to think about this — I think about issues of tech freedom every day, and I still bristle, after all these years (now more than ever), at having to publish NetNewsWire for iOS through the App Store. (The Mac version has no such requirement — it’s available via the [website](https://netnewswire.com/), and I have no plans to ever offer it via the Mac App Store.)
But what if I wanted to do a web app, in addition to or instead of a native app?
I can picture a future, as I bet you can, where RSS readers aren’t allowed on any app store, and we’re essentially required to use billionaire-owned social media and platform-owned news apps.
But there are issues with making NetNewsWire a web app.
### Money
I [explain in this post](https://brent.writersweb.org/2023/02/20/on_not_taking_money_for_netnewswire.md) that NetNewsWire has almost no expenses at all. The biggest expense is my Apple developer membership, and I pay just a little bit to host some websites. It adds up to a couple hundred bucks a year.
If it were a web app instead, I could drop the developer membership, but I’d have to pay way more money for web and database hosting. Probably need a CDN too, and who knows what else. (I don’t have recent web app experience, so I don’t even know what my requirements would be, but I’m sure they’d cost substantially more than a couple hundred bucks a year.)
I could charge for NetNewsWire, but that would go against my political goal of making sure there’s a good and *free* RSS reader available to everyone.
I could take donations instead, but that’s never going to add up to enough to cover the costs.
And in either case I’d have to create a way to take money and start up some kind of entity and then do bookkeeping and report money things to the right places — all stuff I don’t have to waste time on right now. I can just work on the app.
Alternately I could create a web app that people would self-host — but there’s no way I could handle the constant support requests for installation issues. There are free self-hosted RSS readers already anyway, and NetNewsWire would be just another one. This also wouldn’t further my goal of making a free RSS reader available to everyone, since only people with the skills and willingness to self-host would do it.
### Protecting Users
Second issue. Right now, if law enforcement comes to me and demands I turn over a given user’s subscriptions list, I can’t. Literally can’t. I don’t have an encrypted version, even — I have nothing at all. The list lives on their machine (iOS or macOS). If they use a syncing system, it lives there too — but I don’t run a syncing system. I don’t have that info and can’t get it.
If that happened, I’d have to pay a lawyer to see if the demand is legit and possibly help me fight it. That’s yet more money and time.
(Could I encrypt the subscription lists on the server? Yes, but the server would have to be able to decrypt it, or else the app couldn’t possibly work. Which means I could decrypt the lists and turn them over.)
### Another type of freedom
Not an issue, exactly, but a thing.
I was 12 years old when I got my first computer, an Apple II Plus, and I’ve never stopped loving the freedom of having my own computer and being able to run whatever the hell I want to.
My computer is *not* a terminal. It’s a world I get to control, and I can use — and, especially, *make* — whatever I want. I’m not stuck using just what’s provided to me on some other machines elsewhere: I’m not dialing into a mainframe or doing the modern equivalent of using only websites that other people control.
A world where everything is on the web and nothing is on the machines that we own is a sad world where we’ve lost a core freedom.
I want to preserve that freedom. I like making apps that show the value of that freedom.
What I want to see happen is for Apple to allow iPhone and iPad users to load — not *sideload*, a term I detest, because it assumes Apple’s side of things — whatever apps they want to. Because those devices are computers.
I get it. It’s not looking good. And even with the much greater freedom for Mac apps there is still always the possibility of being shut down by Apple (by revoking developer memberships, refusing to notarize, or other technical means).
Still, though, I keep at it, because this freedom matters.
But, again…
Apple keeps doing things that make us all feel sick. Removing ICEBlock is just the latest and it won’t be the last. So I am sympathetic to the idea of making web apps, and my brain goes there more often. And if I could solve the problems of money and of protecting users, I’d be way more inclined.
## [Thursday, August 28, 2025](2025/08/28.md)
### [Writing Mac and iOS Apps Shouldn’t Be So Difficult](2025/08/28/easy-app-writing.md)
In the ’90s and early 2000s I worked for UserLand Software — [Dave Winer](http://scripting.com/) was founder and CEO — on a Mac app called UserLand Frontier.
The app was a scripting system and hash-table-oriented database that powered the early blogging and podcasting worlds. (That sounds grand, but it’s probably an understatement — but this post isn’t all about Frontier’s impact on the web, so I won’t go into details.)
The app was implemented in two pieces:
* The *kernel*, written in C, implemented the database, networking, inter-application communication, various built-in data types, script compiler and evaluator and debugger, and so on
* The *scripts* used the kernel and implemented most of the actual app behavior
Since it was an app, it had plenty of UI — menus, contextual menus, buttons, larger UI components, and so on. What was brilliant was that you could, for instance, add and edit menus, and when you chose a menu command it would run your script. (Or when you clicked a toolbar button, etc.)
You could write an entire static blog publishing system and the UI to go with it without ever restarting the app. Click a thing, then see what happens in the app — and if it’s not right you’d edit the script, which would be automatically recompiled when called the next time.
In other words, there was absolutely no friction when it came to iteration. Write some code without restarting and see your changes immediately.
### How good was this really in practice?
You might imagine that we could do this for an hour or so before having to make changes to the kernel. Not so.
In fact, for the first three years I was there (might have been longer), I never even *saw* the kernel code. I worked all day every day as a professional developer at the script level, never having to restart the app. Just iterating like this all day long.
You might also imagine that the app was sluggish and slow since much of it was scripts instead of C code. It wasn’t! Scripts could be slow for the same reasons any code could be slow (I/O, of course, and algorithms and data structures not suited to the problem at hand) — but the app never felt slow.
I’ll remind you of the timing: *this was the ’90s.* We worked this way for real, and we were amazingly productive.
A scripting language plus key bits implemented in C was more than fast enough for an app. Even all those years ago.
### A scripting language built for productivity
I’m not writing this article to praise Frontier — I’m talking about it to make a point, which I’ll get to.
But I wanted to bring up a second aspect to this: it’s not just frictionless iteration that was so great, it was also the scripting language and environment.
One of the best parts of this was how easy persistence was. I mentioned the hash-table-based database. Hash tables could contain hash tables (Swift developers: picture a Dictionary inside a Dictionary, and so on).
(We just called them tables for short — but remember that these are hash tables, not tables in a SQL database.)
In any script, at any time, without any ceremony, you could read and write from the database simply using dot notation: `user.prefs.city = "Seattle"` would set the value of `city` in the `prefs` table which was contained by the `user` table. This value would persist between runs of the app, because it was stored in the database.
(You could also pass around addresses of things too — it was quite common to pass the address of a table to another script, so that the other script wouldn’t need to hardcode a location.)
It was utterly automatic. And it meant that while we did have to choose where in the database to store things, and how to structure our storage, we didn’t have to choose a storage mechanism. It was the database.
(Note: of course we could read and write files, and did so when necessary. But the point is that the database handled almost all our persistence and in a super-easy way.)
(Also note: the database had a UI. It was visible and browsable. You could and often did hand-edit it. Even the scripts lived in the database, and were addressable via dot notation, like everything else.)
### We had nice things!
I’ll say again — this was in the ’90s, more than 25 years ago, and it was a great way of working on an app.
I’m not saying apps these days need to be Frontier-like in any details. But it seems absolutely bizarre to me that we — we who write Mac and iOS apps — still have to build and run the app, make changes, build and run the app, and so on, all day long. In the year 2025.
And it seems retro in the worst way that we’re still using anything other than a scripting language for most of our code. We should be using something simple and light that can configure toolbars, handle networking callbacks, query databases, manage views, and so on. And maybe with a DSL for SwiftUI-like declarative UI.
Almost none of that code needs to be in a lower-level language like Swift or Objective-C. It really doesn’t. (I say this as a performance junkie!)
It could be in Ruby, Lua, Python, or JavaScript. Better still would be a new language invented specifically for the problem of writing apps, something designed to make the common challenges of app writing easier.
We did have this stuff decades ago. Not for app making in general, sure — but now it’s 25 years later, and a company like Apple could make this real for all its app makers.
It’s easy to see why things are the way they are right now, and you can point to a string of good decisions. No doubt.
But we can think outside of what we have now and ask: what would make app writing easier? What would make it a better experience? How could we get more done for our users with fewer bugs and faster turnaround?
I’m not saying that Frontier’s specific choices are the answer — I’m saying that the combination of frictionless iteration plus a purpose-built scripting language was extremely powerful, and we could use those things now.
And at some point I suspect these things are going to be table stakes for any platform that wants to attract developers. If you were a new developer right now, would you pick Xcode’s build-and-run, edit, build-and-run, edit — plus the growing complexity of Swift — over something like Electron and JavaScript?
### Random notes
Yes, I know about [PyObjc](https://en.wikipedia.org/wiki/PyObjC) and [RubyCocoa](https://en.wikipedia.org/wiki/RubyCocoa). Without first-class support in Apple’s developer tools, these were never going to work as popular alternatives.
I also know about (and use) Swift playgrounds and SwiftUI previews. Neither of these are as satisfying to use as I’d like, and neither of these are nearly as great as frictionless iteration in the actual app.
I also remember Xcode fix-and-continue, which didn’t work well enough to solve the problem of frictionless iteration.
Anyway… One more thing about Frontier: we had a system where people could get updates to the app automatically via the web. Those updates were just serialized versions of scripts at various database locations, which would get unpacked and stored in each user’s database. (Those who opted-in, of course.) The app would not have to be restarted to get bug fixes and new features! And of course the updates were very small, since they didn’t include the entire app. This seems so futuristic, but we had this in 1999. Why couldn’t we have this now?
## [Monday, August 25, 2025](2025/08/25.md)
### [Tough Season in the Apple Fields](2025/08/25/tough-season.md)
We’re adopting Liquid Glass for NetNewsWire 7, which we’ll release some time after the new versions of macOS and iOS come out.
Stuart Breckenridge has been doing great work on getting this done — and he’s written up a couple blog posts (with screenshots!) on his progress. See:
[Adopting Liquid Glass, Part II (NetNewsWire Mac)](https://stuartbreckenridge.net/adopting-liquid-glass-part-ii-netnewswire-mac/)
[Adopting Liquid Glass, Part III (NetNewsWire iOS)](https://stuartbreckenridge.net/adopting-liquid-glass-part-iii-netnewswire-ios/)
Since the app is made with mostly stock Apple UI, you might think that using Liquid Glass would be very little work, that it might be pretty automatic or just a matter of checking a few boxes. But that’s not true this year: it’s been a fair amount of work.
Other apps, apps with more custom UI, will probably have even more work, but even for us it’s been more than a bit.
And we’re not done. There will be little things (hopefully just little things) still to do before shipping. Including verifying that it all works as expected on the actual OS releases.
But all credit to Stuart, who got right on this and did a superb job.
(Note: if you want to see the code, you can: it’s on our [experimental/liquid-glass branch](https://github.com/Ranchero-Software/NetNewsWire/tree/experimental/liquid-glass).)
### But My Mac
As pleased as I am with Stuart’s work, I’m not pleased with Liquid Glass itself.
I don’t really care about it on iOS/iPadOS, because whatever. I don’t love those devices. I love Macs because it’s on Macs where you can set out to make new things that change the world.
(Okay. Fine. On iPhones and iPads you *can*, I guess, but generally it’s much harder, and it has to be an approved activity using an approved app. And one thing you definitely can’t do on those devices is create apps. [All apologies to people who do manage to edit their podcast episodes on an iPad or write at length on an iPhone. Cool! But I hope that even those folks will grant me my point.])
And so I seriously dislike the experience of using a Mac with Liquid Glass. The UI has become the star, but the drunken star, blurry, illegible, and physically unstable. It makes making things way more of a struggle than it used to be.
We had pretty good Mac UI, but Apple took the bad parts of it — the translucency and blurriness already there — and dialed it way up and called it content-centric. But it seems to me the opposite. Liquid Glass is Liquid-Glass-centric.
### Perspective
First thing: I have many friends at Apple and I didn’t want to write any of this. And there are legions of engineers and designers who I don’t know but whose work I respect greatly. It’s not their fault that this is the direction of the UI.
And this is not the first time we’re going through a rough patch with Apple. I think of them as seasons — we had, for instance, terrible-keyboard season not so long ago. We were wondering if Apple would just stop making Macs altogether. But then that passed and we even got these wonderful Apple Silicon machines. Seasons end.
And we’re in a tough season with Swift these days too. It’s gotten so complex and difficult that I find myself daydreaming about going back to Objective-C. Objective-C is definitely funny-looking, but once you get past that it’s actually small and simple.
But with [Swift approachable concurrency](https://www.donnywals.com/what-is-approachable-concurrency-in-xcode-26/) and other changes I can see eventually getting through this season and to a pretty great place, so I’m optimistic.
Seasons do end, in other words, or mostly seem to end (though not the App Store monopoly season, not so far), and I’ve resolved to just wait for Liquid Glass’s replacement. Perhaps along the way it will get refined enough so that people like me can use it without eye strain.
### Better Perspective
But far, far worse than any of the above is Tim Cook’s gold statue presented to the President. And everything that went along with that. I felt utterly sick and I bet you did too. (And it made me seriously wonder if I wanted to continue writing apps for Apple platforms.)
I understand John Gruber’s argument in [Gold, Frankincense, and Silicon](https://daringfireball.net/2025/08/gold_frankincense_and_silicon) that maybe Cook’s move was the best possible move in a terribly corrupted system.
But what’s the use of being so rich and so powerful, I would ask Tim Cook, if you, even more than regular people, have to debase yourself before the dictator?
It’s tempting to think that our current government is just a season, like the bad keyboards or like Liquid Glass will eventually prove to be. Wait till the mid-terms or the next presidential election, you might think.
But there’s no reason to think that this authoritarian turn is just a season. Something besides just wishing and waiting for better is required.
## [Monday, August 18, 2025](2025/08/18.md)
### [Breakpoints Show Thursday in Seattle](2025/08/18/free-breakpoints-show.md)
James Dempsey and the Breakpoints will be appearing in a [Breakpoints Jam this Thursday](https://xcoders.org/2025/08/12/special-event-breakpoint-jam-with.html) (Aug. 21) at Bale Breaker in Ballard. Free show! Awesome songs!
The event starts at 6 pm and music will start around 7 pm. I’ll be on guitar — and you can expect local superstars Ken Case (keyboard, vocals) and Laura Savino (vocals) plus a special mystery guest or two from out of town.
The show will be mostly acoustic, and it will be outside at the picnic tables. I hope to see you there!
## [Friday, June 13, 2025](2025/06/13.md)
### [Saturday March](2025/06/13/saturday-march.md)
Tomorrow is [No Kings](https://www.nokings.org/). There’s one near you!
Chatting with my friends about how I hate these fascist assholes doesn’t do a damn thing. Protests work. (Imperfectly, sure, with no guarantees. But it sure beats _not_ protesting.)
## [Friday, June 6, 2025](2025/06/06.md)
### [Retirement Day](2025/06/06/retirement-day.md)
I wrote in my [love letter to my colleagues at Audible](https://brent.writersweb.org/2025/05/23/love_letter.md) that retirement is coming up — and now it’s here. Today’s the day!
I’ve attended my last meetings. I’ve said my goodbyes. My laptop’s ready to ship back to Audible HQ.
* * *
I started working in 1984, while in high school, busing tables part time at [Schaefers Canal House](https://www.schaeferscanalhouse.com/) in Chesapeake City, MD.
And I stopped working this day in 2025, almost 41 years later, as a senior engineer (which is surprisingly a lot like busing tables — lots of cleanup and setting the table just right for the customers to have a great time).
Along the way I worked on, among other apps, Userland Frontier, NetNewsWire, MarsEdit, Glassboard, Vesper, OmniFocus, OmniOutliner, and Audible.
* * *
My immediate plan — Exhale! Breathe. Enjoy a steak. Watch WWDC from the comfort of home next week. Get back to work on NetNewsWire.
🌲
## [Saturday, May 24, 2025](2025/05/24.md)
### [Retirement and NetNewsWire](2025/05/24/retirement_and_netnewswire.md)
To answer some questions people have asked me about my impending retirement…
#### What does it mean for NetNewsWire?
Good things! I’m not retiring from writing apps — which means I’ll have a lot more time for working on NetNewsWire.
It’s been 15 years since the last time I could work on NetNewsWire during weekdays (as opposed to just nights and weekends), and I’m super-psyched for this.
#### Will you work on any other apps?
Yes. I have several ideas for other apps I’d like to work on, and have made a little progress on one of them.
They will all be free and open source. I have no plans to create apps for money. (I’ll be retired — *not working for money anymore* is the point.)
#### Will you be taking a big trip right after retiring?
Every time this comes up, I joke that the first thing I’ll be doing is *sleeping*. Forty years of work is a long time, and I’ve earned a long nap.
We do have some travel plans, but no big trips yet. We will. There’s so much of the world we want to see!
My actual first week of retirement will be taken up by WWDC. I won’t be there — I’ll be at home watching the videos like most everyone else. Only this time I won’t have to think about how the changes will affect things at work.
#### Do you have any other hobbies or plans? Are you getting into woodworking? Pizza-making?
Yes to other hobbies and plans, though probably not woodworking or pizza (but never say never — those are pretty tempting ideas!).
Making apps is important to me — contributing to the public stack is how I can best use my abilities to make the world better — but it’s also not the only thing.
I have more ideas than time, which is a good problem to have, and once I have some space to think and feel I’ll be able to start picking and get to work.
#### Will you be blogging more?
I hope so!
The hard part is, after 25 years, finding things to say that I haven’t already said. Maybe I’ll just decide it’s okay to repeat myself in new ways. 🐥
## [Friday, May 23, 2025](2025/05/23.md)
### [My Wildly Incorrect Bias About Corporate Engineers](2025/05/23/love_letter.md)
Before I went to work for Audible (five years ago now — time flies!) I had a bias about engineers that worked for large corporations. I assumed that they weren’t as good as indies and engineers at small companies, or else they’d actually *be* indies or work at small shops like Omni.
Obviously I knew there had to be exceptions, particularly at Apple, or else we wouldn’t have had great things like AppKit and UIKit and everything else we’ve built on over these years. But the bias persisted.
* * *
Before Audible, the largest company I’d ever worked at (Newsgator) had just over 100 people. When I worked at Omni it had roughly half that number.
I’ve spent half my career working at even smaller companies, with just me and Sheila (Ranchero Software) or at places with three people (Q Branch) or like six people (UserLand Software).
And of course I was arrogant enough to think that I was better — much better — than any corporate engineer. While a corporate engineer might own some small part of an app or framework — or just a single button, as the (lame) joke went back in the day — I was shipping entire apps on my own or with a very small team. Popular, valuable, newsworthy apps that people loved.
And I wasn’t the only one: think of [Flying Meat](https://flyingmeat.com/), [Rogue Amoeba](https://rogueamoeba.com/), [Bare Bones](https://www.barebones.com/), [Red Sweater](https://redsweater.com/), [The Iconfactory](https://iconfactory.com/) and many more.
* * *
And so I learned very quickly when I started at Audible that I was *very* wrong. I was impressed, and grew more impressed as time went on, by my fellow engineers’ rigor, talent, professionalism, care, and, especially, ability to work with other people toward common goals.
While I’m the die-hard introvert who just wants to go into a room and sit in front of a Mac and write some code and get things done, I learned that my co-workers — even if they, like me, kinda just wanted to sit and write code — were great at app development as a team sport. I was impressed with how they wanted to grow and did grow — always leveling-up their individual skills *and* their ability to work on a team and across teams.
And what a team it was! It’s not a new observation, but the indies I mentioned above, and the ones I didn’t, tend to be white men born in the United States — the people who could most afford to fail, in other words, because for them (for me, absolutely) there’s *always* another opportunity.
My team didn’t look like that — it was quite a contrast with my previous experience. Many more women, people of color, people born outside the United States. (But note that there’s always more progress to be made!)
The engineers on my team could write apps as well, if not *better* in many cases, than the indies I know. And the ones who aren’t quite there yet — well, just give them a little more time. They’ve all given me reason to believe in them.
I regret my bias about engineers working in corporate environments, and I’m so glad I learned the truth almost from day one on starting at Audible.
* * *
For a couple years I did a lot of hiring — a lot of interviews — at Audible. And I noticed something: there was a strong correlation between being hirable and having worked with other people.
The folks who’d worked largely by themselves, or on just one small team, weren’t as good candidates as the folks who’d worked with more people. This, of course, went against my original bias that indies are the best engineers — but by then I knew that a candidate who’d worked with lots of other people had been exposed to more code, more dilemmas, more challenges (technical and human), and they were not just more ready to work on a larger team but more knowledgeable. Even their individual skills were greater.
Advice time: if you’re a newer engineer, find ways to work with other people. Not just because you’re more likely to get hired at a place like Audible — but because, no matter where you want to work, you’ll be better at it.
You can’t just sit alone in front of your computer all day and write code and expect to be a great engineer.
Lesson learned!
* * *
With retirement imminent — this is my last job, and June 6 is my last day (maybe I’ve buried the lede here) — I want to thank my team publicly for how they’ve made me a better engineer and, more importantly, a better person. From the bottom of my heart.
I learned more from them than I could ever have taught; I got the better part of this deal.
Thank you, team! So much. ❤️
## [Sunday, March 16, 2025](2025/03/16.md)
### [Seattle Xcoders Presentation Meetings Return](2025/03/16/seattle_xcoders_presentations_return.md)
Thanks to the enterprising and tireless Xcoders organizers (not me — I’m just the PR guy), we’re finally returning to presentation meetings. At long last!
Thursday, April 3. [Read all about it on the Xcoders blog](https://xcoders.org/2025/03/16/seattle-xcoders-returns-to-presentation.html).
## [Thursday, October 31, 2024](2024/10/31.md)
### [Harris for President](2024/10/31/harris_for_president.md)
Donald Trump is a gross villain and a traitor to our country. He’s a convicted felon, adjudicated rapist, and head of a criminal organization; he works with criminals and he pardons criminals; he’s a narcissist and violent insurrectionist, racist and misogynist; he’s the master of lies and corruption and self-serving.
He plans to rule as a fascist dictator, and this time has the backing to do so, for the benefit of him and his ultra-wealthy friends. Not for you.
For everybody else, the various enemies within — everybody who isn’t a straight white male who goes along with the program — there will be concentration camps, deportation, prison, and rumors and threats of each. There will be more deaths in hospital parking lots.
I have voted for Kamala Harris. I ask you to vote for her too.
I happen to think Harris would be very good, possibly even great, as president. But it hardly matters!
Voting for her is how we stop this. And we have to stop this.
## [Wednesday, October 16, 2024](2024/10/16.md)
### [Seattle Xcoders 20th Anniversary Meetup](2024/10/16/seattle_xcoders_20th_anniversary_meetup.md)
This Thursday, Oct. 17, 2024, is the 20th anniversary of the Seattle Xcoders! We’d love to see you there, at 7 pm at [Bale Breaker and Yonder Cider taproom](https://www.bbycballard.com/) in Ballard.
Everyone is welcome! It’s not just for people who write code — it’s for designers, testers, support folks, and everyone who helps make Apple-ecosystem apps. Even if you just *like* those kinds of apps and like talking about them, come join us!
We’re usually outside by these propane fire things, but I’m not sure this time — we might have a room or some area or something. We should be easy to find, at any rate.
It’s not actually a meeting with presentations — it’s just hanging out and talking. Which we do every first, third, and fifth Thursday (you can [subscribe to our calendar](webcal://p25-caldav.icloud.com/published/2/Nzc2ODExNzg3NzY4MTE3OA8zb_qUej-fZsXG-_oJak3bJvjP8RcHmIEZ0WxGu2kWkvciKC5Sm6Xm5sHZRUHdZPM3KQg8-b2iwsMIEOTWlJo)). One of these days we’ll get back to presentations — but the social part is valuable, and so we keep it up.
PS Looks like the food truck is Impeckable Chicken, which I’ve heard good things about. :)
PPS I’m usually easy to spot: quite well into middle age, with nothing like the amount of hair I once had. Black jeans, usually a black sweatshirt. Glasses. Doc Martens. Not tall.