Thank you, but I prefer it my way

The LLMs have changed how software gets made, and will keep changing it - for code, for design, for any digital product. Buried under all the productivity talk there is one thing they enable which does not get discussed much: never having to collaborate with another human being, ever again. The library whose maintainer won’t answer, the framework whose author finds your use case silly, the colleague who wants it done just so - you can now route around all of them. You can rewrite the thing in an afternoon, and nobody gets to tell you “no”.

We may soon come to regret this new freedom. Not because the rewrites are bad (they are often fine), but because the thing that forced us to work together is gone - and both sides of the open source bargain have spent years making sure we wouldn’t miss it.

🧭 I am currently available for contract work. Hire me to help make your Rails app better!

Baptiste Senior, in case you have not seen the film, is a petty dictator. That is the role we, software authors, are now auditioning for. Every one of us has a list: the maintainer who closed our PR with a smiley, the architecture guild that needed six weeks to approve a column rename, the designer who wanted the dialog just so, the author of that one library whose square was never a square. For twenty years we had to swallow it, because we needed those people to move the mountain. Now we don’t, and the first thing we are doing with our new power is not building something better - it is getting even. Routing around every one of those horrible other people, one afternoon at a time, and calling it productivity.

Let me introduce a term I will be using a lot: a square is a square. It is something that - if we are letting go of our biases - is evidently, indisputably correct. A programming language should parse 10.05 the same way on every machine. A source map should be served in a way the browser can find it. Squares. Not every disagreement is one - plenty of my squares are rectangles to somebody else, and I will try to flag those - but the clear cases exist, and the entire social cost of shared software is the cost of convincing somebody of them. The LLMs have just made paying that cost optional.

In my recent article I mentioned stationery and sghtmltopdf, two fresh PDF libraries. In the Hacker News thread a commenter pointed out that HexaPDF is also great, and added:

Personally I already find hexapdf to be better than prawn. And you can also try to convince the hexapdf author to improve hexapdf; he was willing to do so when he has time and the suggestion made sense.

This is good advice, and Thomas Leitner is, by every account, a cooperative maintainer. And still, almost nobody is going to email him - because the prompt is right there, and the email requires making a case. Even when the maintainer is willing, we won’t bother anymore. Hold on to that, we will come back to it.

Up until very recently software got created in groups. You would not go and write the backend, the web frontend, two native mobile apps and a graphics core all by yourself - and you would not sit through the user interviews and move the rectangles in Figma on top of that. Even in the purely “computering” domain you needed others: a UNIX guy/gal to set up your server and get mail working, a frontend wizard so that your site does not crash Internet Explorer on Windows 2000, that fellow who figured out how to parse a near-complete SQL dialect, because understanding his problem yourself would have taken months.

Bug reporting and sociopath developers describes the arrangement well: you were forced to collaborate, because the mountain was too big to move on your own. Working inside an org stacked a second layer on top of the first - designers, product managers, architecture guilds, platform teams, bastion hosts and Terraform (lots of Terraform) - a whole cohort of well-meaning people who absolutely had to be consulted about every little thing you do.

Now imagine you can move the mountain on your own, without consulting anyone and without having to explain, one more time, that a square is a square. Irresistible.

I have been on the other side of this too. The biggest ask I ever received about tracksperanto was to have it in Python - Ruby was Windows-unfriendly, rarely vetted into studio Linux distributions, and just felt weird to the people who needed tracksperanto the most. Back then I didn’t want to do it, and also couldn’t, because the task was too big. Thanks you, but I prefer it my way - and the mountain was not only an excuse, it was an objective limitation. Today? If folks ask, I will vibe-port in a heartbeat. It would take an agent a fortnight, mostly unattended.

Which is also how the square gets refused, when there is no mountain in the way. The first time I ran into it properly, the software in question had a homegrown scripting language whose tokenizer leaned on the C standard library for parsing numbers - and strtod() respects the user’s locale. On my Dutch colleagues’ machines, a 10.05 in a script would not parse, and the interpreter bailed out with “Invalid value”. I emailed the author with the problem, the workaround and the fix. The answer, paraphrased, was that he was right and I was wrong. The full story is in the aside, for those who enjoy a bit of C.

More than a decade ago, in my previous profession, I worked at a post-production company and was an ardent proponent of one particular piece of software. It handled a uniquely specific and crucial part of our workflow, did it faster and better than the competition, cost a fraction of their price - and was written by one single, brilliant engineer with a doctorate in robotics. It had a homegrown scripting language, and since I was already automating things for work I used it heavily: export modules, data translation, that sort of thing.

