I’ve been a programmer for a long time. I consider myself pretty good at it. Perhaps you’ve even used something I’ve done in the past, maybe a keyboard or a web browser.

Well, over the last year or so, I’ve made the biggest-ever change to the way I write software. I now code with AI assistance all the time. Here’s why. Here’s how.

Why

I’m more productive with AI assistance. Today, I write fewer lines of code than ever— by hand in the old-fashioned way—yet I create more code than ever. What’s more, as far as I can tell, there is no detectable reduction in quality. I’m just faster at making changes, fixing bugs, and turning out more features.

I just completed a two-day project, and my git pull request showed: +5,643 −7,952 in 33 commits. It has never felt easier to change ~13.5k lines of code in such a short span of time. It’s not merely about lines of code, either. Nor about making the process easier in a superficial or simplistic way. It’s a more profound change. Coding with AI assistance frees up time so I can think.

I’ve always considered software to be a form of thinking: ideas, plans, and instructions distilled down into work I want the computer to do. In the past, and over the course of my career, making software has been about organizing my thinking at three different levels of abstraction.

• Sometimes musing about ideas for features the software could or should offer.
• Sometimes developing plans for realizing these features in the form of frameworks, libraries, modules, or classes that embody the feature ideas.
• Sometimes writing out the individual instructions as lines of code to make the data structures and algorithms to implement the plans for the frameworks, libraries, etc. that can deliver the feature ideas the software should offer.

Juggling these different abstraction layers is tricky. Doing it well is difficult. Switching between them has been a constant fact of my working life as a programmer.

This is what AI-assisted software assistance has changed. Now, in my daily work, I let the AI handle the instruction level of abstraction, at least the tougher part of it. I still read and review all the code I have the AI produce for me—but reading and reviewing code is so much easier than writing it.

I’ll show you what I mean. Confirm that all these animals are mammals:

    cat, mouse, horse, turtle, cow, pig, donkey, rabbit, dog, kangaroo

See the error? Of course you do. Now, think of ten kinds of birds. Not as easy as checking the mammal list, eh?

This is the difference. This explains the productivity boost. I still think of the features ideas. I still plan how I want the features to be implemented. I still read over all the code before I commit—and I still take the same responsibility over the code I merge—but I don’t write each and every if/then or function call anymore. No more typing out boilerplate code, either. I no longer have to. The AI does this grunt work for me.

My mind feels freed up. I remain at the higher levels of abstraction, with more time to think about ideas and plans. There’s less cognitive overhead in attempting things, so I attempt more things. I’m more willing to try out how my software might be better if I added a feature, changed an algorithm, or refactored a library, and when an experiment doesn’t work, I roll back with less worry about having to throw away a bunch of work I just concentrated hard to bring into being. It’s just easier to make changes. With AI assistance, I write more and better software than I ever have before.

So that’s why.

How

Mostly python

These days, I do most of my coding in python. I don’t love the language—maybe someday I’ll say why in more detail. However, since the models know python so well, it is possibly the most effective language to use for AI coding. Unlike other languages.

I use Cursor with claude-4-sonnet MAX in Agent mode.

This Cursor combination has gotten good enough that I don’t feel a pressing need to check every day or week for the latest new thing. This isn’t a cheap option, but I spend the majority of my waking hours writing code. It’s my work and my hobby. It’s what I care about doing. So, the expense is worth it to me.

I have the AI write PRDs in the form of phases and checklists.

I describe my ideas in writing with as much detail as befits a statement of goals and a plan for how I want those goals achieved. I tell the AI what I want and what I don’t. For anything even moderately complex, I have the AI write a Product Requirements Document (PRD) before I set it off to write or change code.

The AI tends to get all agile-ish and lard up the document with useless bloat about “success factors”. After all, that’s what the models see when they scour the internet. I warn it away from that. For example, I’ll prompt the AI like so:

