Last time we spent the whole episode learning to teach -- meeting a nervous beginner where they actually are, handing them a running sketch instead of a blank file, teaching the debugging ritual out loud. And right at the end I told you that the makers you teach don't stay in your workshop. They go looking for others like them. Because there's a whole living world of people who make things with code -- sharing, challenging, and quietly lifting each other -- and finding your place in it changes everything about how you keep going. That's today. This is the episode about the creative coding community: what it actually is, how to find your corner of it, and how to be someone worth having around.
I'll be honest with you, this is the part of the craft that saved me. For my first two years I coded completely alone in Antwerp, convinced everyone else was a genius and I was faking it. Then I wandered into one Discord, posted one ugly sketch, and someone I'd never met left three lines of encouragement and a tip that unstuck me in a night. That was the whole turning point. So this episode is less about clever rendering and more about the shape of a healthy scene, and how you plug yourself into it without being weird about it. Allez, let's go find your people.
Here's the thing nobody tells the newcomer: "the creative coding community" isn't one place you sign up for. It's a whole ecosystem of tools, each with its own crowd, its own culture, its own front door. If you only know p5.js, you think that's the whole world -- but there's a dozen neighbourhoods, and knowing they exist is the first step to finding the one that fits you. So, exactly like everywhere in this series, I start by turning the fog into data:
// the scene isn't one place. it's neighbourhoods, each with its own crowd + vibe.
const ecosystem = {
"p5.js": { lang: "javascript", vibe: "beginners, teaching, web", home: "openprocessing" },
"Processing": { lang: "java", vibe: "the original, sketches, education" },
"openFrameworks":{ lang: "c++", vibe: "installations, performance, speed" },
"three.js": { lang: "javascript", vibe: "3D, webgl, product-y demos" },
"TouchDesigner": { lang: "node-based", vibe: "VJs, live visuals, no typing" },
"Hydra": { lang: "javascript", vibe: "live-coded video, browser, playful" },
"Sonic Pi": { lang: "ruby-ish", vibe: "live-coded music, classrooms" },
};
Look at those vibe fields -- that's the real map. openFrameworks people care about milliseconds because they run museum installations that must not crash; Hydra people are livecoding video at a party at 2am. Neither is better. But when you know a tool has a culture and not just an API, you stop asking "which is the best framework" (a question with no answer) and start asking "which of these rooms do I actually want to hang out in". Pick the neighbourhood by its people, not just its features, and you'll last a lot longer.
Once you know the neighbourhoods exist, you have to physically find the doors. And they're scattered -- Discord servers, the old Processing forum, OpenProcessing's comment threads, a couple of subreddits, Mastodon hashtags, and real-world meetups if you're lucky enough to have one nearby. So I model it like a little lookup: tell me what you make and where you are, and I'll point you at the nearest gathering:
// tell me what you make + where you are, i'll point you at a door.
const gatherings = [
{ name: "p5.js Discord", online: true, for: ["p5.js", "beginners"] },
{ name: "The Coding Train fam", online: true, for: ["p5.js", "learning"] },
{ name: "OpenProcessing", online: true, for: ["p5.js", "Processing", "sharing"] },
{ name: "creative-coding.social (Mastodon)", online: true, for: ["everything"] },
{ name: "your local hackerspace", online: false, city: "Antwerp", for: ["irl", "hardware"] },
];
function doorsFor(interest, wantIRL) {
return gatherings.filter((g) =>
(g.for.includes(interest) || g.for.includes("everything")) &&
(wantIRL ? g.online === false : true)
);
}
Notice I kept an irl option in there, and it's not a throwaway. Online is where you find people, but a real-world meetup -- even a scrappy one in the back of a hackerspace -- is where a loose acquaintance becomes an actual friend who'll collaborate with you later, exactly like the cross-discipline partners we talked about two episodes back. If there's a physical scene within travelling distance, go, even once. And if there isn't one? Hold that thought, because we come back to it at the end.
Now, the most common newcomer mistake, and I made it myself: barging in. You do not walk into a five-year-old community and immediately ask people to fix your code or review your portfolio. You lurk first. You read how they talk, what they celebrate, what's already been asked a hundred times. Then you contribute something small and real. I think of it as an on-ramp with stages you actually climb:
// you don't barge in. you climb an on-ramp, one honest rung at a time.
const onRamp = ["lurk", "react", "reply", "share", "help", "organise"];
function nextStep(current) {
const i = onRamp.indexOf(current);
return i < onRamp.length - 1 ? onRamp[i + 1] : "you're a regular now :-)";
}
console.log(nextStep("lurk")); // -> "react"
console.log(nextStep("reply")); // -> "share"
The order matters. You react to someone's work before you reply, you reply helpfully before you share your own stuff, and you share a good while before you start helping others -- and only much later do you organise anything. Skip rungs and you come across as someone who wants the room's attention without having given it anything. Climb them honestly and, without ever forcing it, one day you realise people know your name. Reputation in a community is just the slow residue of showing up kindly, over and over.
Here's a lovely thing communities invented: shared prompts. The most famous is #genuary -- every January, a daily generative-art prompt that thousands of people all interpret in their own way. It's not a competition. It's a campfire. And it works because a constraint you share with strangers turns a lonely practice into a conversation. Let me model a tiny prompt calendar:
// a shared prompt turns a lonely practice into a conversation. #genuary-style:
const prompts = [
"no straight lines",
"only one colour + the background",
"draw ten thousand of something",
"a rule you must break exactly once",
"make it feel like rain",
];
function promptForDay(day) {
return prompts[(day - 1) % prompts.length];
}
console.log(`Day 3: ${promptForDay(3)}`); // -> Day 3: draw ten thousand of something
The magic isn't the prompt itself, it's that a thousand other people are wrestling with the same one on the same day. You post yours, you scroll theirs, and you see fifty completely diffrent answers to "make it feel like rain" -- and every one teaches you something. This is the same power we found way back in the seed-based and constraint episodes: a boundary doesn't shrink your creativity, it focuses it. A shared boundary just adds company. Do one, even a bad one -- finishing and posting beats a perfect sketch nobody ever sees.
Newcomers think you only post finished, gorgeous work. Total myth, and honestly a harmful one. The posts that build the most connection are the process ones -- the ugly work-in-progress, the happy accident, the "why is it doing THIS" screenshot. People bond over the mess, not the museum piece. So when I share, I attach the story, not just the render:
// the polished render gets a like. the messy process gets you a friend.
function shareUpdate(sketch) {
return {
image: sketch.latestFrame,
caption: sketch.story, // "meant to be smoke, became coral. keeping it."
tags: ["#wip", "#creativecoding", "#p5js"],
invite: "anyone know why it flickers at high particle counts?",
};
}
That invite field is the quiet superpower. Ending a post with a genuine question does two things at once: it might get you an answer, and it tells the room you're a person who's still learning and open -- which is magnetic. A finished piece says "look at me". A process post with a real question says "come think with me", and that second one is how you actually meet people. Nobody ever made a friend by being intimidatingly perfect.
The healthiest thing you can do in any community is answer questions before you start asking them. It flips you, in the room's mind, from a taker to a giver -- and givers get helped fast when they finally do need it, because they've built up goodwill. It's the exact reciprocity we touched on when we talked about teaching last episode, just spread across a whole crowd instead of one learner. I even keep a rough mental ledger:
// give before you take. a healthy member's ledger runs generous.
function ledger(given, taken) {
const ratio = taken === 0 ? Infinity : given / taken;
return {
given, taken, ratio,
health: ratio >= 1 ? "generous, welcome anywhere" : "take a beat, go help someone",
};
}
console.log(ledger(12, 3).health); // -> "generous, welcome anywhere"
Now, don't be weird and literal about counting -- nobody's actually tallying. The point of the ledger is a gut check: if the only times you show up are to ask for something, people notice, even subconsciously. But answering one beginner's "why is my canvas blank?" costs you two minutes and buys you a reputation as someone worth having around. Give first, give often, and the taking sorts itself out when you need it. Generosity is the cheapest investment in the whole scene.
Way back in episode 143 we talked about open source -- putting your work out under a licence so others can build on it. That wasn't just a licensing lesson, it was a community lesson, and this is where it lands. Contributing to someone else's creative-coding library or example is one of the most concrete ways to join a scene. And the best first contribution is almost never code -- it's a good bug report or a docs fix:
// the best first open-source contribution is usually NOT code. it's this.
function goodIssue(bug) {
return {
title: bug.oneLine, // "map() returns NaN when inMin === inMax"
steps: bug.reproSteps, // exact steps, copy-pasteable
expected: bug.whatShouldHappen,
actual: bug.whatActuallyHappens,
version: bug.libVersion, // ALWAYS include this
minimalSketch: bug.smallestCodeThatBreaks, // the smaller, the more it helps
};
}
Look at minimalSketch. A maintainer drowning in vague "it doesn't work" reports will love you forever for a tiny, self-contained sketch that reproduces the bug -- because you've done the hard half of the debugging for them. That's you giving before you take again, just pointed at a codebase instead of a person. Fix a typo in someone's README, file one clean issue, and you've made your first real contribution to the commons. From there, code contributions feel a lot less scary.
Creative coding runs on remix culture -- people fork each other's sketches constantly, and that's healthy, it's how techniques spread. But it only stays healthy if everyone credits generously. When you build on someone's idea, you name them. When someone builds on yours, you feel flattered, not robbed. So I bake the credit right into how I share a remix:
// remix culture only works if credit flows. name your sources, always.
function remix(original, myChanges) {
return {
title: `${original.title} (remix)`,
creditsTo: original.author, // NEVER drop this
basedOn: original.link,
whatIChanged: myChanges, // be honest about your part
license: original.license, // inherit it, respect it
};
}
That creditsTo line is not optional and it's not decoration -- dropping it is the fastest way to get a bad name in a small scene, because everyone recognises everyone's work. But credit given freely does the opposite: the person you credited sees it, feels good, and often boosts your remix to their own followers. Generosity with attribution is quite literally free marketing that also happens to be the right thing to do. Be the kind of ancestor whose work people are proud to build on.
Every healthy community runs on one unwritten rule that's more important than any code of conduct document: assume good faith, and be kinder than strictly necessary. Text has no tone, beginners are fragile, and the person asking the "dumb" question is often one harsh reply away from quitting forever. So before I hit send on any reply, I run it through a little filter in my head:
// text has no tone. run every reply through this before you send it.
function kindEnough(reply) {
const flags = [];
if (/^(just|simply|obviously|everyone knows)/i.test(reply)) flags.push("condescending opener");
if (reply.includes("RTFM") || /google it/i.test(reply)) flags.push("dismissive");
if (!/[?]|try|maybe|here'?s/i.test(reply)) flags.push("no actual help offered");
return { ok: flags.length === 0, fix: flags };
}
console.log(kindEnough("Just read the docs, obviously."));
// -> { ok: false, fix: ["condescending opener", "dismissive", "no actual help offered"] }
Those "obviously" and "just" openers are poison -- they make the reader feel stupid for not already knowing, which is the precise opposite of teaching. Strip them out. A reply that offers one concrete thing to try is worth ten that show off how much you know. Remember, you were a nervous beginner posting an ugly sketch not long ago, and someone was gentle with you. Pay that forward, every single time. A scene is only ever as welcoming as its meanest regular, so don't be that person.
And here's the last idea, the one I want you to actually carry out of this episode. Earlier I told you to go find your local meetup -- but what if there isn't one? For years, there wasn't one near me, and I waited around like a fool for someone else to build the thing I needed. Eventually I understood: you don't need permission to start a corner of the community yourself. It can be tiny:
// no scene near you? the smallest viable community is embarassingly small.
function startSomething() {
return {
what: "a monthly sketch night",
who: "you + 2 friends is enough to begin",
where: "a discord channel, or a cafe table with laptops",
ritual: "everyone shares ONE thing they made, finished or not",
rule: "no gatekeeping, beginners first, snacks encouraged",
};
}
Three people and a shared prompt is a community. That's genuinly all it takes to start. The p5.js scene, #genuary, every big Discord you'll ever join -- each one began as a couple of people who wanted company and decided not to wait. Starting small also quietly makes you the organiser, the last rung on that on-ramp we climbed earlier, and being the person who makes the room is one of the most rewarding things in this whole craft. You don't have to find your people. Sometimes you get to gather them.
So that's the real shape of the community, and you'll notice yet again how little of it was about clever code. The code was the easy half -- an ecosystem map, an on-ramp, a kindness filter. The hard and lovely half is human: being generous with your attention and your credit, being gentle with beginners, and being brave enough to post the ugly thing and say hello. Do that, and you stop being a lone coder grinding in the dark and become part of something that carries you on the days your own motivation runs dry.
And that, actually, is exactly where we go next time. Because a community is wonderful, but it can't make the work for you -- at some point you have to sit down, alone, at your own desk, and keep making things day after day, even when nobody's watching and the muse hasn't shown up. How you build a personal rhythm that survives the boring days, the blank days, the days it all feels pointless -- that's the quiet engine under everything, and it's what we get into next. Merci for reading, and go post something ugly today -- I mean it :-).
Sallukes! Thanks for reading.
X
@femdev