A workflow that's perfectly legible at six nodes can turn into something only its author can follow at twenty — not because the canvas got harder to use, but because the habits that don't matter at small scale start to matter a lot. None of this is exotic advice; it's the same discipline that keeps any growing system readable, applied to a node canvas specifically.
Name every node for its job, immediately
The single highest-leverage habit, and the cheapest. "If: worth posting" tells you what a node does without opening it; "If 3" doesn't, and by the time a workflow has three unlabeled If nodes, reading it requires opening each one just to remember what it checks. Name nodes the moment you add them — retrofitting names onto a finished twenty-node workflow is a much bigger job than doing it as you go.
One workflow, one outcome
The clearest sign a canvas needs splitting isn't a node count — it's whether you can describe what it does in one sentence. "Watches for relevant news and posts a reaction" is one outcome. "Watches for news, posts a reaction, and also checks prices weekly and posts a recap" is two outcomes sharing a canvas, and they should be two workflows: separate triggers, separate schedules, separate points of failure that don't take each other down.
Keep the main path straight; branch late
A canvas reads best when there's one clear line from trigger to publish, with branches (If nodes, multi-template fan-outs) kept as short detours rather than the whole layout forking early and staying forked. Per-platform or per-template variations (see multi-template fan-out) belong right before the nodes that actually need to differ, not duplicated all the way back to the trigger.
Delete what isn't connected
A disconnected node left on the canvas "just in case" is pure liability — it adds visual noise, and months later neither you nor anyone else can tell whether it's dead weight or something load-bearing that got accidentally unplugged. If you're not using it, delete it; a workflow's history is better kept in your own notes than in orphaned nodes.
Document the non-obvious, not the obvious
A node named clearly rarely needs a separate comment — but a genuinely non-obvious choice (why this specific relevance threshold, why this particular polling interval) is worth a note somewhere, because "why did I pick 5%?" is a question your future self will actually ask. The node's own label can't carry that context; somewhere in your own documentation should.
Revisit structure when you add, not just when it hurts
The easiest time to keep a canvas organized is the moment you're adding the node that would otherwise make it messy — pausing to name it properly, deciding whether it belongs in this workflow or a new one, takes seconds now and saves the larger cleanup later. Waiting until a canvas is already hard to read to fix it costs much more than keeping it clean as you build.