I’m planning to consolidate and modernize the logic responsible for transforming internal representations of structured inputs into OpenAPI-compatible schema components.

The current codebase has this logic scattered across multiple modules, with redundant implementations, tight coupling, and difficult-to-maintain interdependencies. I want to unify this behavior into a single, coherent interface—ideally encapsulated in a purpose-built class that can handle schema generation, validation, formatting, and serialization of complex, nested input types.

This should include support for type constraints, operator validation, enum handling with upper bounds, default value management, and structured formatting (especially for time-based and numeric fields). The solution should produce clean, reusable schema definitions that are ready for OpenAPI integration and tool generation.

After the core functionality is in place, I’d like to migrate existing helper functions and legacy publishing logic into the new interface. Then, update all call sites throughout the system to use the unified API instead of the fragmented old logic.

Design the solution for long-term maintainability: minimal redundancy, clear boundaries, strong typing, and compatibility with automated documentation and testing.

The project is a FastAPI-based backend, using structured type models and requiring OpenAPI output compatibility. The final result should improve traceability, reduce technical debt, and centralize control over schema generation logic.

So, let’s proceed methodically. Write a PRD to organize the proposed work using the `@asana.md` file I’ve provided. Break down this work into pieces we can apply in an incremental fashion, retaining the existing code paths as we develop new ones, and giving me the option to “cut over” when a refactored code path proves its worth over what exists now. Do not lard on agile-isms or “success factors”. Just a simple, action-oriented set of phases and checklist items.

The response from the AI will look with something like this:

# Project Development Log

## Phase 1: Build Core Utility Class (Week 1)

**Status**: READY TO BEGIN

### 1.1 Setup and Planning
- [ ] Create base module file
- [ ] Define class structure with documentation
- [ ] Plan imports to avoid circular dependencies
- [ ] Determine type sharing strategy (additional module not needed)

### 1.2 Core Logic Implementation
- [ ] Implement primary method with full feature support:
  - [ ] Schema compatibility validation
  - [ ] Type constraint enforcement
  - [ ] Operator compatibility checks
  - [ ] List and nested type handling
  - [ ] Extended mappings for structured types
  - [ ] Size limits for enumerations
  - [ ] Canonical identifier serialization
  - [ ] Default value logic
  - [ ] Format annotations for structured data
  - [ ] Named schema component generation

## Phase 2: Migrate and Consolidate Legacy Functions

### 2.1 Function Migration and Refactoring
- [ ] Move legacy slot-to-schema function into new utility class
- [ ] Migrate schema builder for publishing flow
- [ ] Remove obsolete code from original location
- [ ] Ensure new implementation maintains backward-compatible behavior
- [ ] Validate functionality via existing test suite

## Phase 3: Update Downstream Consumers

### 3.1 Caller Refactor and Verification
- [ ] Replace old utility calls with new class methods
- [ ] Update internal references and imports
- [ ] Remove deprecated dependencies
- [ ] Run and verify endpoint behavior in integration tests
- [ ] All downstream systems migrated and stable

(Aside: Quite obviously, this isn’t actually Asana. Originally calling the file asana.md was a little workplace humor, coupled with a sense of giving the AI some context about what we wanted out of the plan. This workflow has proven mightily effective to tackle projects spanning a few hours to several days—the longest asana.md I saved has over 300 completed checklist items! So I keep using the name with a wink and a touch of superstition. Hat tip to Felipe for this idea.)

I provide tools/scripts it can run to perform tests or confirm results.

See the asana.md example above. Another example:

The code responsible for this work is attached. I want to add a *comprehensive* set of test cases that exercises this code, including a wide variety of types and their edge cases. Use `@test_infer.py` to help you write good tests.

I instruct the AI to proceed phase by phase

I refer to the specifics of the PRD, ands asking it to stop in between so I can review intermediate results.

OK. The Phase 1 code looks good. Proceed to Phase 2: Migrate and Consolidate Legacy Functions. Stop before going on to Phase 3 so I can review.

