# DevRelCon, Red Eyes, and Enums  ## Episode metadata - Episode title: DevRelCon, Red Eyes, and Enums - Show: Build and Learn - Owner / Host: CJ Avilla, Colin Loretz - Guests: [Austin Kleon](https://share.snipd.com/person/0943d8ac-ec84-4901-8e5a-1abf2e1a06f0), [Grant Achatz](https://share.snipd.com/person/c612e3ce-8793-4da0-9cf3-ef0cb9dfb6df) - Episode publish date: 2024-09-10 - Episode AI description: In this lively discussion, renowned chef Grant Achatz shares his culinary experiences and insights from his innovative restaurant, Alinea. Author and artist Austin Kleon chimes in with thoughts on creativity, referencing his book 'Steal Like An Artist.' The duo dives into amusing travel tales from NYC, practical tips for surviving red-eye flights, and the evolving landscape of Developer Relations. They also debate the frustrating complexities of enums in programming, advocating for more flexible practices to adapt to industry changes. - Duration: 44:01 - Episode URL: [Open in Snipd](https://share.snipd.com/episode/bd504acd-de25-4f07-8314-47d618ae8a16) - Show URL: [Open in Snipd](https://share.snipd.com/show/a7d7cab4-9aff-4fb2-bee8-014ef5cd0f7a) - Export date: 2026-02-17T23:33:06 ## Snips ### [Red-Eye Flight to DevRelCon](https://share.snipd.com/snip/14a65d0a-2f83-42bb-9c33-b99fe12dcfce) 🎧 00:07 - 01:41 (01:33) <iframe src="https://share.snipd.com/embed/obsidian-player/snip/c6775fb1-9411-48d2-8d16-e520531b6fae" width="100%" height="100" style="border: none; border-radius: 12px;" sandbox="allow-scripts allow-same-origin allow-forms allow-popups allow-clipboard-write" ></iframe> - Colin took a red-eye flight to New York City and arrived just before DevRelCon started. - He managed with minimal sleep and navigated transport economically, relying on public transit and coffee to power through the conference day. #### 💬 Quote > I actually took a red eye on Wednesday night and got there an hour before the conference started and then thankfully I was able to sleep on a plane. > — Colin Colin on traveling to DevRelCon #### 📚 Transcript was pretty humid. was, you know, visiting New York in the summer. fun to go down the subway when it's almost 100 degrees outside. Yeah. Is it, this is not your first time to New York. And were you there for the whole week or was it just kind of a few days or what did that look like? Yeah, I actually took a red eye on Wednesday night and got there an hour before the conference started and then thankfully I was able to sleep on a plane. have taken that same red eye and not been able to sleep the entire time, which then just wrecked me for the whole day. I made sure that I would sleep on the plane, barely got any sleep. Like my whoop detected that I just didn't sleep, even though I know I did. Then had to figure out, you know, it's been a minute since I've been in New York. So I had to like figure out how do I get from JFK to the conference using, you know, air train to the, this line to this line. That was actually really easy. It was like, this was like a personal development trip So like discord wasn't paying for something. So it's like we're training the whole thing Like what's the cheapest way to get there? I think it was like a hundred and fifty dollar uber ride to get to the Conference. So yeah, I've to the conference had all my stuff with me all day just straight from the airport and just Had a lot of coffee and did the first day and then got to go to the hotel. And yeah, it was there for the weekend after as well. Just, it didn't make sense to like fly across the country and then fly right back as soon as the conference was over. --- ### [Sleep Tips for Red-Eye Flights](https://share.snipd.com/snip/8ab60cd7-a1cc-4d98-a8da-da3cced906f4) 🎧 01:41 - 02:55 (01:14) <iframe src="https://share.snipd.com/embed/obsidian-player/snip/5728a8f9-98ac-4245-884d-19e8fd5853d5" width="100%" height="100" style="border: none; border-radius: 12px;" sandbox="allow-scripts allow-same-origin allow-forms allow-popups allow-clipboard-write" ></iframe> - Use an inflatable pillow and noise-cancelling headphones to improve sleep on red-eye flights. - Manage your position on the plane wisely, and avoid being disturbed by passengers needing access to the aisle. #### 💬 Quote > I have an inflatable Sea to Summit pillow that I take, so I don't have to like, I think the pillow is important, but I don't want to carry a giant pillow everywhere. > — Colin Colin sharing red-eye sleep tips #### 📚 Transcript what are your tricks for trying to sleep on the plane for, for a red eye? Yeah. I mean, so many people like to do ambiance and stuff, and that stuff scares me a little bit. I just don't want to ever have to have something like that. So I have an inflatable Sea to Summit pillow that I take, so I don't have to like, I think the pillow is important, but I don't want to carry a giant pillow everywhere. So this one collapses down into nothing and you can just inflate it. I mask noise canceling headphones, usually AirPods or if you have over the ear ones. It's always tricky though because if you're on the end, I didn't realize this because I was completely out on this flight and no one needed to get up, but I was in the aisle. And like, if you need to get up to go to the bathroom and you're on the inside and everyone's sleeping, like it's not a great, I don't know. Airplanes are so weird, but on the return flight, it wasn't even that late. Like people were passed out and you could see people trying to like climb over seats and stuff. I was like, this is just like, this is how we fly. This is not what the TWA commercials of the fifties and sixties and the, the height of, of, of flight. --- ### [DevRel is Not Dead](https://share.snipd.com/snip/1b371abe-63ce-4681-b729-e959ea7d5ecb) 🎧 06:21 - 08:23 (02:01) <iframe src="https://share.snipd.com/embed/obsidian-player/snip/8f8aeac9-d8f3-4d90-ae5c-48d0451effcf" width="100%" height="100" style="border: none; border-radius: 12px;" sandbox="allow-scripts allow-same-origin allow-forms allow-popups allow-clipboard-write" ></iframe> - The idea that developer relations (DevRel) is dead is misguided due to its varied roles in different companies. - DevRel functions differ widely based on company needs, making generalizations about its demise inaccurate. #### 💬 Quote > Saying DevRel's dead is dumb because it's not one thing, but every company is different. > — Colin Colin on the state of DevRel #### 📚 Transcript We, we can talk about it here because this is a safe place, but was interesting to see how much, there's been a lot of articles about the death of DevRel and we've talked about it on the show before. We may have even mentioned it in the last episode and it was just really weird to see that energy from some folks who aren't even in DevRel anymore. And I'm not sure what the goal is. It's like, is this for your own personal, like, pulling the ladder up behind you, literally kind of stuff, but it's people who aren't even necessarily in dev rel anymore. And there's just a whole lot of justifying dev rel's existence or justifying the function of dev rel. And mentioned it before, but like a lot of the stuff that we do at discord just doesn't look like normal or quote unquote normal DevRel. And when we worked at Orbit we saw this too, every company does it differently. So say DevRel's dead is dumb because it's not one thing, but every company is different. And I think Kelsey Hightower said DevRel is whatever the person paying you says it is, right? At Stripe it's going be different than Shopify is different than a developer first company versus developer plus company. Is it more community focused? Is it content focused? It's all different things. Like you did is very different than what I did. We probably had lots of overlaps, but like, you know, you were very much a face of the docs literally when people would start, know, the videos it was it was CJ. So it was an interesting like vibe to the conference. Like there were definitely people who mentioned some of those articles and the the perception of it Obviously a lot of people also trying to get jobs so that I think that also perpetuates it a little bit like oh If everything was in you know, the high times of dev rel, then everyone would just have a job. And it's like, well, it turns out there is unemployment in every industry. And dev rel does not escape that too. hopefully some of those people are able to meet people and get jobs or connections through, through this though. --- ### [Modern DevRel Trends](https://share.snipd.com/snip/85df6575-d6cd-4bb1-b135-8f92a63908f8) 🎧 10:56 - 12:45 (01:49) <iframe src="https://share.snipd.com/embed/obsidian-player/snip/6ac39ad8-e799-4968-b303-bad5fbc6faaa" width="100%" height="100" style="border: none; border-radius: 12px;" sandbox="allow-scripts allow-same-origin allow-forms allow-popups allow-clipboard-write" ></iframe> - DevRel’s future often involves partnering with strategic developers and catering to a wide range of users. - Mature DevRel teams focus on tailored strategies beyond simple advocacy or conference presence. #### 💬 Quote > There’s this concept of head torso and tail developers in your company. The head being strategic, torso is partners, and tail are DIY developers. > — Colin Colin at DevRelCon on DevRel evolution #### 📚 Transcript there any like trends or things that seemed interesting in terms of like what or like, you know, what is dev rel going to look like in 2025 in terms of. I don't know. I guess I'm thinking stuff like short form content and, or like stuff that's sort of, uh, you know, um, beyond like docs and SDKs. Um, there was, there was a, the talks that were most interesting to me were around like partners and kind of going, there's like this concept of head torso and tail developers in your company. So the head being like those strategic, torso is being, you know, kind of like, we have a contract with you and you're a partner of some kind. And then you had a long tail of just every DIY dev that finds you and is figuring it out. Maybe they're learning, maybe they might bring it into their next company with them. Maybe they're doing something indie or something. So those two were interesting. One was from Roku and the other was from Bear Douglas Pinecone. They time at Twitter and Slack dev, dev rel stuff. those two were probably like the most squad, like mature form of dev rel. And think where a lot of people want to be like, they are not justifying their existence. I guarantee it. Right. Like they know exactly what the power is that they, that they're in. I didn't go to any, there will be all their talks will be released. So even if you couldn't make it, they will be on DevRel Con's YouTube channel. But there was one on video from Kevin. blanking on his last name, Kevin Lewis, just around like how to create that video production like process and stack for yourself. The one that was most valuable to me was actually docs and SDKs and it was an uncommon talk. So didn't really get a sense to answer your question like of like the future of DevRel. --- ### [Avoid Enums for Complex Models](https://share.snipd.com/snip/cf6d21a7-31a4-45a9-b501-e9683d634777) 🎧 16:55 - 21:00 (04:05) <iframe src="https://share.snipd.com/embed/obsidian-player/snip/d283d0c9-12ef-4b56-bbc5-298d192a21e3" width="100%" height="100" style="border: none; border-radius: 12px;" sandbox="allow-scripts allow-same-origin allow-forms allow-popups allow-clipboard-write" ></iframe> - Avoid using enums for complex domain modeling due to migration headaches and inflexibility. - Replace enums with proper models that can encode multiple attributes for better extensibility and maintainability. #### 💬 Quote > Enums are just creating so many, so many problems, so much pain. Just don't ever use enums. > — CJ CJ's critique on using enums #### 📚 Transcript Back in Enum land. I am, I have a new rule of thumb. No, Enums death to Enums. Enums are just like creating so many, so many problems, so much pain. I have decided that yeah, it's just, this migration is just awful. So yeah, we haven't, we have, I have this big blog post about like ways that you should do enums, right. And I'm going to go make an edit to that and just say, just don't, don't ever use enums. It's just such a messy, such a messy, uh, migration to fix switching from an enum to a proper model. And now that we have the model, it's so much more flexible and there's so many more things we can do with it. And yeah, just like breaking it out and actually being able to encode way more than just a string into the value of the enum. And that the, I feel like someone who maybe hasn't played with enums or is just joining us, like, is that going to be the biggest trade-off? Is that like, usually yeah, it's just a string or some sort of int value. Right. Yeah. So usually I think probably the rule of thumb, typically for enums is like, if you have some very small fixed set of things that are some very small fixed set of values that could be assigned to something, then might want to use an enum where, you know, it's either one, two, or three, and it can't be any other value. In of like how it's technically implemented, you can do it at the database level, Postgres support Cnems You do it at like the model level in Rails where you have a column that is either a string or an integer. And you know, if you want super, super fast, speedy, whatever, then you might decide to store an integer in the database. But Rails has like these, you know,rogramming tools that expose methods so that you can call methods on your model, and those can get mapped to names which are attached. So, for example, if you have a status field and you have pending and submitted and canceled or something, you might consider making those in Enum, where in the database you actually store just like 0, 1, or 2, but 0 might be mapped to say like pending, 1 might be mapped to submitted, and 2 might be mapped to cancelled. And then you'll get methods on your object like thing.submitted, question mark, and that will return true or false depending on whether or not it's submitted. So there's a lot of nice little conventional things that you get from it, but we were using it for an item type. In our case, that's like for an estimate, can you, an item type might be the walls or the trim or the ceiling or the crown molding or the window casings and things like that inside of a room. And so you would build up these estimate items for a line item. And of those estimate items will be tied to an item type. So the beginning, it was fine. was like, okay, yeah, you can do the wall ceiling trim and crown molding. And then over time, it was like, okay, now we're painting exteriors. Now we're painting cabinetry, which needs like inside boxes, outside boxes. You exteriors need like fascia and columns and stairs and like all kinds of other stuff. so eventually it was like, okay, now we're trying to encode way too much just into the name of the enum. So got to a point where like the name of the enum was like paint square foot, exterior, siding, whatever. that points at number like 94 or something. And like, okay, we're abusing it too much. This should be a proper model where the model has a name and maybe a slug and an ID. And it accept paint colors or does it not? And is it an individual unit? Are we going to paint each of these or are we going to paint one of them or are we going to paint it by the square feet or by the linear foot? And so a lot of that encoding can happen in a proper model that is like really hard when you're just using an enum. how does that work with --- ### [Use Models for Dynamic Data](https://share.snipd.com/snip/c92788d9-347f-4b85-80af-ee0305b809f1) 🎧 21:10 - 22:25 (01:15) <iframe src="https://share.snipd.com/embed/obsidian-player/snip/47e2c8a5-a7bf-4b42-954a-9e8f31a64d0b" width="100%" height="100" style="border: none; border-radius: 12px;" sandbox="allow-scripts allow-same-origin allow-forms allow-popups allow-clipboard-write" ></iframe> - Use separate data models for values needing frequent updates to empower non-technical users. - This avoids costly database migrations and allows dynamic additions via UI by sales or other teams. #### 💬 Quote > If you use a separate data model instead of an enum, non-technical users can just click around in the UI and add new types. > — CJ CJ on replacing enums with models #### 📚 Transcript if you're adding, you add a new enum without it being a breaking change. If we decided we have pending, submitted, canceled, and if we wanted to add some other one that was like waiting review or something, we could just make that number four. I mean, the models themselves, if, oh, right. If completely changed the model options or, you know, we have a new thing that usually additional things are move, like they break forward and you don't really need to worry about then if you're changing up stuff, how does that work? Right. So when you're using an enum, if it's in the database, it needs a database migration. If you're using an enum in the model, you can add to it or change it from the model. If you're using a separate data model instead of an enum, that gives you a lot of power to like hand over the keys to non-technical users who can just click around in the UI. If someday the sales team decides that they want to support painting, you know, flower pots or something, they can just go in and add a new item type for flower pots. And like, it should all just work as expected without having to like make a change to the code. --- ### [Effective Project Task Management](https://share.snipd.com/snip/aa4da5e1-0181-4817-9e99-3f24f046a1e3) 🎧 23:55 - 26:16 (02:20) <iframe src="https://share.snipd.com/embed/obsidian-player/snip/ed2c469b-e8c6-4cff-9e60-4dd5b8f27021" width="100%" height="100" style="border: none; border-radius: 12px;" sandbox="allow-scripts allow-same-origin allow-forms allow-popups allow-clipboard-write" ></iframe> - Use an inbox project in task systems to separate known priorities from unprocessed requests. - Limit adding tasks directly to main lists; triage and prioritize to maintain focus on important work. #### 💬 Quote > There'll probably be a different project that’s like an inbox. If it's in the inbox, you can count on the fact that we haven't seen it yet till it’s processed. > — Colin Colin on project tracking challenges #### 📚 Transcript little bit of everything we as a company use a sauna for a lot of stuff. We also use notion for a lot of stuff. We have get hub for a lot of stuff. And what's tricky is not necessarily like where do you put all the tasks. It's what is if we only have two people's worth of time, what is the most important things for us to be doing? What are things that are popping up that we don't know about? What are things that we know are going to come up that we don't think about yet, but we don't want to keep it in our brain. And like this feels like solved problem everywhere all the time. But the challenge is if you CJ come and view that board by yourself tomorrow, it's hard to know what of these things are hard, take a long time, are things that we can do in our sleep, things that we already did, unless we really have a good system for it. And this kind of goes back to the slow productivity episode that we talked about where when someone does come with, with something that they need you to do, like asking them to go put it on the list and they'll see how many other things you're doing and they'll be like, Oh, maybe I'll just do it myself. Or maybe it's actually not as important as I thought it was. But like today you couldn't do that because you'll be like, Oh yeah, they just have a lot of stuff. Let me just put this on the top of their pile. And the problem with that is that we don't either know that it's been added and that can be solved all sorts of ways. So we're just trying to think through like how to do this. And we've mocked up a thing in Notion to just play around with like different concepts and ideas. And I went down this like Notion rabbit hole and bought a few temp project templates to see how the people are doing it. And man, people are doing some crazy stuff in notion, which is awesome. But then you're spending more of your time curating notion than actually doing the work. So we traveled a really long circle around to now we're going back to Asana. In part because the team can also see it. We're just going to try to figure out how to make it more like you don't get to just add things to our list. There'll probably be a different project. That's like an inbox. And then we'll move things into our projects that we, if, if it's in the inbox, you can count on the fact that we haven't seen it yet. Till it's been processed. So we're still figuring it out, but it has helped even the notion has helped to take things out of my head so that I don't have to carry them around with me. --- ### [Project Management Challenges](https://share.snipd.com/snip/ceab4626-e43c-47d0-a823-f95f7c791eae) 🎧 26:43 - 29:57 (03:14) <iframe src="https://share.snipd.com/embed/obsidian-player/snip/25a91347-c4ab-4b74-a336-97f43a199918" width="100%" height="100" style="border: none; border-radius: 12px;" sandbox="allow-scripts allow-same-origin allow-forms allow-popups allow-clipboard-write" ></iframe> - Project management overhead mainly serves reporting and visibility to higher-ups rather than internal productivity. - Breaking work into small tickets still leaves many unknowns; priorities change as new tasks and projects emerge. #### 💬 Quote > The main reason for project management overhead was for reporting up. It was all about visibility up, very little about internal productivity and getting stuff done. > — Colin Colin on complexities of project tracking #### 📚 Transcript And we, we actually had a similar discussion with our team at the Offsite a few weeks ago, where we were like, why do we need to put tasks, individual tasks into projects? If I know that there's something that needs to be done, can I just create a task, assign it to myself, and do it? And we made a rough rule that every task must be assigned to a project. And so we used linear for project management. I don't know if that was one of the ones that you checked out, but that's like also a company-wide thing that we're using. So if we were, had a place using Asana, we would certainly use Asana. I don't know if Asana has the concept of projects, but where we landed was like every task should be attached to a project. And then what we've done is put those projects into initiatives. And I think it used to be called roadmaps or something in Asana. And so like when we meet with the stakeholders from different teams, we'll pull up their roadmap and be like, here's all the projects that we know we're working on for you and like rough statuses of each of those. Here's the two that are in flight right now. Here's like what's on deck and then here's everything under that. But I think the biggest takeaway from that meeting was that the main reason for doing all of the overhead regarding project assignment and project management was for reporting up. It was like all about visibility up and very little about internal productivity and us getting stuff done. was almost all about how do we communicate to other teams, how and what we're working on, where in the priority does their tasks fall. But yeah, back to your, one of your earlier points about like, when you look at a ticket, you don't know, is this big? Is this hard? Is this going to take forever? Is there like how many unknown unknowns are there? And there that's like a very challenging thing that I don't think I've ever been on a team that got super, super right. We've done, I've been on teams that have tried the like Fibonacci thing. We've tried the t-shirt sizing thing. We've tried like a bunch of different approaches to measuring tickets. I think in my experience, breaking things down as far as possible can be really helpful to trying to like estimate out how long something is going to take. But yeah, even then, there's a lot of times where like, you don't know what you don't know until you get into it. And so roughly what I've been finding is that the projects that we're working on at Kraftwerk, when we sit down to like design it or think about it, we might write out like 40 tickets or, you know, 35 tickets by the time it's done, we have like 85 tickets or something. And so it's like, you know, more than two X, the number that we thought we were going to do. And of those 85, like 15 of them end up just like never being done ever. They're just like stuff that we thought we were going to do that ends up in this bucket of like, nice to have, but not happening until like, yeah. So like a project, like the priority of the project is actually, there's like a cut line where like after you've finished a certain amount of the work related to a project, it's like, okay, we're cutting right here because there's work. --- ### [Balance Tough Work with Fun](https://share.snipd.com/snip/d3ddd220-2517-48ba-8672-969bb8f533a4) 🎧 32:21 - 34:02 (01:41) <iframe src="https://share.snipd.com/embed/obsidian-player/snip/a526e4bc-8053-43aa-a4c5-0f4ccc17dd22" width="100%" height="100" style="border: none; border-radius: 12px;" sandbox="allow-scripts allow-same-origin allow-forms allow-popups allow-clipboard-write" ></iframe> - Balance tasks to include both challenging projects and enjoyable small wins to maintain motivation. - Take intentional breaks and celebrate progress to avoid burnout and sustain productivity. #### 💬 Quote > You need some small wins; it can't be just the big, huge, maximum effort tasks all the time. You can't run a marathon over and over again. > — Colin Advice on productivity balance #### 📚 Transcript I think a lot of it too, on the tactical side, not on the project management side, a lot of it is about and enthusiasm and like how pumped you are to do the work. And if you open up that project list, wherever it is, and you're like just dreading every single project on there, like you're not going to have a good time. And you're probably going to leave. Yeah. So like having a mix of like stuff that you're pumped about and stuff here. They, you know, like your vegetables, but also you got to have a cookie every once in a while. That's like, all right, let's just like, you know, play with the CSS animation on this in this button that buried somewhere, you know, so I've been thinking about it more and more like a conductor of an orchestra where you have space and noise, right? so you space between the notes is what makes it into music. If they all play at once without any thought, then it's not going to be good. yeah, you have to have some small wins. It can't just be the big, huge, you know, maximum effort tasks after, like, you can't run a marathon over and over again. gotta be some like tasks to come back and just clean some stuff up that we knew we needed to do and come back and maybe even just do a small bug fix that people have been asking for. And everyone's like, Oh, I think, you know, that, that might get more attention than the big scary thing, but the big scary thing also still needs to happen. So kind of having like some good little stop stopping points along the way where you can look backwards and just take a break or, or switch gears and intentionally context switched. Cause yeah, to your point, you're going to burn out. You're going to leave if, if not. --- ### [Source Vision from Product Team](https://share.snipd.com/snip/bf2e38e2-efb5-4af1-bf9c-01e3cd326015) 🎧 34:03 - 35:15 (01:11) <iframe src="https://share.snipd.com/embed/obsidian-player/snip/fa081066-12fe-465f-a7b3-62266fa53fa5" width="100%" height="100" style="border: none; border-radius: 12px;" sandbox="allow-scripts allow-same-origin allow-forms allow-popups allow-clipboard-write" ></iframe> - Align project work mostly through product teams who set the vision and priorities. - Communicate early with engineers to get docs started and keep documentation up to date for a smooth developer experience. #### 💬 Quote > For me, it’s mostly going to be from product and they've already done all the way up to the CTO and CEO and done all that. > — Colin Colin on project vision and docs #### 📚 Transcript Are you feeling like, or I guess I'm curious, where you get your. Inspiration and motivation and vision from, is it like the company, you know, the CEO's like writing some vision doc, and then you're taking that and, and deciding what projects to do. Are you working with directly with like product managers from other teams to decide what to do? Like kind of where does, where does your remit, I guess, come from? Yeah, for me, it's mostly going to be from product and they've already done all of the, up the chain to the, all the way to the CTO and CEO and done all that. So by the time it gets to us, it's like, this is what we're focusing on either quarter or half a year at a time. And so, like, we kind of know like what things we're going to be releasing. What things do we need to monitor and join product meetings and talk to developers and stuff ahead of time. Start getting docs ready. Is the feature done enough that we can start docs? Can we get the engineers to write the docs so we can edit them? So yeah, it kind of goes in waves like that. And then we get like PRs for stuff that just might not be correct anymore. So there's, there's the less vision stuff, but the vision of like, we want to have a developer platform or good experience. --- ### [Steal Like an Artist Insights](https://share.snipd.com/snip/2a9d5b65-f4bf-438b-84ad-abbbaf95c99b) 🎧 36:20 - 40:22 (04:02) <iframe src="https://share.snipd.com/embed/obsidian-player/snip/0779bc5f-fd7a-4aab-add1-58395618a814" width="100%" height="100" style="border: none; border-radius: 12px;" sandbox="allow-scripts allow-same-origin allow-forms allow-popups allow-clipboard-write" ></iframe> - Creativity involves remixing elements from multiple inspirations rather than copying one source exactly. - AI exemplifies 'steal like an artist' by combining many sources to generate new expressions. #### 💬 Quote > An artist doesn’t just imitate one artist. They steal good bits from many and remix it to make their own thing. AI is steal like an artist, combining different sources. > — CJ CJ on creativity and AI inspiration #### 📚 Transcript Have you ever read that book steal like an artist? Don't think so Feel like an artist from Austin Kleon? Clone? Yeah. How is it? Mike sent me this book and I had, apparently had read it before. don't know. my Goodreads it said that I had already read it. I have listened to it, but this was the first time reading the physical version. And I really liked it. I thought it was a fun read and the way that it was laid out was kind of fun. He also has another book. I think it's called Newspaper Poems or something like this, where he takes a newspaper and then uses a Sharpie to black out parts of the words. And what remains becomes like a poem. So it's like taking some other thing and then doing that. So there's like a lot of artistic little kind of blurbs and tearouts and ways to look at stuff. But yeah, I really enjoyed it. I thought there was good reminders in there. For example, like figuring out people you draw inspiration from for like anything.. In my case, I was thinking a lot about devs that I look up to and have followed their career over time. Major like Jim Wierich and Sandy Metz and Gary Bernhardt, also content creators, Ryan Bates, Abdi Grimm, Kent Dodds, and then also people who I've worked with or collaborated with who I thought had just insane work ethic and high productivity and were just really successful. But one of the recommendations was like, go find the people who you look up to and then figure out who are the people that they looked up to and follow the family tree up and do research and try to figure out of like the foundational reasons that are, you know, kind of like core values that might have driven that. So was kind of interesting to think about and also like think about areas where I might be curious to find some more folks to like learn about and maybe be inspired by. Yeah, I think this book comes up a lot along with the war of arts as well. Cause I think a lot of it also comes down to like motivation and inspiration, creativity, and like, are you getting it from other people? Like every thought, right? Even when we talk about ideas on here, it's like we get afraid that someone's going to steal our idea and go and do it. Right. And everything is a copy of something at some point. It's like, is it even once I have like an idea for something, I know there's like 10 other people who are probably thinking on it. Maybe are they actually doing it as a whole other question? Like, do you, cause it takes a lot to do something. So do wonder, like I'll have to read this book, but I wonder how this is framed. Like, have you, are you in the middle of reading it? No, I finished it. Yeah. But yeah, doesn't apply at all to the literal steel, like an artist of AI and, and that's interesting. It actually, does. here's how. So think one of the most core tenants of the book is basically this concept of an artist doesn't just imitate the same exact artist. They're not going to pick one person and do something just like them. What they're doing is looking at a whole field, a whole bunch of different artists, and looking at each piece and saying, what's the one thing that I really like about that? And just the good bits and then remixing it to be their own thing. Instead of just being like, okay, I see Colin's got that really cool hat on, I'm going to put on the same exact yellow hats. Like, okay, cool. You're not, you know, you didn't really come up with your own thing, but yeah. And so in that way, I do think that AI, because it is combining so many different sources, like it is steel, like steel, like, I guess it's like steel, like an LLM. --- Created with [Snipd](https://www.snipd.com) | Highlight & Take Notes from Podcasts