Annalise Kerr
Why I write
I make things for clients, which means the brief changes on Thursday and the deadline does not. A lot of my working life is the gap between what would be good and what will be approved, and I lose that argument regularly.
I keep showing up for it because I do not believe the small decisions are small. Nobody can tell you why one thing feels considered and another feels assembled, but everybody feels it, and that difference is made of a hundred choices someone either made or could not be bothered to make. Caring about them is not precious. It is the whole job, and I would rather be the person who is difficult about it than the person who stopped noticing.
Writing is where I get to finish an argument. No revision round, no committee, no version where the good part comes out because it made somebody nervous. I did not expect it to matter to me this much. It turns out I love it for the same reason I love the work: it is a thing you can keep making better until it is actually right, and nobody can approve it away from you.
So that is most of what I write here. Design and video tools, why a few of them feel right and most do not, and where AI takes the tedious part versus where it quietly takes the judgment you were being paid for.
What I do the rest of the week
I work with software all day and notice how it feels, which sounds like a soft skill until you watch what bad software does to a team's morale over a quarter. My work is the ordinary kind: briefs, drafts, revisions, and the dozen small applications it takes to move any of that from one place to another.
That ordinariness is the qualification. I am not testing tools in a lab. I am using them under deadline, with a half-finished thought in my head, and finding out which ones make that harder.
Why I am worth reading on this
Because the things that make daily software exhausting are rarely the things reviews cover. Nobody writes about the dialog that asks the same question twice, the setting that resets, the flow that assumes you have already decided something you have not. Individually each is trivial. Together they are why people quietly stop using a tool and never say why.
I write from having lived with the software rather than having assessed it, and I try to name the specific moment something went wrong rather than concluding that an experience was bad.
What I get wrong
I mistake my own preferences for principles more often than I would like. Something that irritates me is not automatically a design flaw, and I do not always catch the difference on the first pass.
What I will not write about
Anything I have only read about. If I have not lived with a tool for long enough to be annoyed by it, I have nothing to add that you could not get faster elsewhere, and saying so costs me less than pretending otherwise costs you.
I also stay away from predictions. What software will be like in three years is a genre, and it is not one where being wrong has any consequence for the person writing. I would rather describe something that is true now and can be checked now.
Back to the blog