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.

This post deeply resonates with me.

Never give up seeking truth, however uncomfortable it is. Search for knowledge. Adjust your worldview. Ask. Rewrite outdated code. Drop faulty hypotheses and unreliable foundations.

Software author is, first of all, a writer. They are a person who stands upright and says: “that’s what I know for now, and that’s my best attempt to explain it.” Having this stance, preferring it to everything else, and hiding behind terms, concepts, and authority are invaluable qualities for long-term project success.

Or, basically, for any long-term human activity success.

When I’m in the zone, problems seem more straightforward. Even complex tasks feel pretty doable. Once I notice that, I try to pack my time with high-priority work only. I’ll put off responding to all but really important messages (Slack’s “remind me later” is a great feature). I also try as hard as I can to avoid multi-tasking, so I can keep my entire attention on getting a single task right at a time. If I feel like continuing to work through the evening, I let myself do that, knowing I’ll give myself the time back the next day or the one after that.

When I’m not in the zone, every task seems complex and rife with booby-traps. I feel like I have to proceed defensively and avoid taking risks. On days like these, I try and knock out easy wins and don’t worry so much about prioritization. I do a lot of general talking and bouncing between multiple projects. I don’t feel so bad about stopping work earlier than usual, knowing that at some point I’ll make it up with a period of hard focus

I’ve been reading Sean Goedecke’s blog for a few weeks now, and it is exceptionally helpful to hear these words at this point in my career.

This post spoke to me because I’m working on a project at work where it’s been hard to achieve flow for consistent periods of time.

I’m sharing this to remind myself that it’s okay to have rough days, and the important thing is to be honest with yourself and show up every day, even (especially?) if you don’t want to.

My latest self-improvement experiment is determining what environmental factors will induce flow. I can’t seem to find the right album, the right physical space, the right combination of stimulants and exercise, the right amount of “small wins”, whatever it might be to help trigger the excitement that comes when I get into flow.

The most consistently successful approach has been to completely accept my current situation and problem solve as best I can in that exact moment. In other words, I ask myself: how can I win this moment?

Though Nintendo employs more-modern technologies now, they are still criticized for not having the most-modern technologies that their rivals are all-too-happy to include, often at the cost of compatibility, affordability, and energy efficiency.

This is not a condemnation of using cutting-edge technology. But if given the choice, I prefer “lateral thinking with withered technology.” I think that’s a great philosophy to consider when making anything.

“Lateral thinking with withered technology” is how I approach building websites. Use battle-tested, slow moving frameworks that don’t depend on a cornucopia of vulnerable third party plugins. :cough cough wordpress react cough sneeze:

HTML and CSS are going nowhere, and vanilla JS can do virtually anything you need these days. Render your stuff server side and keep the client side lightweight.