A while back I went on Jared Norman’s excellent Dead Code podcast to talk about my riffing process for intentional durable software design.

Essentially learning riffing helps you more easily figure out the names, responsibilities & relationships for objects in your system. So you can ship better code while maintaining your velocity for the long haul.

You can listen to the episode here, or you can read online for the full transcript. Here’s an excerpt.

Welcome to Dead Code. I’m Jared. And today we are joined by Kasper Timm Hansen, former member of Rails Core, been doing Ruby and Rails stuff for ages. And I wanted to talk to him about the idea of riffing. Let’s get into it.

Kasper, welcome to the podcast.

KASPER: Hi, Jared.

JARED: Could you introduce yourself to our audience?

KASPER: Sure, yeah. I’m Kasper. I’ve been in Ruby and Rails for a long time. I used to be on the Rails Core team. I had some stints at different companies. And these days, I’m doing more consulting. I’ve just joined a co-op where we’re focused on, like, next-gen dev tools and some open-source stuff, and then blending that with retainers, essentially, for our expertise.

We’ve got, you know, [inaudible 01:09] the member of the Rails Core team, and there’s our Bundler Core team, and rbenv, and stuff like that. So, that’s kind of what we’re focusing on; something kind of new and different. We’ll see how it goes, but I’m kind of excited about it. We’ll see, you know, what it turns into and all that stuff. But yeah, spinel.coop if you want to learn more about that.

JARED: Yeah, yeah. I’ll make sure a link is down in the show notes for that.

So, I’ve been talking with a few different people about sort of the nitty-gritty of how we write code and what processes and mindsets and those kinds of things that we use. And I was talking about that on my newsletter, and you brought up the idea of riffing. Could you tell me sort of where that idea of riffing came from?

KASPER: Yeah, for sure. So, it’s taken a number of different steps. It’s progressively evolved a little bit. Originally, I called it product-focused Ruby all the way back in 2022, but I wasn’t really aware of what it could be yet in a way. I didn’t have a lot of language. I just sort of had found this specific technique where…maybe I should start by telling what that is because it’s kind of strange, in a way, whenever I talk about this because it’s kind of two things mixed in as one. It’s, like, both are fairly simple techniques, but then there’s a huge level of ramifications to doing that change.

And the change essentially is, in your software process, you open up a scratch file, and then you use Ruby or pseudo-Ruby to kind of go into a dialogue with the problem you’re working on. So, typically, you’d have something like a prompt that you’d work on, like, four or five lines that you’d just paste in on top like comments in, like, a Ruby file. And you’d start talking it out with the code itself, kind of, and you don’t necessarily execute that file, which is kind of the strange part about it.

And so, what happened was that I was working in this product company, and we’d get a new feature, or whatever. And then at the start of it, I’d feel really overwhelmed. I didn’t know where to start. There’s all this stuff we need to figure out. How do I tackle that? And then towards the end of a feature cycle, it would be like, I’d have a lot of anxiety. Like, did I think about the right things? What about all this stuff I need to think about? Did I cover that well? So, then towards the end of a feature cycle, I’d have a lot of anxiety around, what did I do? Sort of rename this stuff now, but it’s too late now. I can’t change it. So, it’d be a lot of, like, lack of stamina to maybe fix things. So, I’d ship a design that I wasn’t as happy about.

And so, what happened one day was just I opened up that scratch file and then started tossing ideas in there. And then you toss something out, try to refine it, figure it out already. Oh, I can see that this actually doesn’t work, so I don’t need to go all the way to full implementation because I kind of see from the Ruby or the pseudo itself it is not going to work.

Or, you know, the thing I’m working on, it might have a has_many relationship. Well, I remember it from when it was post has_many comments. So, I kind of already know something about that. So, I’m both trying to map my existing knowledge to this new problem I’m working on and sort of using them in conjunction. So, I’m already starting to get cerebral with what happens with this stuff because it’s…so that’s the technique itself.

But then over time, it’s also shifted to include this kind of methodology around it of, like, how are you actually being creative with this stuff? How are you including more creativity into your product development flow, and how does that change your perspective? And you’re also putting your own process into this process of like, could I have solved this differently? Or partly, what it is you’re trying to do when you’re riffing and getting a feel for that, it has a particular flow to it, is you’re kind of seeking at the edge of your understanding all the time because that’s kind of what you want. Sometimes I like to call it, like, having an insights-per-minute bar.

