Originally adapted from Ron Miller's Advanced Improv Practice Guide, and discovered at the bottom of jyn's incredible blog post titled "i'm just having fun", which is a must-read.

Before starting your daily practice routine, read and seriously consider the following:

A. DAILY AFFIRMATIONS

1. How fortunate I am that in this life I am one who has been allowed to create beauty with computer.
2. It is my responsibility to create peace, beauty, and love with computer.

B. I WILL BE KIND TO MYSELF

1. IT IS ONLY COMPUTER
2. No matter my level of development in computer, how good or bad I think I am, it is only computer and I am a beautiful person.
3. I will not compare myself with my colleagues. If they do computer beautifully, I will enjoy it and be thankful and proud that I live in fellowship with them.
4. There will always be someone with more abilities in computer than my own as there will be those with less.

C. REASONS TO DO COMPUTER

1. To contribute to the world's spiritual growth.
2. To contribute to my own self-discovery and spiritual growth.
3. To pay homage to all the great practitioners of computer, past and present, who have added beauty to the world.

D. RID YOUR SELF OF THE FOLLOWING REASONS FOR BEING A PRACTITIONER OF COMPUTER

1. To create self-esteem
2. To be "hip"
3. To manipulate
4. To get rich or famous

Here’s the paradox that makes this pattern particularly poignant. We’ve made extraordinary progress in software capabilities. The Apollo guidance computer had 4KB of RAM. Your smartphone has millions of times more computing power. We’ve built tools and frameworks that genuinely make many aspects of development easier.

Yet demand for software far exceeds our ability to create it. Every organization needs more software than it can build. The backlog of desired features and new initiatives grows faster than development teams can address it.

This tension—powerful tools yet insufficient capacity—keeps the dream alive. Business leaders look at the backlog and think, “There must be a way to go faster, to enable more people to contribute.” That’s a reasonable thought. It leads naturally to enthusiasm for any tool or approach that promises to democratize software creation.

The challenge is that software development isn’t primarily constrained by typing speed or syntax knowledge. It’s constrained by the thinking required to handle complexity well. Faster typing doesn’t help when you’re thinking through how to handle concurrent database updates. Simpler syntax doesn’t help when you’re reasoning about security implications.

Big O notation is a way of describing the performance of a function without using time. Rather than timing a function from start to finish, big O describes how the time grows as the input size increases. It is used to help understand how programs will perform across a range of inputs.

In this post I'm going to cover 4 frequently-used categories of big O notation: constant, logarithmic, linear, and quadratic. Don't worry if these words mean nothing to you right now. I'm going to talk about them in detail, as well as visualise them, throughout this post.

I have a minor in computer science, and I remember sitting through many explanations of the importance of Big O notation, yet it hasn’t really mattered much in my career until recently.

If you have heard of Big O but aren’t clear on how it works, give this post a shot. It contains a lot of great visualizations to help drive the point home.

Too many bangers to pull out of this one. Well worth a full read. But here are a couple juicy pull quotes to whet your pallette:

Programming lures us into believing we can control the outside events. That is where the suffering begins. There is something deeper happening here. This is not just about software.

I believe sometimes building things is how we self-soothe. We write a new tool or a script because we are in a desperate need for a small victory. We write a new tool because we are overwhelmed. Refactor it, not because the code is messy, but your life is. We chase the perfect system because it gives us something to hold onto when everything else is spinning.

I’m trying to let things stay a little broken. Because I’ve realized I don’t want to fix everything. I just want to feel OK in a world that often isn’t. I can fix something, but not everything.

You learn how to program. You learn how to fix things. But the hardest thing you’ll ever learn is when to leave them broken.

And maybe that’s the most human skill of all.

We should stop worshipping numerical comfort. Twenty partial views don’t make a whole picture. They make noise. They make an echo. They create professionalized, sanitized, panel-approved blindness.

If you're lucky enough to know someone with twenty years of scar tissue in a domain, listen. Don't just ask what they know. Ask what they've unlearned. Ask what they stopped saying because nobody understood. That's where the signal lives.

