







A lot of effective engineering comes from the accumulation of small nuggets of knowledge.
Learnable Programming
Here's a trick question: How do we get people to understand programming?
The Gap Through Which We Praise the Machine
My current theory of agentic programming: people are amazing at adapting the tools they're given and totally underestimate the extent to which they do it, and the amount of skill we build doing that is an incidental consequence of how badly the tools are designed.

All you need is data and functions
It's really easy to tend towards complexity as engineers. I think on some level, we love complexity. There are obviously bad types of complexity, but I think there are other types of it that we seek out, because there's something satisfying about wrapping your head around it; and I think a lot of that kind of complexity ends up in our programming languages.
Programming (with AI agents) as theory building
Back in 1985, computer scientist Peter Naur wrote “Programming as Theory Building”. According to Naur — and I agree with him — the core output of software engineers is not the program itself, but the theory of how the program works. In other words, the knowledge inside the engineer’s mind is the primary artifact of engineering work, and the actual software is merely a by-product of that.

Can Current Agents Close the Discovery-to-Application Gap? A Case Study in Minecraft
Discovering causal regularities and applying them to build functional systems--the discovery-to-application loop--is a hallmark of general intelligence, yet evaluating this capacity has been hindered by the vast complexity gap between scientific discovery and real-world engineering. We introduce SciCrafter, a Minecraft-based benchmark that operationalizes this loop through parameterized redstone circuit tasks. Agents must ignite lamps in specified patterns (e.g., simultaneously or in timed sequences); scaling target parameters substantially increases construction complexity and required knowledge, forcing genuine discovery rather than reliance on memorized solutions. Evaluating frontier models including GPT-5.2, Gemini-3-Pro, and Claude-Opus-4.5 under a general-purpose code agent scaffold, we find that all plateau at approximately 26% success rate. To diagnose these failures, we decompose the loop into four capacities--knowledge gap identification, experimental discovery, knowledge consolidation, and knowledge application--and design targeted interventions whose marginal contributions serve as proxies for corresponding gaps. Our analysis reveals that although the general knowledge application capability still remains as the biggest gap across all models, for frontier models the knowledge gap identification starts to become a major hurdle--indicating the bottleneck is shifting from solving problems right to raising the right problems for current AI. We release SciCrafter as a diagnostic probe for future research on AI systems that navigate the full discovery-to-application loop.

Teach Yourself Programming in Ten Years
The conclusion is that either people are in a big rush to learn about programming, or that programming is somehow fabulously easier to learn than anything else. Felleisen et al. give a nod to this trend in their book How to Design Programs, when they say "Bad programming is easy. Idiots can learn it in 21 days, even if they are dummies." The Abtruse Goose comic also had their take.
Programming principles for self taught front-end developers
The majority of us are a bunch of self taught people with rather spotty knowledge and that's fine! Kilian (also self taught) is here to share some of the computer science fundamentals you probably are missing with the aim to improve your code in the long term.
The peril of laziness lost | The Observation Deck
In his classic Programming Perl — affectionately known to a generation of technologists as "the Camel Book" — Larry Wall famously wrote of the three virtues of a programmer as laziness, impatience, and hubris: If we’re going to talk about good software design, we have to talk about Laziness, Impatience, and Hubris, the basis of good software design. We’ve all fallen into the trap of using cut-and-paste when we should have defined a higher-level abstraction, if only just a loop or subroutine. To be sure, some folks have gone to the opposite extreme of defining ever-growing mounds of higher level abstractions when they should have used cut-and-paste. Generally, though, most of us need to think about using more abstraction rather than less.
We should rethink how we teach people to code | deadSimpleTech
It's fair to say that the tech industry at the moment is not in a good place. Software engineers tend to be detached, demotivated and unwilling to care much about the work they're doing beyond their paycheck. Code quality is poor on the whole, made worse by the current spate of vibe coding and whatever other febrile ideas come out of Sam Altman's brain. Much of the software that we write is either useless or actively hurts people. And the talented, creative people that we most need in the industry are pushed to the margins of it.

Coding Agents Are Easy, Actually - Kara's Nonsense
Software engineering is here to stay
Programming as Theory Building: Why Senior Developers Are More Valuable Than Ever
Peter Naur's 1985 theory of programming explains why experience matters more in the age of AI-generated code

The Optimization Trap: Why Too Much Efficiency Makes Us Fragile with Olivier Hamant
</> htmx ~ Working With AI: A Concrete Example
In this essay, Carson Gross walks through a concrete bug fix in hyperscript to show where AI helped, where it fell short, and why keeping a knowledgeable human in the loop is what kept complexity in check.
How I stopped worrying and learned to love the easy fix
On the balance between perfect solutions and pragmatic fixes in software engineering
Knowledge Collapse
AI companies are racing to mechanize mathematics. Where does that leave human understanding?

Seeing Like a Programmer (LambdaConf 2024) — Sympolymathesy, by Chris Krycho
How do we make good software, and indeed, what makes software good: both as software, and in terms of its place in the world?
