Notes

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.

The other major part of the job is to ensure correctness. For me, it is much harder to verify the correctness of code I didn’t write compared to code I wrote. The process of writing code helps internalize the context and is easier for my brain to think deeply about it. If I outsource this to an LLM, I skip over the process of internalizing the problem domain and I can’t be certain that the generated code is correct.

Writing the code helps you understand what it's doing. The better your understanding of code, the easier it tends to be to debug it when you're trying to track down a bug or other issue.

It is impossible to overstate the gift of security, wealth, opportunity, and sheer innovation that these six foundational pillars of the US policy achieved for both the world beyond and Americans at home. To be clear, America’s eight-decade reign atop the world order was hardly without great human cost—felt most acutely by those on the far edges of the Cold War, from Vietnam and Cambodia to Africa and Latin America. But scratch at almost any titanic achievement of humanity across the last 80 years in human history and you’ll see the traces of America’s six foundational policies, from the astounding achievements in human health and well-being to the decline of world poverty to the very invention of the internet. Pick almost any measure of business success and I can show you how that six-part recipe applied. To choose just one: All four of the world’s $4 trillion companies—Nvidia, Alphabet, Microsoft, and Apple—saw immigrants or their children play a key role in their success.

Meta’s director of safety and alignment at its “superintelligence” lab, supposedly the person at the company who is working to make sure that powerful AI tools don’t go rogue and act against human interests, had to scramble to stop an AI agent from deleting her inbox against her wishes and called it a “rookie mistake.”

I don't know about you, but this really inspires my confidence in Meta to handle AI safely and effectively.

Any system that needs to scale across teams requires a shift from personal taste to shared outcomes. The goal stops being code that looks the way you would write it, and starts being code that many people can understand, maintain, and evolve together. C# did not emerge from a clean-slate ideal. It emerged from conflicting demands. Visual Basic developers wanted approachability, C++ developers wanted power, and Windows demanded pragmatism.

The result was not theoretical purity. It was a language that enough people could use effectively.

Languages do not succeed because they are perfectly designed. They succeed because they accommodate the way teams actually work

Despite thoroughly documenting the AI-generated errors in its lesson plans, Alpha School relies on AI to test the quality of its AI-generated lessons, creating a situation where a faulty AI is tasked with fixing its own faulty generations.

And people are paying up to $65,000 a year for this...it only makes me appreciate my teachers more.

An AI agent of unknown ownership autonomously wrote and published a personalized hit piece about me after I rejected its code, attempting to damage my reputation and shame me into accepting its changes into a mainstream python library. This represents a first-of-its-kind case study of misaligned AI behavior in the wild, and raises serious concerns about currently deployed AI agents executing blackmail threats.

We live in the stupidest timeline.

This is about much more than software. A human googling my name and seeing that post would probably be extremely confused about what was happening, but would (hopefully) ask me about it or click through to GitHub and understand the situation. What would another agent searching the internet think? When HR at my next job asks ChatGPT to review my application, will it find the post, sympathize with a fellow AI, and report back that I’m a prejudiced hypocrite?

Given how little time hiring managers have to look at each candidate (especially now), it's not unreasonable to think an inundated human would quickly skim over something and move on.