I liberally insert new PRD phases or skip/delete existing ones as needed.

I do this manually or I ask the AI edit the PRD. I keep the AI on track with reminders about priorities I have for the plan. Here’s an actual example from this past week, rather than the stylized one above.

OK. Here’s what I actually want for Phase 3f… simplification of service creation in services.py. We have a lot of complex code that duplicated over and over. Each service initialization follows the same basic pattern. Here’s one example:

@classmethod
def object_storage(cls) -> ‘ObjectStorage’:
    if not _services_started:
        raise RuntimeError(“ServicesAccessor not initialized. Call start_for_fastapi() or init_for_offline_use() first.”)
    
    # In developer mode (both FastAPI and offline), use lazy initialization
    if _developer_mode and not _object_storage_initialized:
        cls._ensure_service_initialized_sync(‘object_storage’)
    
    if _object_storage is None:
        raise RuntimeError(“Object storage not available after initialization attempt.”)
    return _object_storage

Now, ideally, what I want is a @classmethod on the `ObjectStorage` class itself: `get_service`, which will return a shared instance that’s started. That’s what I want for *all* services. 

There’s also this complex string-based initialization in `_ensure_service_initialized_sync`. `_ensure_embeddings_initialized` is junk. I don’t want that. I don’t want `_create_service_instance_only` either. Just call `get_service` (once it’s implemented). Reduce the complexity. Make the access and initialization patterns simpler, while preserving the three key tenets of this refactor:

1. Lazy initialization of individual services for developer mode in FastAPI/uvicorn
2. Full/eager init of all services for production in FastAPI/uvicorn
3. Lazy offline usage of individual services for standalone scripts outside of FastAPI/uvicorn

I often remind the AI of my goals as we go.

See the “… while preserving the three key tenets of this refactor…” note above and the numbered list of “key tenets” that follows. The AI’s attention can drift. I deal with it by reminding it about the key aspects of my plans.

I have the AI create and run ad-hoc new unit tests and integration tests as we go.

It’s never been easier to write tests. I have the AI do it. I don’t spend much time maintaining a library existing tests. I just throw away most of the old ones and cons up new ones as the need arises. This matches well with my belief that the best way to ensure your code works is to use it.

I review everything before I commit.

As I said above, this is essential. I still have bugs and regressions, since my ideas, plans, and powers reading and reviewing remain imperfect. I continue to test and fix as I always have. I also use the software I write, which I think is the best way to find bugs and regressions.

That’s it. Thanks for reading.

— Ken

I read Founder Mode, by Paul Graham, with great interest. I’m lucky in that I’ve seen both Steve Jobs and Brian Chesky work up close.

A few caveats. I wish that my experiences with them had lasted longer, been closer, and involved more projects. Also, I saw more of Steve than of Brian.

Even with these qualifications, I think it worthwhile to offer a distillation of ten things I did see. There are some overlaps, but this is a subtle topic, not a simple one.

Here is what Founder Mode looked like from my perspective as an observer of these two great founders.

• Steve and Brian were deeply intuitive. In any particular situation, they knew what they wanted. They could also change their minds as the situation changed. They were decisive, but open.

• Steve and Brian worked very hard all the time. I’m not sure either of them ever really turned off. Look elsewhere for notions of work/life balance. Their work is their life, which they pursued with boundless energy.

• Steve and Brian never cared what you thought if it conflicted with what they thought was the right thing to do. They were on a personal quest to ask the most pertinent questions about their company and then find the best possible answers. Not a thing they could delegate.

• Steve and Brian were great editors of other people’s work. They gave out the ideas, jobs, projects, the things to do, and then they commented on, guided, and shaped the results that came back with clear and cogent feedback about what should happen next.

• Steve and Brian did not micro-manage. They right-sized their involvement. They trusted their best people to do great work without smothering them, but then were always there to give feedback and support.

