Notes

You simply cannot breathe without seeing, hearing, or engaging in any kind of technical conversation about AI. AI has dominated the Zeitgeist so catastrophically that the only way to escape is to turn off the WiFi and delete all the apps. Every single piece of fucking software has some kind of shitty AI add-on, forced into your face at regular intervals whilst you’re trying to go about your life or do your job or check your email or write an email or read an email or talk to a human support agent or read a recipe or open an issue on an open-source project or watch a YouTube video or open your IDE or do a fucking internet search. The cognitive overload of AI trying to Make You More Productive™️ whilst you’re actually trying to be productive is so shockingly absurd. And yet, we are being made to feel like we are stagnating, being left behind, not good enough, that we are luddites should we not adopt this imposing technology. We are being told we’re missing out, even though we’re probably doing just fine. The technology is gaslighting us.

It's all opt-out (if you're lucky enough to be able to turn it off) too.

What’s even more personally terrifying: what if I need to find a new job in the near future? There are seemingly no non-generative-AI-centred options left for someone like me. I’m afraid that every opportunity will either be for a company building some kind of generative AI experience, or one that mandates the use of generative AI in your daily responsibilities, or one that refuses to use AI at the expense of their financial success and the stability of my employment. At this point I cannot escape. I am at the mercy of the profession I chose. I have a family to feed and a mortgage to pay. Retraining is not an option right now. I must force myself to adapt.

This was a fantastic conversation bringing in a bunch of the nuance that is so often missed.

No one was particularly optimizing for engagement or time-on-site or conversion. People made websites because they had something to say, or something to show, or just because they could. The web was weird and slow and full of bad tiled backgrounds, bad fonts and dumb ideas.

It was also weirdly, wildly, wonderfully human.

I almost feel like this is one benefit of Musk's takeover of Twitter/X. More people seem to have started building or resurrecting their own personal sites.

There are still people building the web by hand, very much like we did it in the early days. They know all about what's possible using modern tooling, yet they choose to expend their time and attention to the craft of doing it by hand. They care about the craft, and they care about what they're making. They believe in their unique skill and vision over engagement strategies and analytics and content algorithms. They don't need a platform, or they'll build their own.

But agentic coding is about more than moving upwards in abstraction. The compiler gave us abstraction without ambiguity. You wrote C, and it became assembly, deterministically. The layers were clean, and you remained a programmer in the traditional sense of how we’ve always understood the word.

What’s happening with agentic coding might better be captured by a term coined by Venkatesh Rao: “oozification.” Oozification, as Rao describes it, is the tendency of technological systems to evolve from structures built of large, rule-heavy building blocks to ones composed of smaller, more fluid, less constrained components.

Imagine, if you will, the difference between a man-made, plantation forest and a swamp. The forest has legible structure: tidy rows, canopy, understory, floor. The swamp is murkier, richer in evolutionary possibility, but also much harder to read. Oozification is the transformation of the forest into the swamp. The number of possibilities increases, while the number of certainties decreases, and that combination tends to make people downright nervous.

A natural language prompt doesn’t compile into code. Instead, it gets interpreted, completed and sometimes second-guessed by a probabilistic system. Intent blurs into elaboration and precise control gives way to fuzzy suggestion. It’s oozy and messy programming, and the role of the programmer blurs as well into something with unclear boundaries—part orchestrator, delegator, babysitter, designer, reviewer. People have always struggled to call software development honest-to-goodness “engineering,” and with the oozification of the practice, that highly-esteemed label has only become more ill-fitting.

Complexity looks smart. Not because it is, but because our systems are set up to reward it. And the incentive problem doesn’t start at promotion time. It starts before you even get the job.

I've learned so much over the years, and while it is always helpful to think about how features might be used in the future, it's even more helpful to know when to worry about it now, and when to leave it for later...if later ever comes.

The actual path to seniority isn’t learning more tools and patterns, but learning when not to use them. Anyone can add complexity. It takes experience and confidence to leave it out.

I've heard the term cognitive debt being bandied about. Having to deal with larger PRs, especially with a good deal of AI-generated code can be taxing.

This, I believe, is why reviewing AI-generated code feels so much more exhausting than reviewing a colleague's work. When a human pair submits code after a whiteboarding session, I am reviewing implementation against a design I already understand and agreed to. When AI generates code from a single prompt, I am simultaneously evaluating scope (did it build what I needed?), architecture (are the component boundaries right?), integration (does it fit our existing infrastructure?), contracts (are the interfaces correct?), and code quality (is the implementation clean?) — all at once, all entangled.