“Worshipping numerical comfort” is a fantastic phrase that I’ll be pondering here for the next few days.

I’m writing about this today because it’s been one of my “can LLMs do this reliably yet?” questions for over two years now. I think they’ve just crossed the line into being useful as research assistants, without feeling the need to check everything they say with a fine-tooth comb.

I still don’t trust them not to make mistakes, but I think I might trust them enough that I’ll skip my own fact-checking for lower-stakes tasks.

This also means that a bunch of the potential dark futures we’ve been predicting for the last couple of years are a whole lot more likely to become true. Why visit websites if you can get your answers directly from the chatbot instead?

The lawsuits over this started flying back when the LLMs were still mostly rubbish. The stakes are a lot higher now that they’re actually good at it!

I can feel my usage of Google search taking a nosedive already. I expect a bumpy ride as a new economic model for the Web lurches into view.

I keep thinking of the quote that “information wants to be free”.

As the capabilities of open-source LLMs continue to increase, I keep finding myself wanting a locally-running model at arms length any time I’m near a computer.

How many more cool things can I accomplish with computers if I can always have a “good enough” answer at my disposal for virtually any question for free?

The single best trait to predict whether I'm looking at a good programmer or a great one is undoubtedly perseverance. Someone that takes to each new challenge like a dog to a bone, and who struggles to sleep until the next obstacle is cleared.

Today (literally today), I delivered the final story for the third project I’ve had at my day job since starting back in October.

This project involved a lot of unknowns and uncertainties, and resulted in a ton of code that was written and thrown away in order to arrive at the final stab at version 1.

It was painful. Ask my wife and she’ll tell you I spent many days in doubt, riddled with anxiety and impostor syndrome, feeling like a fraud.

But then, just like that, I’m able to click the “squash and merge” button, and it’s done. The clouds lift. It’s incredible.

Sort of reminds me of Courtney Dauwalter’s pain cave metaphor. Every time I start an engineering project, I go into the pain cave and start chiseling away at the walls.

Once I’ve chiseled enough, I am rewarded by stepping back out of the cave and celebrating what I’ve built. It’s an incredible feeling.

It’s a short lived euphoria, though. I only get a few moments before I dust myself off, grab a quick bite to eat, and begin my descent back into the cave to start chiseling away on the next project.

Maybe, like a lot of other middle-aged professionals suddenly finding their careers upended at the peak of their creative power, I will have to adapt or face replacement. Or maybe my best bet is to continue to zig while others are zagging, and to try to keep my coding skills sharp while everyone else is “vibe coding” a monstrosity that I will have to debug when it crashes in production someday.

I enjoyed this piece because I think it represents the feelings I hear from artists. You might not consider computer programming an art form, but if art is humans expressing themselves, then writing code absolutely qualifies.

And like a lot of other artists, many of us "computer people” make money by doing our art for other people. It turns out that for the last fourty years, we could do our art for other people and we'd get paid quite well to do so.

But now that anyone can basically vibe code solutions to basic problems¹, a increasing set of non-nerds is able to use computers themselves. That naturally will drive down our value.

I use "value" here in a cold, hard, capitalistic sense. Maybe it's our turn, as artists who care about making efficient, beautiful, artistic computer programs, to worry about how we'll derive value in a world where anyone can vibe code their ideas to life.

If you want to onboard someone onto a new codebase, let them rewrite part of it. They’ll learn a lot from the process, but crucially they’ll become an instant subject-matter expert on the part they rewrote. With a few refactors, you can go from a situation where you’re the only go-to engineer to a situation where multiple engineers on the team can take ownership. That’s the only sustainable way to run a large codebase.

This is exactly what I’ve been doing at work for the last six months, and now I’m the subject matter expert on a small number of essential components of the system.

These sneaky buggers… ?

I realised the other day that I actually have a straightforward heuristic for this. I count the number of times I have this thought:

“Oh nice catch, I didn’t think of that!”

Man, Sean’s been on an absolute tear lately with these observations. Definitely worth an RSS feed add if you’re into software engineering.