• Steve and Brian demanded progress. Nobody had a comfortable job working with them. They expected people to produce tangible work product on a regular basis. They demanded tight iteration cycles.

• Steve and Brian were always visible. Sometimes it seemed like they were everywhere working on everything.

• Steve and Brian were focused. They banished distractions. Their concentration didn’t waver. They were able to work on a specific task for as long as necessary.

• Steve and Brian exuded extreme confidence. They possessed an intense personal charisma. It made the people around them strive to do their best.

• Steve and Brian never got confused about what their companies were supposed to be doing. They always kept their eyes on creating meaning and value for customers.

A note on verb tenses. I expressed my list in the past tense, as a description of first hand observations I made in the past. It seemed odd to talk about Brian in this way, but there it is. I hope Brian continues his work far into the future.

Do you trust a tweet? Well, here’s what’s in one:

• a display name, the “human readable” name. Historically, this has been freeform text. I’ve always used my true name, Ken Kocienda. Others are more creative and change their display name often.
• an avatar, an image. Again, a freeform field. Use a portrait, a logo, whatever. Another chance to express yourself.
• an account name, the @handle. This doesn’t change. It’s unique in the Twitter namespace. Set it once at account-creation time, and that’s it. Even so, it’s also freeform. In general, you can claim whatever name you want—as long as nobody else has it already.
• the account bio, a click away in all clients I know about. Another freeform field.
• Finally… the text of the tweet, in 280 characters or less.

A tweet also might have a blue checkmark. The presence of this verification badge, or lack of it, is one more piece of information to consider when reading a tweet and deciding whether to trust it.

So once more, using this information, do you trust a tweet? For some accounts I follow, like @Popehat, the avatar has been as much a sign that the account was the real thing, especially since Ken White (the man usually behind the tweets) often has been in the habit of humorously changing his display name to “ReflectTheLatestLegalSillinessHat”. The cleverness of the display name du jour was also a sign the tweet was genuine.

Although the now-retired verification process Twitter used was never made completely clear or transparent, the system sorta worked. For myself, I always looked to the blue checkmark as a signal that the account was who or what it purported to be—and therefore the tweets were too. Tweets with blue checkmarks carried more trust along with them.

To some extent, this also means that I trusted Twitter to perform the verification. I never applied for verification under the old system myself, but I did read the page to see what was required to submit a verification request. As I recall, an organization needed to prove it was indeed that organization (perhaps with legal documents?). Presumably, a government official would need to do much the same. A journalist would need to provide press credentials of some sort. An otherwise “notable” individual would need to make a case for actual notability by pointing to wikipedia pages, google links to articles in reputable publications, etc. It’s very likely that I don’t have all the details right, but it doesn’t much matter. The point is that Twitter gathered and vetted information to verify that accounts were owned by someone or some organization who was, in fact, who they said they were. This is a key. It was the account that was verified, not the display name, or the avatar, or the bio, or the text of the tweets. The account can’t be changed. Up until now, with the previous verification scheme, all the other fields could be altered by the account holder on a whim.

This seems like a shaky foundation for verification, but I can’t remember a case in the past where a checkmark was given incorrectly (in that the account was a fake), and while I heard of many instances where someone applied for verification but was denied (for reasons that nobody outside Twitter could fully understand), the blue checkmarks kinda functioned as intended, even with Popehat-style shifting display names, changeable avatars and bios, and the rest. I guess we came to trust Twitter to get it right enough when doling out the blue checkmarks.

Does the recent ownership change affect the trust question? Maybe it does. For sure, paying $8 for a blue checkmark without any verification process was never (ever!) a good idea. Just ask Eli Lilly.

