Daily one-pagers about AI, leadership, technology, and being human.

johnmaconline

I'm writing to think, learn, and remember in public. I'll be here everyday.

July 17, 2026 2 minute read

The Great Software Garbage Patch

Maybe you’ve heard of the Great Pacific Garbage Patch (GPGP).

It’s a collection of plastic and floating trash out in the middle of the Pacific Ocean. It’s real and needs attention (and receives attention), but also, it’s not a walkable floating island of plastic water bottles, which one team doom-markets it as.

AI is currently creating the Great Software Garbage Patch.

Billions of lines of garbage code, throwaway prototypes, and AI slop. It’s a little harder to put your finger on because it’s dispersed across GitHub and GitLab, the cloud, and 100s of millions of laptops and servers.

Like the GPGP, it’s real, and it needs attention.

It’s happening because AI makes coding accessible to everybody with an idea. It’s happening because AI enables software engineers to do more and create more faster, the byproduct of which is slop and tech debt. It’s happening because, like with many other things in our world, we assume more is better.

Hard drives all over the planet (and yes, “the cloud” is really just servers connected to real hard drives) are screaming for relief.

Maybe we can use AI to help clean itself up.

I wonder if our future includes altruistic organizations focused on cleaning up, reigning in, and managing AI output. I think we’re trending in that direction.

But like with the Ocean Project, somebody’s gonna have to care enough to take it on.

July 16, 2026 2 minute read

If It Were Easy, It Would Already Be Done

So many things are easy to do. Yet, somehow they’re not done.

One reason might be priority. Since those things are easy, we prioritize the hard ones. Thinking to ourselves, “That’s easy. I can do it any time.” Yet, there they sit. Continuously deprioritized and never done.

Another reason might be laziness. I just don’t feel like it. So we don’t.

But before we dismiss laziness as the reason, it’s worth a second-level analysis. Maybe what we’re calling laziness is really the first one — priority. The easy-to-do thing hasn’t risen high enough on the priority list, including “Lay on the couch.”

Another reason might be that it seems easy, but it’s actually not. We talk about how easy it is. Others corroborate. It seems easy because each of the parts or steps in the process seems easy. But sometimes we confuse “known” or “well understood” with easy.

That one’s the trap.

It’s the trap for the organization, and it’s the trap for you. Just because a piece of it’s easy, or the steps are known, or that a small version of it is easy, doesn’t mean the real thing is easy.

Known or understood is not the same as easy. An easily built prototype is not the same as a customer-worthy production version. An easily sent email is not the same as a useful document. An easily sent slack message is not the same as an in-person conversation.

Because what we realize is that if it were easy, it would already be done.

July 15, 2026 3 minute read

Chesterton’s Fence

“Don’t remove a rule, process, tradition, design, or constraint until you understand why it was put there.”

G. K. Chesterton said this in his 1929 book titled “The Thing: Why I am a Catholic.” He was defending older social institutions, especially domestic life, family, tradition, religion, and inherited social practices, against what he saw as shallow modern reform for convenience and culture.

We owned college student apartments for about 15 years. We closed on them in the summer, just a few weeks before the students moved in; therefore, the leases in place were created by the sellers.

They weren’t ours.

I noticed a bunch of weird clauses in them that didn’t make any sense to me. Or, they seemed to violate basic common sense. There was a clause about using the toilets only for what toilets were made for. There was a clause about not using grills indoors, keeping interior doors in their frames, keeping the heat on in the winter, and so on.

I looked at these and thought, “These are dumb. Let’s get rid of all this and simplify!”

Well, over the 15 years, we had tenants who:

  • Built a campfire on the wooden floor of an attic (don’t worry, they put a stone ring around it).
  • Removed all of the interior doors (there were 11) to create a beer-pong tournament in the yard.
  • Used a toilet as a cooler, got a can stuck in the neck, and then broke the toilet trying to remove it.
  • Charged friends to “rent parking spaces”, which was just the front yard of the house.
  • Turned the heat off to save money. The pipes froze.
  • Moved the grill into the kitchen because it was raining. The fire company showed up.

And many more, which still provide great story material for sitting around with friends and a couple of beers. By the time we sold them, our lease had a plethora of new clauses that I’m sure our buyers looked at and said, “These are dumb. They don’t make any sense.”

The new guy comes in, looks around, and says, “What is this old-timey BS? That’s stupid. Let’s get rid of it!”

OK, fair enough. Sometimes, that’s exactly what the situation needs. A fresh look. New eyes. A different point of view.

But also, what about the inherent wisdom built up through historical experience? We do it this way because… We have this policy because… We make you pay this tax because…

Institutions build knowledge through experience, and that experience often shows up in the form of rules, processes, and constraints.

Yes, you should occasionally look at these rules, but before tearing them down, ask yourself what problem, situation, failure, danger, abuse, or trade-off caused people to create them in the first place?

July 14, 2026 1 minute read

It’s the People

Is it the job or is it the people who work there? It’s the people who work there.

Is it the neighborhood or is it the people who live there? It’s the people who live there.

Is it the theology or is it the people in the pews? It’s the people in the pews.

It’s the people.

Always choose the people.

July 13, 2026 2 minute read

Lindy Effect

“The longer something has survived, the longer it will keep surviving.”

The Lindy Effect comes from a 1964 article by Albert Goldman titled “Lindy’s Law,” which described an observation he made about show business, but has been broadened to life in general first by Benoit Mandlebrot, and then by Nassim Taleb.

For example, a book that has been in print for 100 years is, by Lindy Effect logic, more likely to remain relevant and durable than a book published last year.

Have you ever put something on a shelf or in a cabinet temporarily, fully meaning to figure out where it should live permanently later on, but that just becomes its permanent location? That’s the Lindy Effect.

