Home | Podcast | Cultivating curiosity in creative coding with Matthew Ragan

Cultivating curiosity in creative coding with Matthew Ragan

Cultivating curiosity in creative coding with Matthew Ragan

In this podcast you will learn why curiosity matters more than technical skill.  

In this interview, Matthew Ragan explores coding as a practice of sculpting and rehearsal, showing how collaboration with technology leads to more fluid and sustainable creative outcomes.

Matthew Ragan is a California-based creative technologist, educator, and co-founder of SudoMagic. He has an MFA in interdisciplinary digital media and performance. His TouchDesigner tutorials are used by creatives worldwide.

Listen to this podcast to learn about:

  • Why curiosity and patience matter more than technical skill in creative coding
  • What Matthew Ragan’s circus training revealed about working with technology as a collaborator rather than an obstacle.
  • Why “slow coding” offers a sustainable counterbalance to the culture of instant results.

 

Subscribe using your favourite podcast player or RSS

Subscribe: Apple Podcasts   |  Spotify   |  Amazon Music  |   Android   |   Instagram   |   RSS

Chapters

  • (00:00:00) Introduction and host's acknowledgment
  • (00:00:48) Guest introduction: Matthew Ragan
  • (00:01:15) The importance of curiosity in creative coding
  • (00:02:31) Exploring noise algorithms and sculpting
  • (00:05:08) Lessons from circus performance to coding
  • (00:07:17) Balancing creative and commercial projects
  • (00:09:15) Matthew's journey into coding
  • (00:22:03) Choosing the right tools and languages
  • (00:24:03) Advice for newcomers and final thoughts
  • (00:30:55) Conclusion and call to action

About Matthew Ragan  

Matthew Ragan is a California-based creative technologist, educator, and artist whose work bridges performance and technology. With a background in acting, dance, and circus arts, he brings embodied lessons of rehearsal and collaboration into his creative coding practice. He has shaped a generation of artists through his widely used TouchDesigner tutorials, and professionally he has led large-scale projects at Obscura Digital and the Madison Square Garden Company, including Art on theMart and the MSG Sphere. He is the co-founder of SudoMagic, a boutique software and design studio.

Takeaways from this interview with Matthew Ragan

Curiosity

“The one thing that maintains a lot of your longevity in kind of exploring what it is to be a creative coder, I think. The piece that comes back to me is wanting to stay curious and to cultivate your curiosity in the world, because I think ultimately that’s kind of a foundational piece of what helps you keep pursuing and chasing ideas and trying to create new things, is being curious about the world.”

For Matthew, curiosity is not just a starting point, but a way of sustaining creative energy over time. It is the drive that keeps ideas alive and pushes exploration forward.

Coding as sculpting

“I think… whether it’s noise or whether it’s code in general, the way that you access and think about some of those ideas is working with a form or something that has a set of rules… how do you push that a little bit further one way or pull it closer to you in another way?”

For Matthew, coding is not an abstract or purely intellectual act. It is sculptural, iterative, and performative, more like rehearsal in theatre or dance than engineering.

Working with, not against, technology

“The more you resisted the apparatus, the more it hurt… when I found a way to relax into it… and think about how I’m collaborating with it, those were the moments that changed my relationship.”

From circus training, Matthew learned that resistance to the apparatus creates friction and pain. He applies the same principle to coding: technology becomes a partner when you lean into it rather than fight against it.

Curiosity and patience matter more than skill

“My strange beginnings for code were actually Excel spreadsheets… I was deeply curious about what my sleep trends were. What are my activity trends? ” 

Matthew emphasises that curiosity, not technical expertise, was his entry point. Patience and slow exploration remain central to his creative practice, showing that creative coding is less about raw skill and more about sustained curiosity.

The gift of deadlines

“Sometimes setting a deadline is really about a gift that you’re giving yourself.”

Constraints such as deadlines and frameworks provide focus, preventing endless wandering and allowing curiosity to become productive exploration.

Slow coding

“Coding for me has always been such an endeavour of patience and slow contemplation… the good souffle actually takes the time to craft.” 

Matthew likens coding to cooking: you can’t rush a souffle. In the same way, creative coding needs time to develop flavour, depth, and complexity.

Advice—Focus on Expression, Not Just Tools

“Pick a framework, pick a scripting language, and pick a shading language… then it’s less about how I make the thing work, and more about how I express a particular idea.”