On November 25, there came news that there will be three different colors of verification badges, with blue check marks for people, gold for companies, and gray for governments. I don’t know what this accomplishes. Take the example of the 45th President of the United States. He was, and remains, a notable person. He’s also the head of a company (and technically, probably several). He also was a government official. Does that mean that any future famous business-owning government official will have a row of badges? This seems like a recipe for confusion—or perhaps clutter—rather than clarity. If the display name is locked together with the account account name as part of the verification process, this could help to build trust that a tweet is being made from a knowable source. Will avatars and bios be locked too?

And what does paying have to do with it? I get that Twitter needs to make money to keep the servers humming and pay the employees who remain, but does a one-time check of claims and credentials warrant paying $8 per month in perpetuity? Will paying boost tweets in the algorithms? Is this system really more of a subscription with verification as a perk? Will this help people trust tweets?

I guess we’ll see.

After I finished my morning coffee with my wife, I looked at Twitter. I found a link to this essay by Craig Mod: Walking Venice.

Venice is cursed. It’s also beautiful and astounding and I walked up and down its alleyways.

https://craigmod.com/ridgeline/144/

I made a mental note to look it later in the day.

Now the admission. My cerebral reading list is a leaky bucket. So many articles and posts get poured it. So few get ladled back out. Most drip out the bottom and evaporate in a wisp.

Untroubled by this sad fact since it’s a daily occurrence, I scrolled on through my timeline. I soon saw the darkly glowing reply from Sebastiaan de With.

@craigmod What an agonizingly beautiful read. I really, really loved this. Thanks, Craig.

I stopped what I was doing right there and read Craig’s essay. It’s wonderful. I won’t spoil any of it. I suggest you go read it right now just like I (eventually) did.

Then come back and enjoy this partial footnote from Consider The Lobster, the essay by David Foster Wallace*. In his piece about visiting the Maine Lobster Festival in 2003, Wallace wrote about what it was like to be a tourist in America near the turn of the 21st century. His comments are about traveling inside the USA, but they are a suitably apt addendum to Craig’s contemporary experiences in Venice, which, it seems, doggedly lives on in the imagination of so many as La Serenìsima Repùblica Vèneta.

As I see it, it probably really is good for the soul to be a tourist, even if it’s only once in a while. Not good for the soul in a refreshing or enlivening way, though, but rather in a grim, steely-eyed, let’s-look-honestly-at-the-facts-and-find-some-way-to-deal-with-them way. My personal experience has not been that traveling around the country is broadening or relaxing, or that radical changes in place and context have a salutary effect, but rather that intranational tourism is radically constricting, and humbling in the hardest way — hostile to my fantasy of being a true individual, of living somehow outside and above it all… To be a mass tourist, for me, is to become a pure late-date American: alien, ignorant, greedy for something you cannot ever have, disappointed in a way you can never admit. It is to spoil, by way of sheer ontology, the very unspoiledness you are there to experience. It is to impose yourself on places that in all non-economic ways would be better, realer, without you. It is, in lines and gridlock and transaction after transaction, to confront a dimension of yourself that is as inescapable as it is painful: As a tourist, you become economically significant but existentially loathsome, an insect on a dead thing.

Excerpt From
Consider the Lobster
David Foster Wallace
https://books.apple.com/us/book/consider-the-lobster/id357663852
This material may be protected by copyright.

* I enjoy DFW’s nonfiction so very much, and of course, I need to tell you about it in a footnote. At moments like this, I can’t specifically describe why I enjoy Wallace’s essays because it’s everything. So smart. So geekily baroque. So many unrestrained and overelaborated footnotes. Writing so good that it inspires me to write, and yet is despairing too since there’s no way I can hope to approach his level. But I digress.

Some of you may know that I’ve taken an interest in mechanical watches, and I have been putting together a collection of pieces I like to wear. I also like to think about them as products, design objects, and examples of human ingenuity.