At some point, you figure out where that kind of is, and if it drops below, you’re usually like, oh, maybe I need to make a change so I gain more insight. So, it’s like another clue to see where you’re at in this process, and how do you navigate this creative space? Because it’s kind of difficult [laughs] to do, which is partly the interesting about tying all this specific stuff to this general-purpose thing and then sort of back and forth.

So, another tool, a mental tool, I’ve kind of used to explain this is also a difference between, or, like, this marriage of both the top-down design and then also this bottom-up feedback. So, what you are just trying to do is both trying to develop an idea for how should this feature, say, be implemented, and then you’re using the writing you’re doing in that scratch file. We’re trying to stick to actual Ruby that you could execute.

But if you can’t do that, you can just do a half measure or whatever, like, I think it’s going to work like this. And then you can refine it a little bit over time to see whether or not you’re on track. And if that doesn’t work, you can backtrack again. And so, you keep doing that seeking at the edge of what you know right now. And then you’re using the feedback from the code you’re already sort of pitching to see whether or not this is even going to work.

And, in your case, you can find where it’s like, oh, I can see this is actually not going to work. I have a wrong understanding. So, you get that feedback kind of fast, which is kind of nuts, in a way, because you don’t necessarily execute the code [laughs]. And so, when I first started doing this, I was like, well, clearly, this is wrong. Like, I’m not doing what I’m supposed to, or whatever. But I kept doing it because I got good results from it. And, at one point, I had…like, I don’t recommend people do this, but it was just more me exploring and seeing where you could go with this riffing stuff, was essentially writing a feature out.

And I think I had it down, and I was like, I don’t actually think I know how to write this any better. So, I started plugging in all the right places, like the controllers, models, whatever, doing the migrations, all that stuff. And then I had to fix some syntax errors here and there, or whatever, or something like that, in the copying, and it worked. And I was like, uh, okay [laughs], that’s nuts. Again, I don’t recommend doing that, but it was more trying to see where this could go. I don’t recommend doing that, but it was more just, like, interesting; oh, you could actually do that.

Because a lot of what I’m trying to look for at that early stage is design feedback. Like, if a method returns true or false, that’s business logic. It’s not going to invalidate the design. It’s more about all this organization…I like to call it the organizational skeleton around it. How do you figure out where does this go? Where does it fit with the rest of this whole thing? And so, do I now have all the state I need to be able to eventually compute that true or false? And that’s the real thing you’re trying to figure out. And you’re sort of a little bit like playing with Legos in a way. Do I put these together here, and does that work? Or what is this telling me now? Or do I learn something about the problem I’m working on that I then need to take to a stakeholder because I have discovered a thing that was contradictory, or something?

And one of the things that happened was, a side tangent now, I’ve been working a lot with this with my friend, Jeremy Smith. He was also the person who actually named it riffing because I didn’t have that name at first. He was like, “Oh, this is sort of what it feels like to me.” I had some other people I was just sending this to, and they were saying, “It’s kind of like jazz for programming away.” We’re using all this listening to kind of drive yourself further.

And we’ve been doing YouTube videos on this stuff and showing some demos, so you kind of get a feel for it. But then we also did a course, me and Jeremy, on just, like, trying to collaborate a little bit on some of this. This was, like, last year before RailsConf because I was doing a talk there to just help prep that.

So, what we had the people in the course do was essentially try to pair together on one of these riffing things. So, we gave them a prompt, something with, like, subscription credits. Actually, if you go see the RailsConf talk that I did in 2024, it’s the same prompt. It was too much to do, but now we’re like two tangents deep. And so, I think we had 2 people pair on it for 25 minutes, and in that 25 minutes, people are pitching in from the chat as well. It was really interesting and seeing that it kind of worked out again in this, like, weird, crazy way [laughs]. This works, I don’t know.

And then what happened was they had found a way that this prompt could actually…the system as it was described in the spec could actually be gamed. And I thought that was really interesting that they found that really quickly. And so, they could bring that back to the stakeholder and be like, “What do you actually think of this? Do you want this to be different? Or like what do you…how do you want to resolve this?”

And then, what I found, when that’s happened to me in my riffing sessions, it’s also been a case of, okay, well, let me explore the two different paths then. Because I think if I can resolve this with option A, let me write a little bit to see how that seems to go, and then let me try to write out option B. And sometimes what happens is you get a little bit down option A, and you’re like, no, no, this is not right. I want B. I want B.

But then you can make a recommendation that’s much stronger. You can be like, I’ve actually also tried to riff on these things and say that this seems like what I actually want to recommend is to do option B for this, and this, and this reason. So, that’s been really interesting to navigate in all this problem-solving, yadda, yadda [laughs].

Read the full transcript.