I am not a programmer who later discovered design, and I am not a designer who believes code is simply a production step that happens after the interesting decisions are finished. My relationship with creative coding sits somewhere less tidy between those two descriptions.
For me, creative coding begins when the behaviour of a system becomes part of the visual idea.
The prototype changes the design
When I design a static poster, I can decide the composition and know that the final object will preserve that relationship. An interactive screen is different. The visitor moves. Data changes. The viewport changes. The interface waits, responds, fails, reloads and sometimes gets used in ways I did not predict.
Code is not only implementing the design. It is exposing what the design forgot to consider.
That is why I like building prototypes early. The moment an orbit starts moving, a bubble becomes draggable or a control has to respond under a thumb, the project begins giving visual feedback that no static mock-up could provide.
Behaviour can carry brand character
Brand identity is often discussed through logos, colour, typography and imagery. On digital products, behaviour can be equally recognisable.
The way the orbit expands, the way a section transitions, the way the Fan Club feels playful rather than administrative—those are brand decisions too. They tell the visitor something about BC Art & Design before any paragraph explains it.
Creative coding gives me access to that layer. It lets the interface express personality through movement and response rather than only through surface styling.
The technical limit is part of the composition
I enjoy constraints because they turn vague creative wishes into design problems. A mobile device cannot comfortably render the same density as a large desktop. An API should not be called without considering latency and limits. A complex animation has a performance cost. Accessibility and reduced-motion preferences matter.
Instead of treating those constraints as the engineer's problem after the visual work is complete, I prefer to let them shape the concept.
The Fan Club became group-based because thousands of profiles are too much to show at once. That technical limitation created variety and exploration. The blog became a separate, simple reading system because long-form SEO content should not be trapped inside an animated single-page state. The orbit gained a fallback because experimental navigation should still have a reliable route.
The limitations improved the design.
I do not code to prove that I can code
There is a temptation in creative technology to turn the technique into the subject. Complex shaders, elaborate motion, impressive libraries and clever interactions can become a form of performance for other creators.
I enjoy technical craft, but I try to ask a less glamorous question: does this make the experience better or more memorable for the person who did not read the source code?
If the answer is no, the cleverness may belong in a laboratory rather than the final interface.
Creative coding keeps my disciplines connected
Photography taught me to look. Graphic design taught me hierarchy. Corporate work taught me systems. Game design taught me feedback. Coding gives those lessons a place to interact in real time.
That is why I continue to enjoy it. Code is not a separate identity I attach to design work. It is another material, like type, image, sound or motion—one with rules strict enough to expose lazy thinking and flexible enough to make strange ideas possible.
The best moment is still the same one I felt as a kid experimenting with the web: the screen does something that did not exist a moment earlier, and the idea becomes behaviour.
That, to me, is creative coding.
Where creative coding should stop
The ability to customise behaviour can encourage endless intervention. Sometimes the best code is the code I decide not to write. If a native browser behaviour is clearer, faster and more accessible than a custom version, replacing it simply to make the project feel unique is usually a bad trade. Creative freedom includes the freedom to leave a good default alone.
That is another reason I treat code as a design material rather than a performance of technical identity. Materials have strengths and limits. A good designer does not use every material on every project; the choice itself carries meaning. In the same way, a custom interaction should exist because it expresses something the standard behaviour cannot express as well, not because the source file looks more impressive afterward.
Creative coding is most satisfying when the custom behaviour feels inevitable after you experience it. The visitor should not think, 'Someone wrote a lot of JavaScript.' They should think, 'Of course this thing behaves like this.' When the technical effort disappears into a natural interaction, the code has done its creative job.