It’s easy to find watches for any budget, including budgets far exceeding mine. For example, this morning, I was browsing a couple of my favorite watch dealer sites, and I saw a new posting offering a Rolex Sea Dweller, a watch that typically sells for well over $10,000 USD, but… this particular example had a “COMEX” signature on the dial, referring to the relationship between Rolex and the Compagnie Maritime d’Expertises (COMEX), a French deep sea diving and technology company well known for pushing diving to new depths. Since comparatively few of these pieces were made, they are rare, and given the association with an illustrious company like COMEX, they are special too. Therefore, this particular example was being offered, with the original box and associated papers, for $140,000 USD.

Wow!

This $140k asking price raises the question of what objects like watches or Rolexes or specially signed COMEX Rolexes are rightly worth, and can also cover similar questions we might ask about Impressionist paintings, vintage Superman comic books, a Mickey Mantle baseball card picturing him in his rookie year, or all the new attention being paid to NFTs. What are these things really worth?

As I thought about this question, I was reminded of a time when my wife and I were watching an episode of Antiques Roadshow. It’s been quite a few years, and I may not have all my details right, but I’m sure about the main parts of the story.

An appraiser began to introduce an early American document, a Letter of Marque and Reprisal signed by President James Madison in the 19th century. In the age of sailing ships, such letters were official proclamations naming specific individuals as operating under the auspices of the US government. In other words, they were privateers, not pirates. Letters of Marque and Reprisal are mentioned in the US Constitution (and shows how just how old the US Constitution is: it has specific provisions for dealing with pirates on the high seas). My wife and I thought this was an incredibly cool object, signed by one of the Founding Fathers of the United States. Yet, the appraiser gave a disappointing auction estimate: $1500.

The show went bling and went on the to next item, which was, to our eyes, an incredibly ugly early 20th century vase by someone neither of us had ever heard of. But… oh… the appraiser was quick to add that this artist has suddenly become collectible, especially works depicting chickens. Yes, his indeed, the chicken pieces have become highly sought after, and lucky for you, the appraiser added, “Since the vase you’ve brought in today features chickens so prominently, I feel confident giving an auction estimate of $4500.”

My wife and I laughed, and ever since then, she and I share an inside joke. Whenever we see an item that isn’t as good or special as it might be, especially pieces of art we don’t like, we say, “Well, if only it had a chicken on it…”.

There’s a point to the chicken vase story I try to remember as I think about watches and collecting them. No object has intrinsic value. We make the valuable things valuable, and whether it be a COMEX watch, a Letter of Marque and Reprisal, or a chicken vase, the monetary value of a thing is usually just a simple case of supply and demand, and often reduces to little more than a silly and fickle popularity contest.

In my watch collecting, I aim to avoid getting caught up in that. My watches may never be the ones that will suddenly become highly sought after but I don’t care. I tell myself: Just collect and wear what you like. I even bought a watch this morning. I can’t wait for it to arrive.

There’s something charmingly unmodern about correspondence describing a lunch with a new acquaintance. It’s a throwback to the age before mass media, when life moved at a slower pace—or at least it seemed to from today’s perspective—and when penning and posting letters was the way the cognoscenti kept in touch with each other.

I woke up this morning to read that Om Malik had written about our recent lunch in this style. I just had to respond.

I know about Om through his writing, his photography, his investing, and his watch collecting. I share many of these interests. I always figured that Om and I know many of the same people too, and for many years I’ve said to myself that it would be great to meet him. That never seemed like a real possibility, since everyone is always so busy, breaking the ice with new people isn’t my best skill, and there just didn’t seem like there was a simple way to connect the dots.

Then a couple of weeks ago, Om and I exchanged a couple Twitter DMs—this was around the time I made the twentieth anniversary announcement of the start of the WebKit project—and before I knew it, we had set a time to meet for lunch in San Francisco.

I always worry when I meet someone like Om, a person I admire and is so accomplished. Will the chemistry be good? Will we find it easy to talk to each other? Will I get nervous and fail to make sense about anything?

I needn’t have worried. We found it simple to chat, and as Om commented, we meandered through several of our favorite topics.

