I'm Sander Sturing, a creative coder at Studio Dumbar for almost nine years. I've been a creative coder for about five of those years. I mostly create custom tools and small pieces of software for designers, including visual designers and motion designers. I also do a bit of generative design, mostly using Processing, Drawbot, Python, and, increasingly, software like Cavalry and TouchDesigner.

It actually came back into my life when I was at Studio Dumbar. I graduated almost 14 years ago, mainly doing creative coding—almost everything in Processing. I studied at an art academy, but it was a new course focused on information design, such as data visualizations and interactive installations. I learned a lot of coding, but no one was looking for a coder, so I started making websites at design agencies. That's how I joined Studio Dumbar, designing and building websites.

After a while, the studio became more interested in using motion for identities and other projects, moving away from static designs. We quickly found the limits of what we could do with software and our skills, especially sketching different variations quickly since motion takes more time to set up. About five or six years ago, I started coding again. Our first project was Amsterdam Sinfonietta. From there, I stopped making websites and became a full-time creative coder. It's so great and fun.

I did bits and pieces of coding here and there in my previous job, but never as my main thing. I kept up with it for fun on the side, but I never thought it could be an actual job, especially not in a design studio doing big design projects. It never occurred to me ten years ago that it could be my job. It happened naturally, and here we are.

There's not a clear division between my personal work and what I do in the studio. The type of work I do for myself is closely related to my studio work, which I'm happy about because I love working in a studio. I appreciate that I can work there that aligns with my interests. I'm more technical than a designer, even though I attended an art academy and work in design. I'm more interested in making things work technically and coming up with smart solutions.

This is why most of my personal work involves collaborating with a designer or someone else. I prefer having someone handle the visual aspects while I focus on the technical and creative parts. We can bounce ideas off each other and create hybrid designs. This approach is consistent in both my studio and personal work.

I don't do a lot of crazy visuals. I prefer creating something that doesn't feel obviously coded. It should have a clear structure and appear well-thought-out rather than looking experimental or random. I like using code to achieve this because it allows me to make quick iterations, variations, and tests within the visual setup. I'm not into unexpected results from code; I prefer having control over the outcome. Once I have that control, I might experiment with unusual numbers or inputs to see what I can achieve, but I always start with a clear goal in mind.

That's what set us apart a bit when we started. I truly believe in using coding in a design agency, not just to make something you can only create with code. Often, it's more about setting up tools that allow designers to quickly create different iterations and variations. They can try out different things, change numbers and inputs, and get immediate outcomes, allowing them to sketch faster.

Many visual outcomes could be made with other software like After Effects, but it takes longer and requires a clear end result in mind. This often means missing out on unexpected results, which I actually like when designers find them. I prefer giving designers the opportunity to explore quickly.

When I started working with designers to create tools, they often had a visual or creative idea in mind. They might have a sketch illustrating what they want. Most of the time, their question is, "Can you automate this so I can create many different variations?" They know it looks good but want to try it in 100 different versions.

People often think this takes a lot of time or is almost impossible to do. What I like to do is make quick sketches, which is why I enjoy Processing and calling these things sketches. I try to give them to the designers as quickly as possible. Sometimes, it's just me coding and giving it to them to experiment with. We're both working with the tool from different angles. I'm trying to make it technically better and think, "Hey, if we have this, I can also combine it with this or connect it to this part." Meanwhile, they start experimenting. Because I give them a quick version, they run into problems quickly, which is good. If you know where you run into a problem, you know what area you need to improve or build upon.

This back-and-forth process is crucial. They might ask, "Hey, can you also add this?" I build that in and experiment further. That's how most of the tools we create in the studio come to life. They get a version from me after an hour of coding, and it can turn into something big. I need their input while building it to understand what they're looking for. They often push it in a direction I didn't expect. I might write a code with a certain idea in mind, but they do something else with it, leading to interesting results. We continue from there.

That's why I strongly believe my work is much better when I collaborate with someone else. Otherwise, I have to come up with the idea and code it, and it never expands into new areas. You end up making your tool do just the one thing you had in mind. I believe in giving them the code as quickly as possible. Most of the time, I give them an opportunity to work with image input. Even if they just use a black-and-white image or video, they can quickly design and get a nice outcome. I use this approach a lot. We go from there.

Yeah. So, I think I like to be surprised by the visual outcome, but when I write my code, I'm very strict about what I think it should do. I always say that code is the most direct way of talking to the computer. If you have a piece of software or something, there's always someone else who already made some choices about what you can do, as the slider ranges from this number to that number. Someone thought about how you interact with the computer or how you tell it to do something. This is valuable and speeds up many things, but it also takes away the directness of me just telling the computer, "Hey, do this."

In that part of the process, I like to be super strict and have full control over how I set things up. I want to understand everything that's happening. I compare it to generating a world or environment that has my rules in it. Within those rules, everything can happen. If something doesn't fit, I have to change my rules. Within that world, designers can play, find unexpected things, or grow in certain areas. They can loosen or tighten the rules, and we build this together.

There are two aspects to it. One is visual. We do a lot of type in the studio. The studio has been around for 40, 45 years, almost 50 now. It's something we are known for, and it's kind of in our design DNA. We like to work with bold type. We also work a lot with identity, so type is always involved.

