Esoteric Cowboy

Snowy Egret

Mon, 18 May 2026 00:00:00 GMT

A snowy Egret captured using a Fuji X-E5 and Fuji XF 70-300mm lens

The Snowy Egret (Egretta thula) is a small species of heron.

Snowy Egret plumage was so prized for women’s hats that, at one point, 130,000 birds were killed in a single nine-month season. Harriet Lawrence Hemenway leveraged a sense of noblesse oblige, and her Brahmin connections in the Boston Social Register, to organize a boycott. This boycott led to the founding of the Massachusetts Audubon Society in 1896, the seed of the National Audubon Society, and helped drive the Migratory Bird Treaty Act of 1918.

Photo notes

My first bird photograph with the new Fuji XF 70-300mm lens. Not as sharp as I’d hoped – it’s heavily cropped. I’d mounted the camera on a cheap Sirui tripod hoping to catch a spoonbill on the water, and I got appropriately distracted.

croppie holidays

Wed, 24 Dec 2025 00:00:00 GMT

it’s no secret that i get antsy when i don’t have an active project. this year, with a new career under my belt and finally calling my own shots, i decided it was time to do a little open source software with my holiday time.

for Beep, i’ve been using Croppie with stimulus to adjust and edit images. auto insurance and crms both involve some degree of image editing and storage - not necessarily cascading walls of images, but performance being my north star, i thought… well, hey, Croppie hasn’t had a release in over five years and i bet i can do better than ~50KB.

i ultimately created a fork which is more of a completely new project with a fork relationship. the project was rewritten in typescript, made esm-only, and supports the modern pointer events api. it’s ~5KB gzipped (a 90% reduction) and we’re already dogfooding it in production.

https://github.com/bayinformatics/croppie

we’re using bun for built-in testing, lost pixel for visual regression, and have no external dependencies. we also support dark mode. sad bois unite.

it’s a small project, and i was able to crank it out pretty fast. in about 72 hours i had a drop-in replacement. the entire thing was written by me in neovim with the claude code plugin, mostly for confirming functional parity and reviewing my code.

this was one of the most excellent ai coding experiences i’ve had. “does my implementation match the original behavior here?” was an instant sanity check that compressed the time while still leaving me feeling in control.

i’ve been evaluating ai coding tools for about a year now and am genuinely shocked at how useful they are. there’s no way development at Beep would be moving as fast as it does without ai coding assistance. that’s not to say we just type a prompt into claude code, hit enter, and walk away - as far as i can tell, one-shotting sufficiently complex software is not in the cards any time soon.

most value for me has been in asking for a socratic tutor to help hone my architecture or patterns. here’s an example prompt i used when rewriting Croppie:

“in my test mocks, i want to use happy-dom to have a lightweight test bed. some functionality appears missing like canvas mocking. i’d like you to look at my implementation of the mock canvas and ask me about my choices and architecture”

with small scope, a clear goal, and one decision-maker: me. this worked beautifully.

so why am i skeptical about ai for oss teams at large?

oss discourse tends to oscillate between “all the code will be written with ai” and “ai is plagiarism.” i don’t subscribe to that black-and-white thinking, but i do see issues that are more practical than philosophical.

notification fatigue is real. coderabbit, i’m looking at you. no, i made that decision intentionally - go away. github code quality, you too. every pr becomes a wall of robot opinions nobody asked for. the irony of ai tooling meant to save time creating more noise to wade through is not lost on me.

there’s no shared context. my chats are private. the ai doesn’t know why we made the decisions we made, and neither does the next engineer reading the code. although i try to document things via changelog, ai adds even more of a “meh, ship it” button to the average engineer. suddenly documentation requirements or some sort of wiki become necessary just to preserve the reasoning that used to live in slower, more deliberate code review. i like what ampcode is doing with shared team context and logs; that feels like the right direction.

signal-to-noise inverts with scale. when i’m the only reviewer, ai augments my judgment. when there’s a team, it creates noise for everyone. the same generic suggestions surface things humans already know but chose to accept. it doesn’t know when to shut up.

the pattern i keep landing on: ai as personal assistant scales. ai as team process doesn’t.

if you’re working on a small oss project over the holidays, ai tooling is genuinely great for that. just don’t inflict it on your teammates’ inboxes.

how are you using ai in your open source work? i’m curious whether others have found ways to make it work at scale, or if we’re all just turning off the bots.

Choosing to Wield the Hammer

Fri, 17 Oct 2025 00:00:00 GMT