For newcomers, Matthew suggests starting small and focusing on expression rather than tools. His advice reframes learning as cultivating curiosity, not mastering technical detail.

Links from this podcast with Matthew Ragan

Edited transcript of this interview with Matthew Ragan

Curiosity matters more than technical skill

Robin: If a creator could do one thing to improve their skills, what would it be?

Matthew: I love that question. I think the temptation is often to imagine that there is some hard skill — if I only learned to write shaders, that would change the trajectory of my capabilities. If I only were a better programmer, if I only were better at this or that.

Matthew: But the more I think about what maintains your longevity in exploring what it is to be a creative coder, the piece that comes back to me is wanting to stay curious, and to cultivate your curiosity in the world. Ultimately that’s foundational to what helps you keep pursuing and chasing ideas and trying to create new things: being curious about the world.

Matthew: Because when you’re not curious anymore, you stop caring.

Robin: As you were working up to that, I thought you were going to say: be interested in learning. It’s a really nice link between being curious, open, and learning as well. In terms of coding, what’s a good example of being curious?

Matthew: One of the deep wells of curiosity for me that I chased for a long time was noise and noise algorithms. It’s a funny thing to think about what we imagine is random in the world, and the places that pops up. Suddenly that becomes the look of a star field, or the texture of gravel, or grass, or wood grain.

Matthew: I had a friend who was a sound artist, and he used to talk about practitioners who would start with an objective. They’d think about the sound of rustling leaves, and their whole creative exercise was: how do I start with some original noise — pink noise, brown noise, whatever it is — and sculpt that into being this thing that we know and recognise?

Matthew: For me, that’s an example: you take this idea of things that appear random or pseudo-random, and you think about shaping and sculpting that — making something interesting and familiar out of what we think of as chaotic.

Coding as sculpting, not just problem solving

Robin: One of the things I keep being struck by with those noise algorithms is the rich set of generative possibilities that come from them as well. And it’s nice because they’re not always trying to do things that are natural either. Now, I was keen to explore the word ‘sculpting’. Why did you use that?

Matthew: I think sculpting is — it’s funny. My background… I feel like I’ve been a hundred different people sometimes. But as an actor, a dancer, a circus performer once upon a time, a lot of times we start with original material. You start with a script. You start with a score or a movement, and you have to think about how do you influence that, or make some accented shape out of the material that you’re working with.

Matthew: For me, whether it’s noise or code in general, the way that you access and think about some of those ideas is working with a form — something that has a set of rules or conventions — and then thinking: how do you push that a little bit further one way, or pull it closer to you another way? How do you squeeze on it here, or stretch it there?

Matthew: The idea is not just experiencing it, but thinking about how you’re engaged in an interaction, or play, or a dynamic with the material that you’re exploring.

Robin: So it becomes less like an intellectual exercise. It’s a push-pull thing — that’s a really nice way of thinking about it, because it becomes physical.

Working with technology instead of fighting it

Matthew: Yeah, absolutely. As a circus performer, I worked on a bunch of different apparatus, and one of the biggest lessons I took away was: the more you resisted the apparatus, the more it hurt. Whether that’s trapeze or aerial fabric — any number of things — your resistance or confrontation with the apparatus is when you got a rug burn, or you banged your shins, or got bruises.

Matthew: But when I found a way to relax into, or soften into, the apparatus and figure out: where is it creating resistance? Where is it providing support? How do I invert my ideas of resisting this contraption and instead think about how I’m collaborating with it?

Matthew: Those were the moments that changed my relationship to the work I was doing. And I try to pull the same idea along with me when working with code — rather than imagining I have to fight and resist and bang my head against a problem until I solve it. Sometimes we fall into that trap, especially when we’re coding. Instead, it’s: how can I lean into the thing that’s frustrating me in this moment, and take advantage of it if I can?

Robin: That’s one of my personal behaviours that I have to keep catching myself with. I get set on a particular way of doing something, or there’s a problem, and I sit there thinking I have to solve it to get to that point. Then hours later — when I probably should have taken multiple breaks — I eventually go: ‘Oh, this isn’t really that important.’

Matthew: It’s funny, right? We’re confronted with this thing that’s not working, and all of a sudden we have this compulsion: I have to figure out why it’s not working. Rather than taking a moment to say: huh — why isn’t that working?

Robin: Is it important that it’s not working?

Matthew: Yeah.

Robin: How do you know when to stop that process, Matthew?

Matthew: Isn’t that the million-dollar question? It depends for me on whether the project is a purely creative endeavour, or whether it has some commercial component. Is it part of a job or a gig?