It’s interesting that working with type in coding can be quite difficult. For example, Processing, the go-to tool for creative coding, works really poorly with type. You can't load variable types, and it's quite hard to add to. I do a lot of that stuff in DrawBot in Python, but it's a bit too technical for me sometimes.

What's interesting about working in a studio is that often, the concept, idea, and visual come first. Otherwise, we might be a little limited. We just have to come up with the idea of how we want something to look.

And then we find the best way to do it. It's never just, "Oh, we're going to code something." Sometimes, we start coding, but halfway through, we realize it's better done in Cinema4D or After Effects. Then, we switch to that method. That's the luxury of working in a studio with talented people doing different things. They can always keep the visual idea central and use the best approach.

Sometimes, we sketch the same idea from three different angles. Each angle has its own benefits, interesting results, or unexpected outcomes, and we pick the best one. Working with type in code is often hard to control. The studio's style is usually experimental and graphic, like D&AD, which is super typographic and has a clear grid. Coding often involves creating complex particle clouds or technical-looking designs.

The studio's style is usually graphic, bold, and uses only two colors. For D&AD, we found it quicker and better to sketch in Outforce and then work with code. We create a tool to generate the designs for us, leading to interesting outcomes. We have to work with type because that's how we design, and we just find the best way to achieve our vision. Sometimes it's with code, and sometimes it's not.

Definitely. One thing I'm constantly working on is writing code for other people. This changes how I write code because I need full control and understanding of what's going on. If someone wants to change something, I have to know where that is and make it clear for those with less coding experience. It's not just about the code itself; it's also about explaining how it works.

Explaining the steps the code takes to achieve the visual result is super important. This helps in communicating with designers so they understand how the code interprets their image and the steps it takes.

Often, I try to mimic the steps designers use to create a design. For example, first, we do this, then we take this shape and turn it into something new. By taking the same iterations, my code becomes more legible. It's not just about the code being readable but also about the steps it takes to be well-defined and clear. Instead of using shortcuts, my code is much cleaner and more explainable. This is a big issue, but it's mostly because I work with other people using it.

I use both. I'm absolutely in love with Copilot because it always seems to know what I'm doing. I use it to take care of repetitive tasks. I never ask questions to Copilot. For me, it's like, "Oh, I made one function that works for the left side, and now I need something similar on the right side." I just type a comment, and it knows what the code should be. I only need to rewrite it and change the variable names and numbers. That's super helpful.

I use ChatGPT in a broader sense. When I start coding something, I use it more like a brainstorming tool. I ask it to create a certain function or make something work, and we go back and forth. I then use that as a template or boilerplate to start writing my own code. Both tools are super functional for me.

I prefer having full control, as it's the most direct way of interacting with a computer. AI often does the thinking for you, which is almost the opposite of what I want. I use AI in a very functional way, replacing Google with large language models.

Yeah, it's something I think about a lot. When the activity first came out, everyone was joking, "Oh, I can also code." There were many posts with people asking, "Hey, can you make my website?" For now, it feels like it kind of replaces Google. We always joked that if you're a web developer, you're just really good at Googling things. It was true; no one remembered everything you had to type; you just knew what to find and where to put it. That hasn't changed. You can ask it to do a lot of things, but you still need to know what to ask. You need to know, "Hey, I want this function to work like this, and I want to include this." That knowledge can't easily be replaced, I think.

On the other hand, in 10 years, I don't think I'll write code anymore. This has more to do with software like Careful or TouchDesigner, especially Careful, where we now do a lot of motion. I do a lot of the motion that I used to code in Careful because it uses the same thinking methods. Also, with software like Blender Geometry Nodes, I think there's a shift towards node-based software.

Cavalry doesn't have the user interface of node-based software, but it operates similarly by connecting little blocks. For me, it's the same thought process and steps as in coding. I know how to break down a task into small steps, complete those steps, connect them, and reach the end goal. I believe this type of software will replace much of the coding we currently do, especially when integrated with AI. You could ask AI to create a specific block and insert it into your node-based design software, making the process more efficient.

I think in a few years, I won't need to code as much. I also teach coding, and I often say that actually writing the code is only about 10% of the job. The rest involves knowing what to search for, how to connect various parts, and how to break down a big problem into smaller steps. Recognizing opportunities and possibilities is crucial.

I teach in Germany at a university. It's a small design part of a school that's usually more focused on engineering, called Hochschule Reinwald. Teaching helps me a lot because students have similar questions, which I can incorporate into activities. This process can replace about 10-20% of my work. The remaining 80% involves understanding how to divide tasks, connect parts, and explore possibilities.

The fun part of coding is knowing what can be changed and how to interact with it. This dynamic aspect is crucial. Node-based software with AI and large language models will take over some of the routine tasks, giving me more time to be creative and explore new opportunities.

That's a good question. For me, Cavalry comes close to what I envision. It feels like actual software, but there's a lot of coding involved. You can write your own notes, but it's more about knowing what to connect to what you put. I want software that offers the best of both worlds. It should feel like actual software with a timeline and interactive elements but also give you full control.

Basically, my ideal software would have a node-based design tool where you can easily create your own nodes and mix them with pre-made ones. They are starting to touch on that with geometry nodes, but there's still a lot to learn about how nodes work. Often, the output isn't immediately usable, and you must convert it into something else to use it. I would like to have the best of both worlds. That's my dream.