When Casey Reas and Ben Fry released Processing in 2001, they made a decision that would ripple through two decades of digital art: they hid OpenGL. That single abstraction—wrapping verbose graphics calls in ellipse() and line()—didn't just simplify code. It defined what kinds of images artists would imagine making.

This is the strange power of building tools for other artists. You are not shipping features. You are shipping a worldview—a set of assumptions about what art is easy, what art is hard, and what art is even conceivable within your framework.

For experienced creative coders considering this leap from making work to making the substrate others work on, the challenges are less technical than philosophical. What do you hide? What do you make beautiful by default? And how do you write documentation that doesn't just explain, but invites?

Every function you expose is a hypothesis about what your users want to think about. Every function you hide is a hypothesis about what they'd rather not. Getting this ratio wrong in either direction is fatal—too much abstraction and your tool becomes a toy; too little and it becomes a chore.

Consider the spectrum. On one end sits something like p5.js, where background(220) paints the entire canvas in a single call. On the other end sits raw WebGL, where the same operation requires shader compilation, vertex buffers, and matrix math. Neither is correct. They serve different creative postures.

The critical insight is that abstractions are not just about ease—they are about what becomes thinkable. When Zach Lieberman designed openFrameworks, he deliberately kept certain graphics operations transparent because he wanted artists to feel the geometry, to treat pixels as material. Hiding too much would have amputated a mode of thought.

The pragmatic approach: identify the one creative decision your tool is optimizing for, and expose that dimension richly. Hide everything else behind sensible defaults. A tool for typography needs granular control over letterforms but not over event loops. A tool for generative motion needs frame-perfect timing but not over color spaces.

Takeaway

Abstractions do not merely simplify—they shape the horizon of what your users can imagine. Choose what to hide by asking what deserves attention, not what deserves convenience.

Every tool ships with defaults, and those defaults quietly colonize the aesthetic imagination of everyone who uses it. The gray Processing background. The Comic Sans of PowerPoint. The specific teal-and-orange of DaVinci Resolve. These are not neutral choices. They become the visual accent of an entire generation of work.

This is the burden that tool designers rarely discuss openly: your default stroke weight, your default easing curve, your default noise seed—these will appear in tens of thousands of works. Ship an ugly default and you have inflicted ugliness at scale. Ship a beautiful one and you have quietly elevated the baseline of an entire community.

But beauty in defaults is not about making everything look polished. It's about making the first thing a user sees feel like an invitation rather than a specimen. When TouchDesigner opens with a working particle system, when Hydra loads with a pulsing shader already running, the user's first experience is not a blank canvas but a living artifact they can perturb.

The deeper responsibility: your defaults teach taste. A student writing their first draw() loop absorbs your color palette, your stroke ratios, your framerate assumptions as if they were laws of nature. Design them as you would design a museum's permanent collection—because for many users, they will be.

Takeaway

Defaults are not the absence of design decisions. They are the most consequential design decisions you will ever make, precisely because users experience them as invisible.

Most technical documentation answers the question: what does this function do? Great creative coding documentation answers a different question: what could I do with this function that I hadn't considered? This shift, from reference to provocation, transforms docs from a manual into a collaborator.

The p5.js reference is a masterclass here. Every function comes not just with a signature but with a runnable, editable example—often something visually surprising rather than minimal. You look up bezierVertex() expecting a curve formula and encounter a strange organic shape that makes you want to modify it. The documentation seeds curiosity before it dispenses knowledge.

This principle scales. Consider how the Three.js examples page functions less as documentation and more as a gallery—hundreds of tiny worlds, each demonstrating a technique but also being an artwork in miniature. Users don't read Three.js docs; they browse them the way one browses a museum, waiting to feel the pull of something.

Practical craft: pair every technical description with an example that is slightly excessive—one that goes beyond demonstrating the API to hint at what the API is for. Include the weird edge cases. Show the function used against its apparent purpose. Documentation that only demonstrates intended use teaches obedience; documentation that demonstrates play teaches art.

Takeaway

Documentation is not a debt you pay after building a tool. It is where the tool's creative philosophy either becomes contagious or dies quietly on a reference page.

Building tools for other artists is a peculiar form of authorship. Your work will appear inside thousands of other works, uncredited and often unnoticed, shaping what those artists can see and say.

The three decisions—what to abstract, what to default, how to document—are really one decision repeated at different scales. Each asks: what kind of imagination do I want to make possible? The technical questions are downstream of that aesthetic one.

The best creative coding tools are not neutral platforms. They are opinionated collaborators with taste, generosity, and a clear sense of what art might become. Build accordingly.