When you have a hammer, every problem looks like a nail. As aphorisms go, I hear this one constantly. I have never heard it used in a positive context. Misusing tools evokes images of beating a screw into your deck with a hammer or sawing a bolt out of your motorcycle subframe. Inefficient, embarrassing, and dangerous. The three killers of careers and consultants. Over the last decade in software, I think we’ve elevated the wrong advice. We’ve been taught that reaching for the same hammer makes us lazy. But sometimes the right move is choosing your hammer deliberately and wielding it with mastery.

No Agent is an Island

At this point ‘premature optimization’ has reached low-effort meme status. Don’t create 20 Go microservices for your new startup, don’t manage your own Kubernetes cluster, don’t Terraform yourself into a corner. We all nod along. But here’s what we’ve missed: the new enemy isn’t premature optimization, it’s context loss. And there’s no faster way to lose context than distributing your systems. When you’re one person (or a small team), every additional service is another mental model to hold, another deployment to remember, another place where things can break silently. This holds even more true in the realm of agentic AI. When Claude or Cursor is helping you code, it needs context, and lots of it! A monolith means you can feed it one codebase, one set of patterns. Microservices? Now you’re explaining service boundaries, API contracts, and inter-service communication before you even get to the actual problem you’re solving.

Early in my career, I consulted for a small shop in Wisconsin, which gave me access to the inner workings of tech companies across healthcare, fitness, and print industries. But my greatest lesson came from a single engineer who rented a private office from us.

He built and ran waiting system software for major hospital systems—entirely solo, entirely in Grails. Occasionally he’d pay for a few of my hours when he needed help. I didn’t even know Groovy, but because everything lived in one coherent codebase, I could hold the entire system in my head. In just a few days, I implemented timed texts, sign-in links, and several other substantial features.

He was, by far, the most profitable solo developer I’ve ever encountered. One person, one framework, one mental model.

This was 2014. Today, a developer in his position would be tempted by serverless, vercel, and fixing whatever breaking change has been introduced in Next.js or React. Back then, the siren songs were different but equally distracting. He ignored all of it. He’d chosen his hammer and mastered it.

That engineer taught me something the industry blogs never mention: boring technology is a competitive advantage when you’re small.

For any new web project, I reach for Rails. Convention over configuration. Monolithic architecture. Ship fast, iterate faster. The framework gets out of my way and lets me focus on solving actual business problems instead of wiring together infrastructure.

Boring is powerful when you’re starting from zero. Running Rails’ built-in generators `rails generate scaffold, rails generate model` is faster than asking Claude to write equivalent code. You get a working CRUD app with database migrations, views, and routes in seconds. No prompt engineering required. You get the entire force of a community behind you and 20 years of AI training data. When you ask Claude or Cursor for help with Rails, it’s drawing from millions of Rails codebases, Stack Overflow threads, and blog posts spanning two decades. Compare that to the JavaScript ecosystem, where the ‘right way’ to handle routing changes every few years and half the training data points to deprecated patterns. You get 80% of the way with 20% of the effort. This leaves you with time and energy for what actually matters: understanding the business problem, modeling the domain correctly, and shipping features that solve real needs.

Handing Over the Keys to the Honda

The thing about consulting work that product engineers often miss: you’re not just building for yourself. You’re building for the team that takes over after you leave.

When I meet a new client or start a new project, I’m thinking about the handoff from day one. Can they hire Rails developers in their market? Will the next engineer understand the codebase in six months? Can a non-technical founder grasp what the system does without getting lost in microservices diagrams?

This is where boring technology becomes a business advantage. A Rails monolith with straightforward documentation is something a client can actually maintain. They can hire locally. They can onboard new developers quickly. They can understand the system well enough to make informed decisions about future development. If they’re feeling daring, they could even attempt to vibe code it.

Compare that to the handoff conversation when you’ve built a distributed system: “So you’ll need to maintain these seven microservices, understand their API contracts, monitor the message queue, manage the service mesh, reconfigure the hoozymcflozzy…” You’ve just guaranteed they’ll be calling you back at premium emergency rates. Not exactly a strong selling point.

As a one-person technical team, you can’t hide behind complexity. Your value is speed (shipping features fast) and clarity (making sure everyone understands what you built and why).

Speed comes from keeping your entire system in your head (and in your AI’s context window). When everything lives in one Rails app, I can trace a request from browser to database and back in seconds. More importantly, when I’m pair programming with Claude or Cursor, I can feed it the entire relevant codebase. One repo. One set of patterns. One mental model.

Every additional service fragments your attention and fragments your AI assistant’s understanding. Want to add user authentication? In a monolith, Claude sees the User model, the sessions controller, and the authentication logic all in one place. In a microservices setup, worst case you’re working across packages and system boundaries, best case, you’re working in a monorepo with so many files you’ll blow straight out of the context window.