Matthew: At the end of the day, a hard lesson I try to hold onto is this: plant a flag — a measure of when you need to take a break. If I’ve fought with this for 30 minutes, maybe I should go get a cup of coffee and breathe for a moment.

Robin: One of the nice things about commissions and professional work is that moment of ‘I thought this was only going to take a day — I’m on day two — this isn’t going to work well for being able to eat and pay rent.’ So it’s a nice constraint sometimes. But we don’t always have that when we’re doing our own creative work.

Matthew: Yeah.

Robin: It’s funny — I’ve been asked a similar question multiple times: how do you know when something’s resolved, or when it’s finished? I normally turn around and go: ‘I don’t — but I have a deadline.’

Matthew: Absolutely. I was just giving a talk the other day to a group of students working on some TouchDesigner projects, and we were talking about exploring creative endeavours. One of the pieces I was talking about was that sometimes setting a deadline is really about a gift you’re giving yourself.

Matthew: You’re imposing a constraint, because when we’re working with blank pages it’s easy to get lost exploring forever. When we have a constraint, it matters.

Robin: I wasn’t planning on asking this, but I’m really interested in your move from performance into installations and coding. How did you learn to code?

Matthew: One line at a time — slowly and in agony, is how it felt.

Matthew: My strange beginnings for code were actually Excel spreadsheets. I had a stretch of life, in the circus part of my adventure, where I was really interested in tracking the metrics of my life. I was deeply curious: what are my sleep trends? What are my activity trends? What are my consumption trends?

Matthew: So I built these complex forms and spreadsheets to ingest that data. Then I found myself asking: how do I run analysis on these data sets, turn it into graphs, understand trends?

Matthew: That’s my entry point. Learning how to code was a strange journey for me. I never had the mental image of myself as a computer programmer or developer — that seemed foreign. But I was curious about how to make sense of information around me.

Matthew: My entry point was deep introspection and curiosity about my own metrics and biometrics: how much was I sleeping, consuming, working out, travelling? Those things found their way into a spreadsheet, which became: I’ve got to write the formulas to parse this information and make sense of it.

Matthew: Then: I need to identify trends. Then: I’ve got a bunch of noise — I need to filter out the noise from the signal. That opened questions about what other invisible things exist in the world — especially as performers, always navigating and experiencing things — and how do we use technology in a performance capacity to help create some dialogue between me, the performer, and all of these invisible things that are around us all the time.

Matthew: So I started with Excel and then found my way to Isadora and Quartz Composer, and then Processing, and then TouchDesigner and then Python, and you know, then it’s a slippery slope.

Robin: Yeah. Okay. So that’s a bit, trying to go back a couple of things. So it was almost like the I, I think a coding is two things. Thinking in rules and thinking about data. You actually started with thinking about data and observing data before you then sat there and went, oh, I need to think about the rules.

Matthew: Exactly. I’ve never been particularly good at doing things in the order that you’re supposed to do things in. You know, I find the hardest way to confront a problem, and that’s usually my entry, I,

Robin: probably not a bad entry point because in some ways that means the really hard build of learning experience first.

Matthew: uh, exactly.

Robin: If you were doing that again, how would you change that sort of process?

Matthew: I think I’ve been thinking a lot about what, you know, what is code and how do we think about code. I think a lot of times, because you know, I had this kind of like notion, I wasn’t a particularly a very good math student. Like I was not particularly gifted in the, in respect to like thinking about mathematics conceptually, that always felt like it was really something that I wrestled with.

Matthew: And I think, you know, in hindsight, I think it was really more about the abstract construction of math that was often hard for me, but in context it’s often quite interesting. Right. In the context of working with a data set or working with some information. So I think I would probably encourage myself to first imagine that any problem or any curiosity that we have exists inside of a context.

Matthew: And then to also tell my younger self that coding is, ultimately, I think in many ways a kind of act of authorship and writing. It’s really about kind of understanding a scene that’s in front of you and understanding who the actors in that scene are and what the rules they’re gonna abide by will be, and how they’re going to interact. And I think if I thought of it less as a kind of computer science, ‘you have to understand calculus to be good at this’ kind of frame initially, I would’ve approached it, I think, differently.

Robin: And that’s also one of the differences between a lot of these creative coding tools. And some people don’t even call them coding because of the fact that they actually visual programming languages. And you sort of work with building up things in a sort of more tactical ways when you are working with something that’s actually purely language based. But the thing that you still do need that computational style thinking that you’re talking about with those tools as.