That is too many dimensions of judgment for a single pass. The brain is not built for it. Things get missed — not because I am careless, but because I am overloaded.

There’s no mention of how these tools are causing corporations to blow past their already tepid climate goal; no mention of how the affluent, surveillance-obsessed exec dictating its trajectory enthusiastically cozied up to fascists; no mention of how Elon Musk and Mark Zuckerberg’s data centers are funneling pollution directly into black neighborhoods; zero mention of the technofascist plan to leverage AI to decimate unions; no mention of the weird and precarious financial shell games powering the sector.

I don’t like using code that I haven’t written and understood myself. Sometimes its unavoidable. I use two JavaScript libraries on The Session. One for displaying interactive maps and another for generating sheet music. As dependencies go, they’re very good but I still don’t like the feeling of being dependant on anything I don’t fully understand.

I can’t stomach the idea of using npm to install client-side JavaScript (which then installs more JavaScript, which in turn is dependant on even more JavaScript). It gives me the heebie-jeebies. I’m kind of astonished that most front-end developers have normalised doing daily trust falls with their codebases.

I don’t think I’m as adverse to dependencies as Jeremy, but I’ve definitely shifted more to his views over the years. I’ll definitely write my own code more readily than I would’ve several years ago.

I do get the appeal of building in React, really, I do. It’s a fun programming model, and there are inherent organisational benefits to the component paradigm it pushes so hard. There’s also a lot you can reuse out there, and maybe that gives you the confidence that you’ll spend less time in the initial implementation, leaving you longer for improvements and polish.

And that’s fair, you probably won’t find a larger ecosystem of components, libraries, and complementary frameworks, ready to use! But beyond generally poor performance, they come with another pretty big caveat: they don’t seem to last very long. In my experience, there isn’t much in the way of stability in the React ecosystem, or even the JS ecosystem as a whole. Perhaps that’s changing lately, but historically, I’ve seen multiple large applications end up rewriting massive portions of their code after a while, not because of product reasons, but because of dependencies

It is easy to find a library for anything you need in React. It's what it makes it easy to quickly build things. But building quickly doesn't mean building well.

It’s time to stop lying to ourselves that JS-heavy client-side approaches are the way to develop a web app nowadays. We really should stop reflexively reaching for JS frameworks for everything we build, and to stop basing our architecture decisions on the stack we’re most familiar with.

"How we've always done it" is so often too easy to say and do.

We really owe it to our users to do better as an industry, because right now we’re often building the way we want to, not the way they need us to.

This is a phenomenal deep dive into all the different ways you can customize the HTML list elements.

I enjoy programming computers because they function on a set of precise and rigid rules. This creates a kind of fantasy world where you can gain wizard-like powers as you accumulate knowledge. Yes, programming is hard and it can be exasperating, but that makes the eventual accomplishment of mastering the skill all the sweeter. Over time, you gain fluency and dexterity as a programmer. It feels good.

Which is to say that the pleasure I get from programming is mostly about learning the underlying truths about computation and applying what I’ve learned. Always improving the craft. This, to me, is the practice of programming.

As the saying goes, the more you learn, the more you realize how much there is still to learn. I’ve spent countless hours over the last 30 years reading about, thinking about, and practicing the art, hobby, occupation, and discipline of programming computers. If only by volume, it’s a big part of who I am.

This is why I love development.

We value learning. We value the merits of language design, type systems, software maintenance, levels of abstraction, and yeah, if I’m honest, minute syntactical differences, the color of the bike shed, and the best way to get that perfectly smooth shave on a yak. I’m not sure what we’re called now, "heirloom programmers"?

Do I sound like a machine code programmer in the 1950s refusing to learn structured programming and compiled languages? I reject that comparison. I love a beautiful abstraction just as much as I love a good low-level trick.

If the problem is that we’ve painted our development environments into a corner that requires tons of boilerplate, then that is the problem. We should have been chopping the cruft away and replacing it with deterministic abstractions like we’ve always done. That’s what that Larry Wall quote about good programmers being lazy was about. It did not mean that we would be okay with pulling a damn slot machine lever a couple times to generate the boilerplate.

I like this definition that the problem lies in “never reorganizing [the code] to reflect your understanding.” In a go-go-go product cycle, that loss of understanding begins to create problems that have literal and figurative costs. A general sense of confusion builds and builds. The developer economics are fairly simple to quantify; either you slow down and pay someone to refactor and document the code after every major iteration, or you pay every developer who works on the project until the end of time to stare at the code for a few hours and wonder what the hell is going on. That dumbfounded staring at the codebase compounds over time. Organizationally, you pay in velocity and turnover; talented people are going to leave after a few rounds of bullshit.