You Get Some Clarity, and You Get Some Clarity, Everyone Gets Clarity

Clarity works both ways. A monolith is clear for me: one codebase, one mental model, one place where everything happens. It’s clear for stakeholders who need to understand what they’re paying for. And crucially, it’s clear for AI coding assistants that amplify my productivity.

When a client asks “where does the user registration flow happen?”, I can point to one file. When I ask Claude to add email verification, it can see the mailer setup, the User model validations, and the registration controller in a single session. No explaining service boundaries. No managing API contracts across repos. Just: “Here’s the codebase, here’s what I changed. Review plz, luv u.”

Every architectural decision is really a decision about where to spend your attention. Microservices distribute your computing across services. But more importantly, they distribute your mind across codebases, deployment pipelines, API contracts, and debugging sessions. When you’re one person, your attention is your scarcest resource. A monolith isn’t a compromise—it’s a deliberate choice to keep your cognitive load manageable and your AI assistance effective.

Choosing Your Hammer

DHH has made the architectural case for monoliths. I’m making the cognitive and pragmatic case. When you deliberately choose your hammer and master it, you’re not being lazy—you’re being strategic about the one resource you can’t scale: your attention (and trust me, I, along with the entire biohacking subreddit have tried).

Look, there’s a time for novelty. If you’re in the fundraising game, the right buzzwords can open doors. But once those doors close and you actually need to build something that works, makes money, and doesn’t page you when you’re skiing? Mastery wins. Every single time.

I’m not arguing monoliths work for everyone. Far from it. If you’re coordinating hundreds of engineers across dozens of teams, you need to work with your organization to map out your architecture. When your organization is so large that independent deployment cycles and team autonomy become more valuable than system coherence, split things up.

But here’s the thing: you’ll know when you hit that point. You won’t need an article to tell you. Your deploys will be taking hours. Your merge conflicts will be constant. Your team leads will get shifty and start weird skunkworks initiatives to break things up.

Most companies never reach that scale. And the ones that do often started with a monolith. GitHub ran on Rails for years before introducing microservices. Shopify still runs one of the largest Rails monoliths in existence. Basecamp (DHH’s company) serves millions of users on a monolith.

The real advantage isn’t that boring technology can’t scale, it’s that boring technology lets you scale with a smaller team. You don’t need a platform engineering group, a DevOps department, and a site reliability team when you’re running one well-architected Rails app.

So the next time someone warns you that when you have a hammer, every problem looks like a nail, you can smile and say: ‘Exactly. And I’ve gotten really good at driving nails.’

cybernetically enhancing my brain with vendor lock-in

Thu, 06 Mar 2025 00:00:00 GMT

just how quickly can you build and deploy a site in 2025? if you ask Guillermo Rauch he’ll probably say instantly, or something, before muttering to himself about state-sponsored propaganda and the free market. sure, i could flash nixos on to the spare machine sitting on top of my guitar amplifier. battery swelling, insurance adjusters frothing at their thin-lipped mouths, but what if i just paid someone else to do that for me? and what if i gave two billionaires money in the process?

in the age of Claude 3.7, gps ads, algorithmic feeds, and robot-on-robot violence why would i do anything myself, including setting up my own aws environment? what am i, a caveman?

so, instead of doing the logical thing i’ve been doing most of my life and making a Ruby on Rails app, i decided to see how many npm libraries i could weave together into a digital trammel. perhaps, i’ll even catch something good, and not just some endangered turtles.

over the course of approximately 3 hours and 27 commits, i threw together

https://mwksl.coffee

one of the most simple crud apps one could design. it has auth, a postgres database, edge functions… for some reason, and uses shadcn and tailwind for styling.

those three hours were 2 hours and 10 minutes of reading docs, resolving npm conflicts, and consulting the oracle stack overflow with 50 minutes of hamfisting garbage typescript into webstorm via my keyboard. indeed, who doesn’t enjoy reading year old release notes to find slight changes in type names. now, granted, its my own fault for trying to use an orm, and quickly reading through some older implementations. i, like most modern developers, don’t believe in personal responsibility, so, i’m choosing to blame the geist of modern computing. the greater foundational spirit of the lightning boxes that dominate our lives.

the irony isn’t lost on me: i’m tracking the substance that wrangles the post-modern, meme-riddled, goop floating in my skull, using tools that deteriorate my cognitive abilities. with every sip of caffeine i ingest, i wedge myself further into the wallet of vercel. i’ve become codependent. i need caffeine to understand modern web dev, and i need modern web dev to track my caffeine.

