







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?
Learn To Code, It’s Harder Than You Think
TL;DR: All the evidence shows that programming requires a high level of aptitude that only a small percentage of the population possess. The...
Motivating Adult Learners by Introducing Programming Concepts with Scratch
Novice programmers usually fail to combine abstract concepts and knowledge into program design, even though they know the syntax and semantics of individual statement. Adult novice programmers with little computer background knowledge might face more ...

The Bulk of Software Engineering is Just Plumbing
I read a post online recently about how some software engineer was asked to complete a technically complex, jargon-filled coding challenge over the...

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.

The Most Important Non-Programming Skills for Programmers
Skills for programmers that are so much more important than any language, library, or framework

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.
Complexity and Strategy | HackerNoon
I struggled with how to think about complexity through much of my career, especially during the ten years I spent leading Office development. Modeling complexity impacted how we planned major releases, our technical strategy as we moved to new platforms, how we thought about the impact of new technologies, how we competed with Google Apps, how we thought about open source and throughout “frank and open” discussions with Bill Gates on our long term technical strategy for building the Office applications.

Complexity and Strategy | HackerNoon
I struggled with how to think about complexity through much of my career, especially during the ten years I spent leading Office development. Modeling complexity impacted how we planned major releases, our technical strategy as we moved to new platforms, how we thought about the impact of new technologies, how we competed with Google Apps, how we thought about open source and throughout “frank and open” discussions with Bill Gates on our long term technical strategy for building the Office applications.

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