Matthew: Absolutely. I feel like, you know, it’s so funny, in some ways I thought that, you know, working with any kinda node-based environment, that I initially really resisted the notion of integrating work with that kind of traditional language and programming language rather. And the longer I’ve gone along, I feel like more of my work has shifted into the programming language side of it and leveraging the node-based environment more sparingly.

Matthew: So it’s like been a kind of interesting reversal where the formality and the structure of a kind of coding language enforces some rules that then make it a little more fun to work in the other space. Where before I kind of, you know, imagined that it was the other way around.

Robin: So basically heard someone talk about the fact that they were, had stopped doing reactive work because they were just actually sick of the coding parts of it always running late. And that was both when they were coding, and this particular person came from the engineering background into the arts or when they were working with other coders as well. I’ve seen this multiple times in multiple different spots. Is there a way we can solve that problem?

Matthew: Huh. Well, you know, I think one lesson that for me, and maybe this comes from having a background in music and in dance, is that you take for granted that you spend more time at the ballet bar than you do working on the piece for any performance that you’re doing. The fundamentals are the place where you kind of experience and return time and time again to the kind of fundamental pieces that you have to work on and the essentials.

Matthew: And I think sometimes we get kind of lost in creative coding projects where we kind of get swallowed by the fun, creative part, and forget that we really need to do some of the other strategic planning and organisation and project management work because that enables us to understand the amount of time that we have available to us for the fun things that we wanna do.

Matthew: So for me, the strategy that I’ve found myself using is to work backwards from deadlines and then be dominated by my calendar. Even if I’m frustrated by that in many circumstances, thinking about time as a resource that I can use as my exploratory space, that’s also constrained by the deadline that I have to meet, for me has helped ensure that the creative and pure exploration has to fit within getting the thing actually done for someone to see it.

Robin: Actually this is also an interesting thing around performance, actually, ’cause essentially theatre and performance has quite a very structured way of actually going around the opening ideas, collaborating rehearsals, and then the actual event. Compared to say, extra visual artists don’t have that type of structure around what they’re doing.

Robin: It was even in another interview recently, the two people, both visual artists, but they worked with a theatre company and they talked about sort of working through the ideas as workshops where they sat there and went into the workshop doing a whole, we wanna explore this or we wanna explore that. And it was. Yeah, I hadn’t really heard visual artists talk about that sort of process before.

Matthew: Oh, that’s so interesting. I love that because I think that, right, like the rehearsal was always a place where someone got to see the work that you were doing. And I think especially for interactive works, like it’s very important that you have people play, test, and interact with it and you get that feedback and response from people that are using it, rather than waiting until it’s open and being like, how would we have known that this wasn’t gonna work?

Robin: This is probably a question that could be a whole interview. How’s AI changing the way you code?

Matthew: That’s such a great question. You know, I find myself resistant in many capacities, but I think also curious still in some. I find that I’m not as interested in the kind of pure vibe coding exercise that some people have found themselves using, where they’re kind of writing the strict rules of adherence for the application that they wanna build and then getting back a result.

Matthew: But I do find myself doing things like looking for different methodologies for understanding a particular problem or especially lately, how do I move between domains? I understand how this works in Python, but how does this particular idea work in, you know, Go or Dart or you name it?

Matthew: And so I think LLMs are particularly good in that respect, in helping you kind of do some of that cross language transformation that is otherwise a bit of a slog in terms of a tutorial here and a lot of documentation there. Like, I really wanna understand the pattern and having some way to see that is often really powerful for me, in a kind of coding practice.

Robin: Yeah. Okay. So that’s sort of like that moment where it’s very much a conceptual coach around ideas rather than actually trying to get it to actually write code.

Matthew: You know, it’s fun. I think partially also, I think about the projects I’ve looked back at, that I’ve written, you know, and I come back to it two years later, three years later, I’m like, what joker wrote this thing? And like, oh, I wrote it. And like there is a part of me that’s a little more concerned about returning to something that’s entirely generated two years from now, or three years from now being like, wow, my memory palace is entirely empty for any of the constructions that got me here.

Matthew: Like, I don’t even know where to get, I guess I should burn it down and start over. And those are always the scariest projects where you’re starting from a brand new foundation.

Robin: When you’re starting to code, do you actually have templates or is it like a blank page every time?

