Having a Creative Practice as a Programmer

2026-05-31 · page · source ↗ · source summary

Manuel (the.scapegoat.dev) argues that programming is artistic practice — source code as artifact, not just executable — and that programmers have optimized for intellectual collaboration while neglecting what artists know: that a daily creative practice, separate from productive output, is what sustains craft over a career. Drawing on years of sketchbooks and music, he distills creative practice into habit, deliberate practice, throwaway studies, mundane maintenance, and reflection — then applies each to programming. The sharpest insight: open-source side projects are not creative practice. They're "rendering a painting" — known work that takes time. Creative practice is smaller, messier, and judged by process, not product.

Key Quotes

"There can be a separate track within one's career that runs parallel to one's 'productive output.'"

This is the essay's central reframe. The painter has the grand painting and the daily sketchbook. Most programmers only have the grand painting — their job — and wonder why they burn out. The parallel track isn't a side hustle; it's the thing that makes the main track sustainable.

"Everything you do is valuable, but nothing you create is of value."

Manuel's most counterintuitive claim, and the hardest for programmers to internalize. The professional instinct is that output must justify the time. Creative practice inverts this: the time justifies itself. The output is a byproduct. This is the same move that separates a sketchbook from a commission.

"Nothing is worse than making something good and then trying to replicate that success."

The accidental-hit trap. One good thing becomes a tyrant — every subsequent attempt measured against it, freedom replaced by expectation. Deliberately making terrible things is the inoculation. This is genuinely hard for programmers, whose entire professional identity is built on making things that work.

"We are often overly precious with our source code."

The diagnosis behind the studies prescription. Programmers treat code like finished work, which kills experimentation. The fix: build throwaway prototypes that sidestep infrastructure — hash tables not databases, function calls not HTTP APIs. "Try and try again until we finally understand what we want." Compare with Code Field's "resist the urge to over-specify" — both are about lowering the stakes enough to actually explore.

"Velocity at the computer is fundamental to the quality of my cognition as a programmer."

Manuel's deliberate-practice claim applied to tools: vim movement, keyboard macros, window navigation. Not because speed matters for its own sake, but because fluency at the interface removes friction between thought and expression. This is the same argument musicians make about scales — you don't perform scales, but you can't perform without them.

"Keep a diary or a blog and record what you worked on."

The reflection mechanism. Writing is "a potent catalyst for thought" — not just recording what happened, but discovering what you think about what happened. This connects directly to One Year of Keeping a Tada List (daily accomplishment tracking as forced reflection) and If AI Is Doing the Investigation, Version the Investigation (preserving the reasoning, not just the output).

Key Themes

#concept #practice #creativity #craft

The parallel track. The most transferable idea: creative practice runs beside productive work, not instead of it or as an escape from it. It's maintenance for the person who does the work. Without it, you're drawing from a depleting well.

Process over product. Every characteristic Manuel lists — habit, deliberate practice, studies, mundane tasks, reflection — is about the doing, not the done. This is the through-line connecting sketchbooks, music practice, and JavaScript snippets. The value is in the practitioner, not the artifact.

Open source is not practice. Manuel's most useful negative definition. Open source has users, issues, PRs, expectations. It's real work that happens to be unpaid. Creative practice has none of that — it's "exploratory software work" with zero external stakes. The distinction matters because confusing the two is how side projects become second jobs.

Mundanity as infrastructure. Cleaning brushes, untangling cables, emptying inboxes, upgrading credential managers. These aren't distractions from practice; they are practice. Time spent on pedestrian infrastructure "is that much time you will have won" when you sit down to do creative work. This echoes The Mundanity of Excellence — excellence is a collection of small, correct, boring things done consistently.

Deliberate practice at the interface. The warm-up exercises from drawing class — lines, ellipses, curves — map directly to vim drills and keyboard shortcut practice. Tool fluency isn't optimization theater; it's reducing the distance between thought and expression. A programmer who thinks through their tools thinks better than one who fights them.

Critical Analysis

What's right and important. Manuel has identified something the software industry is terrible at acknowledging: creative work depletes you, and the industry's standard replenishment strategies (conferences, "hack weeks," side projects) are consumption or labor, not practice. The parallel-track model is the best framing I've seen for why 10%-time programs fail — they measure output, not process. Creative practice can't be a JIRA ticket.

The tension with agent-era programming. This essay was written in 2022, before coding agents became a daily reality. In 2026, the question is sharper: if agents handle implementation, what is a programmer's creative practice? Manuel's answer would probably be that the practice shifts up the stack — from vim drills to prompt craft, from JavaScript snippets to spec experiments, from tool fluency to taste development. The parallel track doesn't disappear; it moves to wherever the human is doing the thinking.

What's missing. Manuel is honest that he's still figuring out what programming creative practice looks like — the essay is more diagnostic than prescriptive. The concrete examples (JS snippets, tweets, Obsidian entries) are thin compared to the rich detail from drawing and music. This is partly because programming creative practice is genuinely harder to define — code has no equivalent of a sketchbook that's universally recognized as practice rather than product. Creative coding actually has one: The Importance of Sketching with Code describes the sketch as exactly that object — small, exploratory, judged by the question it asks rather than the product it ships, and framed as "solving problems you don't have yet." But it's also because he's earlier in the journey. A follow-up in 2026 would be fascinating.

The vibe-coding parallel. Vibe Coding and the Maker Movement describes "evaluative anesthesia" — the dopamine of making eclipsing the ability to judge. Manuel's creative practice is the antidote: practice without expectation, making without the need to ship. But there's a danger he doesn't name: creative practice can become its own form of evaluative anesthesia, where you're always "practicing" and never shipping. The parallel track needs a firewall — Creative Firewall's logic applied to time rather than authenticity.

The craft connection. This essay belongs next to Software Engineering Craft in the wiki. That page tracks the fundamentals that don't change; this one describes the practice that keeps those fundamentals alive in a person. Craft is what you know; creative practice is how you keep knowing it. Slowing the Fuck Down makes the case for deliberate friction; Manuel makes the case for deliberate low-stakes work. They're different arguments that converge on the same conclusion: sustainable programming requires time spent not producing.

See Also

Sources: Having a Creative Practice as a Programmer Last updated: 2026-05-31