The Lindy Effect happens to software engineers all the time. We make a little script or tool, and it’s fragile and crappy and was never intended to live beyond today, but then it somehow gets legs. You use it again tomorrow and your colleague sees it and asks you to share it. They use it. It makes it into the repository, and other members of the team start using it.

Now it’s been around for a while, and other tooling and infrastructure use it and are built around it.

Eventually, it just is part of the workflow. With all of its fragility and foibles.

We also call that “tech debt.”

The reason we call it debt is because eventually, we have to pay the piper. We have to clean it up. And that process is usually daunting, time-consuming, and costly.

AI loves to create tech debt. It’s one of its superpowers.

AI doesn’t know about the future. It doesn’t know what you’re planning on doing with it and what it’s making. Therefore, it’s always trying to build the easiest solution it can. Unless you give it requirements and specs that define the future it must consider, you’ll get a crappy little one-off solution that creates debt right away.

To guard against the Lindy Effect, ensuring poor software lives longer than it should, you gotta be a good boss of AI.

And being a good boss of AI is really just being a good engineer.

P.S. Lindy’s, by the way, was a New York deli in which many actors and comedians hung out in the 60s.

July 12, 2026 2 minute read

Amara’s Law

“We tend to overestimate the effect of a technology in the short run and underestimate its effect in the long run.”

The wording itself is a paraphrased amalgamation of ideas from Roy Amara, an American futurist and researcher during the 1960s and 70s.

The internet is a great example of this law.

The dot-com bust happened precisely because we hyped too much, too quick. We thought every company needed an internet business strategy immediately, even if that business model didn’t make sense for a particular company. The investment community insisted on an internet business model for any company it might invest in.

This was the 90s. Yes, the internet was starting to insert itself into culture and started affecting commerce, but it was too early for “all business” to be done over the internet. The world wasn’t quite ready. So the bubble burst.

But look at business today. The internet has lived up to those mid-90s predictions. All business, and much of life, needs an internet strategy. It just took longer than was predicted.

So will AI take over all knowledge work, like some are predicting? Will most human work be trade and labor? If so, how long will it really take?

It remains to be seen. I’m optimistic that it won’t, or if it does, humans and the system will have time to adjust as we did with the internet.

Here’s what I do believe, though: AI is here, and AI, whether quickly or slowly, will affect most knowledge work.

You’ve been warned.

July 11, 2026 1 minute read

Conway’s Law

“Organizations design systems that mirror their own communication structures.”

This rule comes from a 1968 paper by Melvin Conway about “How Do Committees Invent?”

Basically, look at your current organizational structure. Your product’s architecture will likely follow that structure closely.

For example, if you have a firmware team, a host library team, and a host application team, then your product’s software architecture will mirror that. You’ll have a firmware module, a host library, and a host application.

You’re probably saying, “Duh, that’s what we want.”

And that might be true.

However, what about test and verification? Conway’s Law says that if you also sprinkle your test team across the organization, then you’ll end with one platform that tests firmware, another that tests the host library, and a third that tests the host application.

In a small org, that might be ok. In a large and complex org, that’s probably not what you want.

So you can reverse engineer Conway’s Law.

Design your organization to match your product’s intended structure.

July 10, 2026 1 minute read

Yes, Like a Calculator

Calculators didn’t wipe out jobs. Neither did computers.

At least not in the toggle-switch way that people talk about AI.

But they did affect jobs and how people do their jobs. We used to employ rooms full of people to hand-calculate complex equations. We also used to employ rooms full of people to first typeset and later type handwritten documentation for distribution.

We don’t employ rooms full of those people anymore because the calculator and the computer have moved those functions to the creators of the information. They enable the creators. But we still do employ administrative assistants, accountants, and engineers. Their jobs have changed a bit.

AI is doing and will continue to do the same thing. It may have a broader scale and touch more professions, but it’s fundamentally similar.

Only time will tell what the true effect will be.

However, I think we will still need junior workers. We will still need mid-level workers. We will still need senior workers. And managers and executives as well. Responsibilities will probably move around with capabilities.

But yes, AI is like the calculator.

July 9, 2026 1 minute read

Like a Calculator for Coding

People still do math in their heads and on paper.

But the calculator (and by extension, the phone/computer) has taken over the great majority of the heavy lifting arithmetic in daily human life. Even quick and dirty math. Watch clerks try to make change. Watch customers try to calculate a tip. Watch players sum up their scores at the end of the board game or the hand of cards.

AI is doing the same thing for software development.

Much like a professional accountant works with spreadsheets and ledger applications rather than a ledger book and pencil, professional programmers now work with AI rather than a text editor and make files.

Oh sure, we still look at the code. We may even tweak it here and there.

But AI is writing it, like the calculator is doing our math.

So does that mean we’ll lose the knowledge of programming? Is it something we need to collectively worry about?

I’m not sure yet. The calculator hasn’t destroyed humanity’s ability to do math, but it’s certainly a crutch.

Are crutches bad?

July 8, 2026 1 minute read

Humans Will Stop Writing Code

I’m now fairly convinced.

We’ll stop writing code. There will still be code, of course, but it’ll be written entirely by the agents.

It just makes so much sense. I watch myself now, and I realize that I tell the agent to do everything, including basic and simple stuff that would be easy for me to do.

If I want to change an error message, I tell the agent to do it. If I want to change an input argument, I tell the agent to do it. If I want to make the output blue instead of green, I tell the agent to do it. If I want to commit and push “my” code to the repository, I tell the agent to do it.

The agent knows syntax better than me. The agent’s purpose is to do this work.

My purpose it is to tell the agent what to do. What are we trying to accomplish? What are the requirements? How do we verify we’re getting what we need?

Humans will stop writing code, but the smart ones will continue to be the boss.

Pin It on Pinterest