Matthew: I don’t have too much boiler. Well, it depends. I suppose there are some frameworks that we’ve used where we start with some, you know, kind of initial template, or work within a kind of component library that has some definitions. I would say inside of the context, a lot of the Python code that I write, I mostly start from a blank page each time.

Matthew: Although it, you know, it also depends. There’s, in our kind of internal practice, whenever we’re starting a new commercial project, we have an established framework and architecture that acts as our kind of boilerplate starting point that we then build on top of, that we kind of maintain as our initial kind of reference template for what a project is gonna look like.

Matthew: So, I suppose it’s in some respects, a little bit of a and a little bit of b — where it’s not entirely from scratch every time, but it does feel like it in some occasions.

Robin: Yeah, because I, it’s one of the things that’s made my life a whole lot easier is basically sitting there going, I’m using this type of pattern. And it came up. That means that I can open a patch from a couple years ago and go, okay, I know what the logic is here, of the architecture more than anything. But the same time, there’s some projects where I just start with key.

Matthew: Yeah, we, it’s so funny, like I just recently have thrown myself into an effort to try and better define what is the structure of a project look like. So it can be described as a transferable collection of definitions.

Matthew: And it’s so funny, I looked back at the repo and I was like, oh, I started this endeavour actually a year ago and then promptly put it down for about 11 months, before being able to pick it back up and think about it a little bit differently.

Matthew: And it’s funny sometimes how there’s, I feel like I go in waves of wanting to have highly structured and consistent foundations to build from. And then wanting, you know, at the same time to say, no, I’d rather, I want to start from scratch and I don’t want to conform to any of my existing ideas.

Robin: choice of language you were working with this moment? Did you make that choice or did you just fall into that, into using Python? Because that was what was working with other things.

Matthew: I fell into working with Python initially because it was what worked with TouchDesigner. And that in many respects it kind of became a gateway for me. So I’ve used Python for a lot of different scripting solutions. These days we’re using a fair bit of Dart inside of our projects. A kind of combination of Dart as the language and then Flutter is the kind of front end piece of that.

Matthew: We’ve done a bit of TypeScript here and there, and then strangely Go is a language that we’ve kind of fallen into for a number of internal tools and kind of low level applications that we work with.

Matthew: So, you know, I think that a gift that one of my professors in college gave to me, working with media servers for live performance was, you know, he used to ask me like, okay, well, you know, which is the application you’re gonna use for this show? And that inevitably led to a kind of question like, okay, what are the needs for this production? And let’s balance the needs of the production against the budget that’s available, and we’ll pick the right tool for the right job.

Matthew: And these days, I try to pick the right coding language that’s gonna fit the requirements of a project. Even if, you know, the go-to tool that I always pick up is maybe not the right one. I try to be a little more critical about like, hmm, what are the actual requirements here and how do we pick the right tool? It fits the shape of this particular kind of creative exercise.

Robin: Huh. I’m personally gonna have to think about that one a little bit, Matthew, because I think I’m probably in the spot where I always think to try to fit everything into an existing set of tools is probably the best way to put it.

Matthew: Well, you know, it reminds me, I think about a, someone told me once, like, what’s the right camera and the right camera to use is the one that you have.

Robin: Is there something else that you feel like we haven’t talked about that you would like to talk about?

Matthew: Hmm. That’s a good, gosh, I love that question. And it’s so interesting. I feel like we’re, we’ve talked a lot about like what it is to be inside of this, like, you know, contraption that is creative coding and I. I don’t know. I think one of the things that I worry about or I think about a lot is how newcomers to this discipline are going to navigate this experience.

Matthew: I’m curious what you think there as well, because it, I remember the kind of uphill slog of learning and exploring and understanding tools and kind of getting my bearings. And these days it feels like the spread of information is so much broader than it used to be.

Matthew: My curiosity for you, just as a conversation is what you think about it, what you think it’s like for newcomers in this space. Because I think about the challenge of kind of getting your footing as a creative coder, and beginning to understand things and now it just feels like there’s so many tutorials that push you in so many different directions and so many frameworks to choose from and this, that and the other.

Matthew: I don’t know. I wonder what it is to be beginning in this field these days, and if it’s exciting or intimidating or, I don’t know. Do you have any sense of how people are feeling in the conversations you’ve had?

Robin: I sit there and feel like people do. The confusion is probably the best way I think about it. And I mean, I’m a little bit like you as well. If I unpack how I learned how to code, it was non-linear. Partly forced clicks when I would start to work more with visual and node based things.

