The Privilege not to Rush

Hello, A Newsletter by Arne Brasseur Aug 31

(View in browser)

Hello,

A decade ago, in May 2016, I launched a series of educational videos about Clojure under the name Lambda Island. I had a little launch party in my Berlin appartment. A friend made a Lambda Island cake.

With everything going on this year already I completely missed this ten year anniversary! A belated Happy Birthday to my brainchild!

The months prior I had spent building the software platform the site would run on. Videos, transcripts, memberships, subscriptions, a shopping cart with checkout flow, discount codes, a blog and newsletter functionality. The works.

And then I started making videos, first one a week, then one every two weeks, until eventually it would become sporadic. I was working all by myself in my apartment, burning through my savings, trying to reach break-even before it broke the bank. It was pretty brutal, and my mental health took a hit. (Here’s an old post I wrote after the first year.) Eventually I started contracting again, and Lambda Island fizzled out.

But I learned so much. The last ten years of my career are entirely built on that experience. Hard truths about doing business, about running software in production, but also technical chops. For each video I would take a popular Clojure library, and turn it inside out. Read the docs, read the code, try it out until it broke. Build something with it that allowed me to explain authoritatively what it did and how it did it.

It meant going slow, and sweating the details. Every line of that code would be on the screen, 30 points large. The code had to make sense, it had to sing.

While working on the Lambda Island code base, at some point I created my own URI library, being unsatisfied any of the existing libraries. I thought it was pretty nifty, and to get some extra visibility I released it as lambdaisland/uri. Lambda Island Open Source was born, and continues with dozens of projects to this day.

Many of the other projects came later, during the Gaiwan years. As we worked on projects, for clients or internally, we kept recognising pieces that we wanted to have in our toolkit for future projects, problems that we wanted to solve properly once and for all.

This code couldn’t be rushed, because it had to be right. Often we had approached the same problem a few times already, across projects, from different angles, and then at some point what you do is, you try to hold all the needs and tensions and trade-offs you’ve encountered in your head at the same time, until an implementation crystalises. It still won’t be perfect, it never is, but it’s the closest to perfection you’re going to get today. A perfectly encapsulated piece of functionality, at your disposal forever after.

It is a privilege not to be rushed. In her Beyond Tellerrand keynote, titled "Living Through an AI Takeover Without Losing Your Soul", Lauren Celenza asks the question, "What if speed wasn’t the priority?". The understanding being that speed is always the priority, the alternative a happy fantasy we can dream away to when we close our eyes.

Or is this a solution that’s in search of a problem? And how would we solve this differently if speed weren’t the priority? Of course, speed is always the priority. It will remain the priority in business, right? But what if we just, just for a moment, did an exercise together where we asked ourselves, how would we solve this differently if speed weren’t the priority? I do this with teams all the time. It’s actually quite astounding. The new conversations and questions and ideas that emerge. It sort of stirs the room up a bit.

People say "fast, good, cheap, you get to pick two". There’s a joke going around that with LLMs you get to pick "fast" twice. But really this isn’t a new thing. Software development has always had a tricky relationship with time. Development time is slippery. Sometimes, under the right conditions, you can move incredibly fast. More commonly time slips through your fingers like water. You hit a snag, old decisions made under pressure come back to bite you, requirements are suddenly a lot more open to interpretation than you expected.

While building Lambda Island I really got to see both sides of that coin. I shipped a lot of functionality in those first few months. The code wasn’t always pretty, but I was running it myself, and dealing with support requests, which limited the shortcuts I was willing to take. I did learn to be extremely pragmatic. Skip everything that feels like ceremony. Keep the system as simple and straightforward as possible. You need sharp tools if you want to do that. I would routinely REPL in to production.

But some things could not be rushed. I would simply work at a natural pace, keeping my wits about me, until things were done. I had no one to keep me accountable except my bank account.

And I’ve done the same many times since. Explaining to clients that certain things are important, and they will take as long as they take. This can be a scary thing to do, it requires that people trust you, and it requires that you manage expectations well, before people become impatient. But it pays dividends.

Sadly I know a lot of devs who are not able to do this, because they don’t enjoy that trust. Because the way their teams and projects are managed means that only the rush job feels acceptable. But it’s a race to the bottom. This is not how you get recognised for technical competency, and eventually your skills and your career will suffer. This is twice as tough for women, who have to work twice as hard for the same recognition, and who are more often asked to justify the time it took to do their work.