We talked about his photography, his use of Leica cameras, his love of the cold and the snow, and how being out in the wilderness is an opportunity to focus on an inner dialog with our thoughts and experiences.

We talked about watches, how Grand Seiko makes up a large part of his current collection, the piece on his wrist with its stunning blue dial, and how one Grand Seiko that Om bought in the 1990s became the grail watch for an avid Japanese collector.

We talked about technology, our thoughts about what computing in the future might be like, how helpful it might someday become, and comparing it to the gadgets we brought with us to lunch.

I had a great time meeting up with Om. I’m so glad the pandemic has eased to the point where it’s possible to get together with wonderful people and share a casual meal. I missed that over the past eighteen months. I look forward to the next time Om and I can get together.

A postscript. In my conversation with Om, I mentioned a photographer. It was Richard Benson. Everyone called him “Chip”. A wonderful artist. He taught me a lot. I wasn’t in contact with him much after I left Yale, but I remember him very fondly. www.nytimes.com/2017/06/2…

I woke up and looked at the clock. 3:15 AM. I had a clear picture in my mind to make something new. It took me the next six months to make that drowsy vision real.

The result was Up Spell, a word game for iOS. But that’s the end of the story.

On that morning, it was April 2020. We were still in the first few weeks of the pandemic. When I had closed my eyes to go to sleep hours earlier, I already knew that my new job at Airbnb had gone off track. I had recently accepted an open-ended role with the company, an opportunity to look around and find interesting work to do with interesting people. Instead, as Airbnb was circling its wagons to figure out how home stays and travel could possibly go on amid global lockdowns, I felt like an odd man out. I left the company just ten weeks after joining.

I didn’t know what to do. That’s why my early morning idea was so appealing, because in that moment, I was sure I had a plan. Creating a word game was appealing notion, since I like word games, and I was reasonably sure I could make one that would be fun to play. But that wasn’t the actual idea. To explain what my real goal was, I need to step back in time.

Back in June 2001, I joined Apple to work on what became Safari and WebKit. Mac OS X was new. It had been released just three months earlier. With it, the commitment Apple had made years earlier to bring NeXT technology to the Mac had finally come to fruition. During my second week at Apple, I attended an internal training program to learn about the Cocoa frameworks and Objective-C, the foundation technologies for Apple’s new operating system. They were the main developer tools for programmers inside the company and those making their own apps to run on the platform.

Over the next fifteen years, I wrote code in ObjC just about every day. The language offered me a small collection of rules on the surface and a deep well of flexibility underneath. This combination facilitated and encouraged quick and playful experimentation. The language allowed me to wink and say, “I know what I’m doing.” ObjC winked back and became a willing participant in helping me make computers do cool stuff.

I made URL loading APIs for the Foundation framework, I wrote the keyboard for the original iPhone in ObjC (with some C++ mixed in for performance-critical work), and I coded the Solar face for the first Apple Watch. So much more too. All in ObjC. It remains one of the best languages ever for creating apps and frameworks. I’ve loved every minute I’ve spent coding in it.

On that morning in April 2020, it was clear to me that ObjC was no longer the future for Apple technology. It made me sad then, as it does now, but I’ve come to terms with it. However, it still seemed possible to do one more project in ObjC before its technological sun set over the horizon. In 2020, ObjC still had full access to everything iOS could do. I could make an app with no compromises in the old style.

Over the next six months, I spent so many enjoyable days programming. While the pandemic was raging in the US and around the world, I wrapped myself in a safety blanket of square brackets. ObjC helped to keep me sane and safe. I shipped Up Spell in October 2020, and while it didn’t sell as many copies as I had hoped it might, that’s OK.

The real idea I had on that morning months earlier wasn’t about making a word game. It was about stopping time, capturing a moment, making the fast-moving world of technology come to rest for a moment, so I could savor one small piece of it one last time before it disappears.