Robin: That was to do with data visualisation, not to do with creative work so much. And I think some people sit there and do a whole, oh, it’s too hard to contemplate is maybe the best way to think about it.

Robin: I have tried to teach coding at different times. I’ve never been particularly successful with that. I think I’ve always confused people because I don’t think I’ve had the depth of understanding to be able to give that.

Matthew: I was just so curious to me because I think about how coding for me has always been such an endeavour of patience and kind of slow contemplation. I think that like, I don’t know, I think about it sometimes the same way I think about cooking, that you have a set of ingredients and it’s gonna take time to assemble all of them.

Matthew: And as much as you wish you could just kinda like, you know, throw it all in the microwave and you would have a perfect souffle. Like the good souffle actually takes the time to craft and work with it. And it’s, I don’t know. I think it’s just really, it’s interesting to see how much the world is gravitating towards kind of instantaneous results instead of slowly cultivated and crafted things.

Matthew: And I don’t know, it just leaves me wondering what this field will look like, you know, in five years or 10 years, or if there’ll be a resurgence if people will come back to it and say, oh, actually. Just like there was a slow cooking movement. That will be a slow coding movement of kind of like, no, we make, we write all of our functions by hand ourselves.

Robin: Picking up on that slowness. There was a really early interview with Steph Lee and he basically did a whole, oh, my own creative practice. I got my professional practice doing work for other people in my own practice. I code everything in. Slowly in complicated things because my time thing’s different means I’ve got two, literally two different head spaces between the types of work as well.

Robin: I think of it as, that’s probably a good example of where he’s maybe doing slow coding, complicating coding by choice. also the other things, a newbie is the, this is. Thing about, you go into a piece of software and you feel like you wanna learn how to use touch designer, but that’s not gonna get you very far.

Robin: Because you need this embedding of what we’ve been talking about around rules and data driven approaches. As like the core foundations and then also you need the whole thinking the way this particular thing works as well.

Robin: And I know when I went back to doing interactive work. It was like I started with processing. I was very familiar with those types of languages. And then I went, okay, I need to explore using max more because of the audio stuff’s not working the way it was processing, and I just. I’ve just found Max impenetrable to my way of thinking.

Robin: And it wasn’t once I sort of had a spot where someone had shown me and talked a lot about thinking in that node base way that it all started to click.

Matthew: Yeah, that’s so interesting. I often think about the fact that, I don’t know, as a younger person, I imagined that the rules that governed any of the software that we interacted with had, I don’t know. Were governed in some, you know, abstract way by a form of logic or ideology that was unopinionated.

Matthew: And more and more it’s interesting to think about. Every piece of software that you interact with has a very distinct opinion about the world, about the data that it interacts with, about how you ought to interact with it.

Matthew: And it’s funny to think about the fact that those opinions and perspectives of the people that have contributed to the tools that we interact with, find their ways, you know, all the way out to us, even if it’s, you know, many steps removed.

Robin: Yeah, and that’s, it’s especially these sorts of node based patching. There’s a strong philosophy around data coming in. Some manipulation and then the generation of things at the end, and there’s a bit in the middle around the logic and rules that are very uncomfortable and sometimes challenging to achieve in those environments compared to the mapping approach that they lend themselves to very easily.

Matthew: Yeah.

Robin: Yeah, actually, yeah. I hope for the future would possibly be the having better tools for working with the core rules or something.

Matthew: Mm-hmm.

Advice for beginners: focus on expression, not tools

Robin: I’m going back to my standard wrap up question Matthew. What’s your greatest piece of advice to creators about coding?

Matthew: You know, I think my, the greatest piece of advice that I could offer is that there’s no one or right tool that’s gonna solve this particular problem for you of finding your way into kind of creating work.

Matthew: I used to tell people, pick a framework, whether that’s Max or a touch center, or Unity, or Unreal Engine, whatever it is. Learn how that environment thinks about the kind of work that you wanna do, and pick a scripting language. Hopefully that’s compatible with that environment because you’ll need to write some code and then pick a shading language because. If you understand or have those tools at your disposal, then it’s really about, it’s less about how do I make the thing work, and more about how do I express a particular idea or concept and the kind of cultivation of that curiosity about what you wanna express and think about.

Matthew: It’s really the most interesting thing that you can continue to feed. Because a tool you can learn, and to remind yourself that any of those things are ultimately kind of constructions and ideas that are really just about meeting your expressive interests.

Posted 27-09-2025