i’ve completed my transformation. completely locked in to next.js, vercel, neon — but not only this, i’ve locked my biochemistry in too. who needs neural implants when you can run a cli tool to deploy your EDGE COMPUTE FUNCTIONS™️. this is cybernetic enhancement for the terminally online: we’ve ditched the chrome hardware for subscription-based digital services that save us potential minutes of work.

the full recipe for this digital monstrosity? start with a fresh next.js 15 app. add a sprinkle of drizzle orm (appropriately named, as it’s just enough database to make everything damp enough to mold). toss in nextauth so you can scapegoat the library for your misunderstanding of pbkdf2. layer on shadcn components since something good had to be developed from the primordial ooze of tailwind. and finally, drown the whole thing in classes until your jsx looks like the xanga page from your xRawrxMonsterx era.

after battling npm dependency hell – where “react-dom”: “^19.0.0” somehow conflicts with a package that requires “react-dom”: “^19.0.0” – i finally deployed to vercel. why? because i’ve developed stockholm syndrome for platforms that promise to handle infrastructure for me. i am done. i am happy. :)

as i sip my fourth espresso, washing it down with a sugar-free red bull and watching the caffeine counter tick upward on my shoddily deployed app, i realize i’ve created the perfect metaphor for modern development: an over-engineered solution to a simple problem, temporarily satisfying but ultimately creating more dependencies than it resolves. the difference between caffeine and cloud services? at least caffeine is honest about its half-life.

generating the future

Tue, 17 Dec 2024 00:00:00 GMT

house keeping

freq boutique was electric – thank you to everyone who made it out. video available here (gentle warning: some mic feedback haunts the opening moments)
moodmix has entered the digital afterlife. custom AI models vs LLMs: a $100 monthly offering i can no longer justify.

midi divination

norns programming pulled me away from the physical realm of modular and guitar. the end of tape experiments led me, unexpectedly, into pure digital territory. my current implements: generative music systems and max for live.

there’s something mystical in crafting sounds and surrendering them to midi chaos. here’s a 2-minute window into these evolving experiments (the full sequence runs much longer, but file size constraints are very real). a first for me: sequenced drums making an appearance.

recommendations

Family Romance, LLC by Werner Herzog – a gentle unraveling of reality via rent-a-family services in Japan. minor Herzog perhaps, but the existential questions linger. Ernst Reijseger’s delicate score threads through the film perfectly.
supporting your local independent theater.

iron oxide

Sat, 07 Dec 2024 00:00:00 GMT

house keeping

enjoy the music of my dear friend Drift Diffusion, he is generous enough to let me share the stage with him next tuesday.

manor revisited

the norns has rekindled my love of lua. long dormant, somewhere from 2006, likely still writing gui scripts.

i look forward to sharing scripts with the community soon. in the meantime, i’ve continued pulling on the tape and unwinding the cassette.

for now, this is the finale of my tape experimentation. my next chapter involves integrating the norns into a new modular system and venturing into live visuals.

recommendations

Community by Jonathan Franzen - a sprawling exploration of idealism and community in 1970s Chicago
Mahashmashana by Father John Misty - an introspective 70’s psych rock inspired album mixed with a hefty dose of LA mysticism a la Bruce Wagner

haunted by tape

Wed, 13 Nov 2024 00:00:00 GMT

house keeping

i’m playing an ambient show on December 10 at Fort Greene in Denver. you should come.
a note on The Blood Brothers reunion tour: it’s transcendent, mystical – witness it if you can.

paranormal echoes

the Tascam 424 MkII found me through a stranger in Redlands, Ca. i’ve been haunted by the tape sound for the last 15 years. hiss and warble from my childhood. itself artifacts of my own memory. they’re memories of memories, degrading and transforming like magnetic tape worn thin with time.

i’ve recorded a short demo track onto tape for your ears. yes, this arrives shortly after my essay on joy in music – perhaps there’s a certain pleasure in haunting, too.

technical apparatus

committed first to tape, then into ableton. hiss and warble are authentic artifacts of the physical medium. digital intervention remains sparse: just the essentials of mastering (3-band eq, glue compressor, limiter). a failed RCA cable forced an unintended path: mono output split and widened into stereo space. sometimes technical limitations reveal themselves as gifts.

recommendations

Under the Volcano by Malcolm Lowry. a feverish descent through mezcal vapors — the consul dissolves into his final day like a memory eating itself.
The Bloody Lady by Claire Rousay. a reimagined score for Viktor Kubal’s 1980 eponymous animated film.