If you are in charge of engineers, ask yourself if they are given the space to go slow when it’s worth it, when it’s needed. Trust your people when they tell you, they are the ones that know best. As a developer, your leverage may be limited. The best you can hope for is to carefully manage upwards, to educate the people above you about what they are really asking for.

FuncProgConf & BeClojure

You can find me this Wednesday in Leuven, Belgium, for an informal Clojure meetup. We did a few of these before the summer, and they were always a lot of fun. There are no talks, we just get a drink and talk about life. The last few editions we had a simply rule: "no Trump, no AI". This created space for some of the realest conversations I’ve had last year. I’m looking forward to hearing what folks got up to over the summer!

Mobilizon (fediverse) event page · OpenMeet (ATProto) event page

Next month I’m visiting Stockholm, Sweden, for FuncProgConf (October 14). We’re also doing a Clojure Café the day before. I was reminded at Dutch Clojure Days just how important it is to see people in person, and I have some friends and acquaintances in Stockholm I’d love to see again.

Open Source

This week saw the first proper release of lambdaisland/dbus-client. Technically there was already a release last year, but it had some showstopper bugs, which I finally took the time to address. It’s one of those things that I know I will find unexpected uses for now that I have it in my toolkit.

I also spent a few days on Compass, to get it ready for Clojure/Conj. Much of that was customising the styling to incorporate their house brand, but I also fixed a whole lot of small issues I noticed, especially in the features we added in a rush in the run-up to Heart of Clojure 2024.

HeartConf

Several people have already offered their help for HeartConf, which I am deeply grateful for. I’m working on getting some structure and planning in place, I think it’s important to have a good basis for collaboration before I start pulling others in.

The rebranding from Heart of Clojure to HeartConf means I can’t just copy-paste the previous edition. New house style, new domain name, a different venue, and a different scope. It’s cool, I get to invent a whole new conference, while taking all of the learnings from the 2019 and 2024 editions. It’s also a lot of work, but I’m slowly chipping away at it. I added an about page to the skeleton website, so at least people can get a sense of what we’re going for here.

Poll

I want this newsletter to be a two-way street. A few people have already responded via email, which I really appreciate, and I always try to take the time to write back.

But, as an easy way to get some input from you, dear reader, I would also like to include a poll. Starting with this one:

Poll: What do you want to read about in this newsletter?

I only listed a few options, but you can write in your own answers as well.

This poll is made with Pollariser.eu, a lovely polling app by a fellow reader of this newsletter, Tomáš Baránek, written in Clojure. It’s the kind of indy effort I love to see and support!

Bookmarks

A selection from my Mastodon bookmarks

• The Teaser Period: Why the AI Boom Is Hitting a Reset Wall
  This is a long read, and it asks for some economic literacy, but it makes a compelling comparison between subprime mortgages pre-2008, and AI data center funding today. It makes a compelling case that especially OpenAI is likely to end up in a situation in 2027-2028, where they have to raise large amounts of additional capital to pay for data center capacity they ordered, and that raising that capital depends on revenue targets they will quite likely not reach. It’s not a certainty that will happen, but if it does it could have devastating results for the industry, and really for the entire global economy.
• Stanisław Lem foretold the current LLM mania in 1964
  This is pretty remarkable, a Story by Stanisław Lem from 1964, about an electric poetry machine. It’s trained on large amounts of existing books, people do wacky prompt engineering. Poets hate it but the media loves it, some develop AI psychosis, and in the end the creator shuts it down because it’s using obscene amounts of electricity. Lem is one of the great sci-fi writers of the sixties, not as widely read these days as Isaac Asimov or Frank Herbert, but every bit as worth reading. (He also inspired the Lem project, an emacs-like editor in Common Lisp).
• Data Became Code: We Ran Code Inside Fortune 500s Using Files They Published for AI Agents
  The stupidity will continue until AI improves.
• Baldur Bjarnason - The story of this blog so far: ‘AI’, the death of web dev, and feeling like an outsider
  Baldur Bjarnason came onto my radar because of some of his writing on AI, but it seems like he’s swum through a few different waters already, and is trying to figure out where to go from here. Some of it is quite recognisable. I think he’s someone to keep an eye on.
• Youtube - Quitting AI greatly improved my mental health & enjoyment of work
  
  A dev tells his story. There’s some wisdom there, and a few good book recommendations.

Picture

Since I forgot to share a picture last time, here’s a snap from my SUP board in the French Pyrenees.