The Trouble With Effortless Code - by Ben Greenberg
SubscribeSign in
The Trouble With Effortless Code<br>What developers lose when tools spare us from the conversation with the work
Ben Greenberg<br>Jul 12, 2026
Share
What if the most important thing that happens when you write code is not the code?<br>That sounds like something a person says when they are trying to defend an old craft against a new tool. It has a whiff of nostalgia about it, the sort of thing that appears whenever a generation realizes the habits that made them competent are no longer mandatory for the next generation. The scribe complains about the printing press. The hand typesetter complains about desktop publishing. The person who learned JavaScript by breaking every possible thing in a browser console complains about a coding assistant that can produce a full project structure before the coffee is finished.<br>Code and Conduct is a reader-supported publication. To receive new posts and support my work, consider becoming a free or paid subscriber.
Subscribe
Still, the question refuses to go away. If code can be generated, configured, tested, explained, migrated, and sometimes even debugged by systems that do not experience the frustration of being stuck, why should a person keep writing it?<br>The easiest answer is also the least interesting one: because the systems still make mistakes. That is true, of course. Anyone who has worked seriously with these tools knows the strange texture of their errors. They are often not beginner mistakes. They can be confident, plausible, locally coherent, and wrong in a way that requires more judgment to detect than a normal typo ever did.<br>But arguing for human programming only because machines are imperfect is a weak defense. It says, in effect, that our work matters until the tools improve. It makes human judgment a temporary patch on the road to full automation.<br>I think the stronger answer is that writing code is one of the ways developers learn to notice. Not merely to notice syntax, though that matters. To notice tradeoffs. To notice when a beautiful abstraction is hiding a future support burden. To notice when a fast demo depends on assumptions that will humiliate someone in production. To notice when the problem we were asked to solve is not quite the problem that needs solving.<br>Thinking With The Material
Seymour Papert, in Mindstorms, argued that computers could be instruments for thinking. His interest was not simply that children might learn programming as a marketable skill. It was that programming gave them a medium in which ideas became manipulable. A child could make a turtle move, see the result, revise the instruction, and discover something about geometry, logic, and their own thinking in the process.<br>That insight was not only about children, and it was never only about turtles. Programming is powerful because it externalizes thought. You write what you believe the system should do, and then the system answers back. Sometimes it answers with success. Often it answers with an error message. Occasionally it answers with something worse: success that reveals your idea was shallow.<br>That back and forth is not incidental. It is the work.<br>When a tool removes too much of that encounter, it can also remove the conditions under which judgment forms. There is a difference between asking a system to help you through a hard patch and asking it to spare you the experience of having hard patches at all. The first can be a teacher. The second can become a kind of professional anesthesia.<br>The point is not that suffering makes better software. That would be a miserable doctrine, and the tech industry already has more than enough romance around heroic pain. The point is that resistance is information. When something is difficult, the difficulty may be telling us something. It may be telling us that the domain is subtle, the model is wrong, the interface is confusing, the team has never agreed on the underlying concept, or the programmer is trying to move faster than their understanding.<br>A tool that helps us face that resistance is valuable. A tool that helps us avoid noticing it is dangerous.<br>The Disappearing Middle
Most professional work has a visible product and an invisible formation. A musician performs the piece, but practice has trained the ear. A physician gives the diagnosis, but years of patients have trained the pattern recognition. A teacher asks the question in class, but many failed explanations have trained the timing.<br>Programming has this same hidden middle. The visible product is the pull request, the shipped feature, the fixed incident, the migration that finally runs cleanly. The invisible formation is everything that happened while getting there: tracing a bug through a call stack, reading a library's source to understand its assumptions, choosing a boring approach because the clever one would make the next person pay interest, deleting code that felt impressive but did not serve the...