Sometimes I spend a long time perusing books or the internet, spoken and written words alike, and among the many reasons for such an endeavour (does one need a reason to, err, procrastinate?) I will nominate a strong craving for new ideas:

did it ever occur that —

or what if this ever came to —

what if we turn the parallel —

into
the
orthogonal

to then try to make sense of it

and every so often, then, there is a a-ha! moment as one comes across something that really gets the gears going — we're struck with novel thoughts! — and even more seldomly, but preciously!, chance presents significant perspectives that resonate deeper.

This shifts things in such a way that past and present arrangements are seen in a new light; it is as if new patterns emerged, and possible new paths, with new names for previously invisible modes of action — — —

— but so many words! Get to the point, Alex.

[November 6th, 2024: this writing has been long overdue; it is a try at connecting to ideas in Maggie Appleton's talk at Local Conf — link is below — but also an opportunity to update my stance on llms and other modern tools.

It might change in the future, because — because we play by internet's rules, everyone.]

Crafting things, making stuff, putting ideas into the world — programming is represented among such verbs, with immense possibilities — and a few days more than a month ago, one of these stints of clicking around on the internet brought me to Maggie Appleton's talk at Local First Conf: Home-Cooked Software and Barefoot Developers.

It spans not more than half an hour — and it is also masterfully presented in text for those who'd rather — so please indulge. It's about designing local-first software, using LLMs to empower programmers, and a new-found sense of scale. Some concepts were new to me; Maggie juggled and jumbled them all into a big ball of wonder. Thus, baby-steps: we shall start with local-first software, sparing just a second of thought on a concept whose name practically contains its definition.

The term precedes the article, but 2019's Ink and Switch "Local-first software: You own the data, in spite of the cloud is a good primer on the topic and a possible definition for the idea.

A conciser take: local-first means to think of, and prioritise, data on the device rather than on a remote server (it is more than this — but for a start it will do). Immediate consequences? Things are generally faster; another: one doesn't depend on the internet to get work done (one absurdity that we collectively let ourselves fall prey to, not only on the domain of work but also of private entertainment and culture — but I digress). Still relevant, albeit slightly less meaningful for a great majority, is the concern of privacy.

Local-first as a paradigm is enjoying some momentum recently, but is still far from default, and arguably not even on the consumer's radar. But Appleton is not only onto local-first as proposed in the 2019 article; it takes on the broader meaning of local, one that we tend to associate with authenticity and familiarity. Among the talk's various points, there is a proposed contrast between large-scale, industrial software (think cloud benemoths the size of Google, Amazon, Netflix) vs. something one would whip up at home — the software equivalent of grandma's cool hand-knit sweater, the small restaurant from the neighbourhood that spans two decades of history — or a freelance, amateur take on programming.

Is it not striking that "[...] people working for large Californian corporations and shipping their software overseas [...]" have so thoroughly pervaded and molded our digital interactions and expectations — and we never really gave it more than a moment's notice?

I remember the launch of Github Copilot, and my first tries at it; then ChatGPT came along, with its strong impression on geeks and laypeople of society at large (and do you remember when? 2021 and 2022, respectively — does time fly?). But the earnest and cute code prediction via autocomplete of 2021 pales aside today's state-of-the-art (at consumer level!) LLMs, which can now oversee the creation of entire full-stack applications...and AI progress hasn't really slowed down yet.

The second part of the argument is less philosophical and more pragmatic. LLMs empower the enthusiastic t(h)inkerer by doing away with extensive studies of frameworks, or on how to connect different services in a deployment architecture. One can be at home and write a program in (almost) plain English; and while it is still necessary to have some degree of familiarity with code practices, it seems to be a matter of time — or of getting the right tools together in a LLM driven workflow — to do away with handling code entirely.

There's plenty of anecdotal evidence for and against gains of productivity, clearer code, more joy in working in professional developer settings. But this happens at a lower scale as well: I have personally met — and learned much from — programmers who started with, and found their footing, in chatGPT: unabashedly wielding it in all circumstances, the problems are thought of, bugs fixed, and code ran without much knowledge beyond a for loop, let alone general best practices, proper software architecture, or measures for reliability of software. And these new, code-avoidant programmers stand aside hard-planners, die-hard-touch-typists, hard to convince developers of — gasp! — maybe five years ago.

Let then there be no doubt: LLMs bring value to the accessibility of creating software, and we should embrace and celebrate an influx of new perspectives that challenge the dominant highly-technical background that many of us carry. So what exactly is the point here? Not a single one, but a handful. For one, things are really changing: despite the blockchain-like fad and hype that AI carries — it's evident how companies are shoehorning new and shiny technology in places which were doing very well without — LLMs have very immediate applications that even the most resistant naysayer must come to acknowledge. People can code both faster and further, now.

And then Appleton's presentation ends with a quote from Ivan Illich's Tools for Conviviality, itself an invaluable gem in this perspective shift from the major and global to small and local, to back up the vision of handling software, and computer tinkering in general, at the scale of a kind, thoughtful gesture to people or communities we care about. It is unfortunate — but not irremediable! — that such an attitude has not been cultivated in the last few years, and as a real possibility for so many engineers.

Of course, there's the argument against the use and reliance on LLMs — tools that may or may not be trained on data they should have no access to, or consume much more energy than a single individual would manage to generate — the latter a possible argument against the technology via Illich's own ideas on resource management. I am all for rethinking our present technological stances: to decentralise, to reduce dependency on data-driven models of profit, and even to just — for the sake of sanity — slow down.

But we're sort of stuck here, aren't we? In a way, if one can wield one tool to become a 10x programmer, some natural law of, err, capitalism, makes it so that we must all catch up in order to remain relevant. It is rather accelerationist in nature — and I'm on the fence about the whole thing — but Appleton paints an earnest case for a new segment of work, in which I recognize a sliver of hope for more independence and self-reliance, and I cannot help but sympathise with.

And back to the my main point: why did this resonate so much? Again, I was just perusing the internet, available for chance encounters — and I felt recognized in small-scale software. In the last couple of years, I've put efforts in a handful of small tools, with specific and limited application, for my own use: their market-fit was never thought as larger than one. But through social media and quotidian life, they have been graced by the eye and awe of others; they also target the very particular problems of people near me, who happen to care for the same things.

In the last month (it is now evident why these words took so long!) I developed differently, as an experiment, with plenty of help from Claude and Cursor, iterating over the product rather than the code itself. Having lots of fun, generating some insights into the process, but overall at peace with the big shifts that are happening, at a global scale, for what it means to be a programmer.