When we added a second seat, a Linux one, my scripts failed on it with “Invalid value” and no line number. The culprit took a while to find. My colleagues were Dutch, and some of them had export LC_ALL=nl_NL.UTF-8 in their shell profiles so that dates and numbers would look sensible to them - and in a Dutch locale the decimal separator is a comma. The C standard library functions used for parsing numbers - sscanf(), atof(), strtod() - respect that setting, and the tokenizer of the scripting language was built on them. Under a Dutch locale a perfectly ordinary 10.05 literal would not parse. The grammar of the language changed depending on who was running it.

It is an easy trap, and plenty of seasoned C programmers have fallen into it. So, being a fan of both the software and its author, I wrote him an email: here is the problem, here is the workaround we applied (force the locale to US English for that one program), here is how to fix it properly.

The response was terse, and the gist of it - my paraphrase - was: I am right, you are wrong, and what I am doing is perfectly fine. Perhaps he felt the user’s locale ought to be respected everywhere, and there is a version of that argument I could follow, if it weren’t for the literals in the scripts. It did not matter. I had my workaround, and he had his position.

Most of what makes feedback succeed sits with the recipient, not with the giver. A clear-cut “here is a problem, here is the fix” can still yield nothing but “go away, everything is fine”.

The sscanf story is the crude version: one author, one “no”. The subtle version is more common and more damaging, and the best specimen I know is Sprockets. In March 2012 somebody asked the Rails asset pipeline for source map support. The maintainers agreed on the spot - “Absolutely”, “Started a branch for this” - and then the feature took seven and a half years to ship, until October 2019. In between, a working pull request got closed in 2014 because the processor API had to be redesigned first, and Josh Peek, the diligent maintainer who wanted that redesign done properly and by himself, made his last commit in June 2015 and left Richard Schneeman to pick up the pieces alone. Nobody was rude. Every single decision was defensible. The sum of them was a feature the whole Rails world wanted arriving after everybody had moved on. The dates and the receipts are in the aside.

Sprockets started in 2008 as a small JavaScript concatenator by Sam Stephenson at 37signals. In 2011 it became the engine behind the Rails asset pipeline and its stewardship passed to Josh Peek, who did the 2.0 rewrite for Rails 3.1 and the 3.0 rewrite after it, with a great deal of careful design thinking in both. This is not a story about a lazy maintainer. It is a story about a very diligent one.

In March 2012 someone opened an issue asking for source map support. Source maps were brand new, and anyone writing CoffeeScript or SCSS could see they were going to change debugging in the browser completely. Sam replied “Absolutely.” Josh replied “Started a branch for this.” Then the issue went quiet. People kept dropping by - “whats the progress on this?” (2014), “Anything I can do to help?” (also 2014), “can we safely use the 4.0 branch if we’re really desperate?” (2015) - and none of them got an answer. In early 2014 a contributor brought an updated pull request with a working implementation. It was blocked on the processor API, which had to be redone for 3.0 first, and compilation should be a “pure functional” transformation with no temporary files on disk. A perfectly valid position. The pull request was closed a few months later, unmerged.

In September 2014 came the roadmap: 3.0 would be transitional, and 4.0 - “the big drop” - would have full source map support, “in the near future”. 3.0 shipped in April 2015. In June 2015 Josh made his last commit to Sprockets. Richard Schneeman picked up the pieces, largely alone and largely on his own time, and gave a talk with the telling title Saving Sprockets. Sprockets 4.0, with the source maps, was released in October 2019.

Seven and a half years after “Absolutely.”

I was one of the people who needed those maps badly, and in 2013 I gave up waiting and wrote Vitrine, a little development server, just to have them. When the 4.x branch got merged in 2015 I filed an issue because the maps got served but the browser was never told they existed; the answer was that this only worked in the debug pipeline, and “who knows.. maybe in the future there will be a more convenient way to do this..”. We are in the future. It never happened. By 2016 the mood had soured enough for Giles Bowkett to write Let The Asset Pipeline Die, which was unfair to Richard, who was doing the heavy lifting at that very moment - but hard to argue with from the receiving end. I wrote my own response at the time, too.

Note that nobody in this story was rude, and nobody said “go away”. What happened is subtler, and I think much more common. A maintainer had a clear picture of how the thing should be done properly - a new processor API, a pure functional pipeline, the beautiful stuff - and wanted it done that way, by himself, before anything else could land. Offers of help did not fit the picture, so they got a reasoned “not yet”, or silence, or got parked behind the redesign. Every individual decision was defensible. The sum of them was a feature the entire Rails world wanted taking seven and a half years, and a maintainer who burned through his own energy carrying it all - and then, understandably, left. It did not do Rails’ standing in the frontend world any favours either. Anyone who found their brownfield Rails.application.assets to be nil in production knows exactly what I am talking about.

Rails is omakase, and omakase lives by the chef’s aspirations. But omakase is not supposed to be huge, and Rails - after more than twenty years on the scene, with all its modules, libraries, dependencies and test cases - is frigging huge. That is not a bad thing; software that lives long and evolves grows functionality and guardrails, that’s just evolution.