Joe Duncko, who’s an engineering director I’ve known from hackathons and local meetups for a couple of years, recently wrote a piece for his blog: Organizations Adapt to the Cost of Iteration. He argues that:

• Businesses have historically been hesitant to add new software features to their products because of the time investment that’s required to implement them;
• Also, it’s been hard to iterate and improve on features because of the delay that a lengthy implementation process creates between having an idea and getting user feedback on it;
• And now that coding agents make it quicker and easier to write new software, businesses should be more willing to try new ideas, instead of subjecting them to lengthy approval processes.

I think that this makes sense on its own terms, and it’s the kind of change that a lot of people in the software development world are hoping for. But, I don’t know that it’ll always be an easy sell to the people who run companies. I want to take a quick step back, analyze this take from a holistic standpoint, and try to figure out the risk/reward calculation that an organization faces when it strives for higher velocity. I think the basic question is just this: in the future, will organizations move at the pace of software development, or will software development move at the pace of organizations?

I’m staying at the house of a friend of a friend whilst they’re off on tour with Ariana Grande. I take care of Mabel, who is a 9 year old corgi, and Grimm, the random stray cat that lives on the porch. Obviously, the owner needs regular updates as to the state of their livestock. Obviously, I burned through all the small talk and “Mabel continues to be a dog today” updates a while ago. All I can think to do is to rip off @cleolonglegs:

The tech sector of the economy has a structurally disproportionate amount of influence over the world. Among other things, this is because the number of people working on a tech product stays relatively low even as the number of people that their product reaches skyrockets. Take Discord: they have a few thousand employees and hundreds of millions of users. Contrast this with a business like a grocery store, where the amount of work goes up fairly steadily with the number of customers and the amount of stuff that they buy, or a lawyer’s office, where the amount of money coming in is tied to the amount of billable hours worked by specific attorneys and their staff.

The reason that so many businesses want to invest in AI is the potential of pushing this dynamic even further. A traditional law firm can only take on so many cases before needing to hire more attorneys; in contrast, the theoretical AI equivalent could serve tons of people with a few prompt engineers and the AI agents that they delegate the lawyerin’ to.

Originally posted to LinkedIn.

A few hot takes for the #vibecoding era:

I. Coding has been heading towards higher and higher levels of abstraction for a very, very long time. We’ve gone from assembly language to C to JavaScript.

When I first started pursuing web development, years before the initial release of ChatGPT, people were already talking about it as primarily a process of gluing together existing code, instead of writing things by hand like the good old days.

Nevertheless, interview questions about low-level stuff like sorting algorithms still got asked, even though almost no-one has written such things from scratch outside of school for a long time. I think that this indicates something about the enduring value of being able to understand technical stuff at a high level of detail.

Getting overwhelmed by emails is easy; millions are sent every second. The world-spanning network of machine-to-machine systems that allows you to receive autopay notifications for stuff you forgot you signed up for is complicated, but the piece of software known as “Outlook” makes it so that when you look at your computer, you just see emails. That list of emails is an “abstraction,” which means “a version of something that’s simplified to make it easier to fit in people’s brains.”

You can think of emails as electronic signals propagating over cables (which is a low level of abstraction, of which I have very little understanding), as TCP traffic between machines using specific ports and mail transfer protocols (which is a slightly higher level of abstraction that I mostly get), or you can think of it as a bunch of new posts from Substack and Patreon, requests to donate to political campaigns, and alerts about outages from hosting providers (which is a quite high level of abstraction that I can easily use to understand my email inbox right now.)

There’s a strong tendency among a certain type of person to think of low levels of abstraction as “how things really work.” And this produces tension when combined with another fact: companies are mostly led by people operating at very high levels of abstraction.

The term “separation of concerns” gives you an easy way to throw a wrench into almost any programming argument. It’s hard to interpret at the best of times, but it definitely sounds weighty and important, and so you can use it to argue against any code that you don’t like and for any code that you do like. Here are some models for separation of concerns that I have seen:

Model A: The Language Model

A one point, in the world of web development, it was easy to tell which part of the code was which, because each concern was addressed by a different language. The HTML created the content, the CSS established the styling, and the JavaScript added the interactivity:

“Promises” are a ubiquitous feature in the JavaScript language. For example, if you call the function fetch in order to get some kind of JSON object from an API, fetch will return a Promise:

const thisIsAPromise = fetch("/api/get-id/1");

What does that mean? The MDN documentation informs us that a Promise “is a proxy for a value not necessarily known when the promise is created.” That’s kind of true, and for a while, I even believed it. However, nowadays, I think that it’s actually easier to think of Promises as a way to manage code, not data.

Linus Torvalds is the legendary creator of the version control system “Git” and the kernel for the operating system “Linux,” which between them are used to develop approximately 125% of all software. He also gets mad on the Internet a lot. There’s a subreddit dedicated to his outbursts. He produces headlines like “Linus Torvalds on why he isn’t nice: ‘I don’t care about you’”. His feedback is often along the lines of:

So this patch is utter and absolute garbage, and should be shot in the head and buried very very deep. Please immediately delete it from the whole internet.

Or:

“Steven, stop making things more complicated than they need to be… You copied that function without understanding why it does what it does, and as a result your code IS GARBAGE. AGAIN.”

Back when I worked on the farm, when it rained, it mattered. I have a lot of memories of ducking into a barn, or into the truck, or going all the way back to the house for an early lunch just because the rain had come.

Most people probably think that rain is generally good for crops, but unless the topography of the land is perfectly mapped out to drain excess rainfall away from them, things get dicey. Plants’ roots need to absorb oxygen; in other words, they have to breathe a little. Roots can get enough air to respire from between the gaps in clusters of soil, but they can’t breathe through water. Too much rain will make them wither away. The only solution is to change the landscape so that the water won’t build up where you have things planted; the simplest way to do that is to dig drainage ditches.

Not all drainage is visible on the surface. It’s common to dig a ditch, fill it in with highly porous gravel or drain tile, and then let the dirt cover it up again, instead of fighting to keep it from eroding away season after season. In my time, we mostly filled in ditches with heavily perforated black drain pipe. The fields also had an ancient network of old, brown square porcelain tubes (yes, square tubes) that were laid end-to-end under the soil. No one quite knew where they were laid, which was exciting when digging or plowing. My grandfather remembered the burying of them in trenches as a kid.

Tonight, I went on a walk to the gas station to buy soda and got trapped by the rain. It’s been a while since that happened. I mean, it has rained in the last five years, but it hasn’t really affected my life. It’s surprisingly pleasant to get trapped like that: there’s nothing you can do, and there’s nothing happening that’s not supposed to happen. It’s free peace.

In my post about GIFs, I pointed out that the creators of the GIF file format explicitly said that it wasn’t meant to be a great format for animations, but since it was widely available in people’s browsers, and no-one actually read that spec, it ended up being used for animations all over the place anyway, and now it’s all the format is known for. By opening a technological window, and allowing some limited animations to be stored in .gif files, they closed a door (new file formats with more advanced compression are constantly pushed back on because people are used to GIFs.)

Unrelatedly, here are two keywords that exist in JavaScript: const and let. let creates a variable that can have a new value assigned to it later, while const creates a variable that will always have the same value attached to it. const is the typical way that people declare variables in modern JavaScript; thanks largely to linting rules and style guides like the Airbnb JavaScript style guide, which for whatever reason was very popular back in the day, a generation of programmers learned that changing the values of variables was to be avoided, and obviously const is the way to do that, right?