DevRelCon, Red Eyes, and Enums

Show Notes

We discuss visiting NYC, DevRelCon, red-eye flights, and why enums are terrible.

Some of the bits and bobs mentioned in this episode:
- DevRelCon
- Chef's Table (S2E1 Grant Achatz) / Alinea
- Steal Like An Artist by Austin Kleon
- CJ enumerating lessons about enums


Full Transcripts

CJ: What's up, Colin? Welcome back from DevRelCon. How was New York City?

Colin: was pretty humid. It was, you know, visiting New York in the summer. Always fun to go down the subway. when it's almost 100 degrees outside.

CJ: 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

Colin: Yeah, I actually took a red eye on Wednesday night and got there an hour before the conference started. And then

CJ: I don't know.

Colin: thankfully I was able to sleep on the plane. I have taken that same red eye and not been able to sleep the entire time, which then just wrecked me for the whole day. So 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 I 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 is, was like a, like a personal development trip. So like discord wasn't paying for something. So it was like, we're training the whole thing. Like what's the cheapest way to get there? Cause I think it was like 150 Uber ride to get to their conference. So yeah, I've got 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.

CJ: hmm. So what are your tricks for trying to sleep on the plane for, for a red eye? I don't know.

Colin: Yeah, I mean so many people like to do like ambience 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 some 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 like carry a giant pillow everywhere So this one like collapses down into nothing and you can just inflate it. I mask Noise canceling headphones, usually AirPods, or if you have like over the ear ones, it's always tricky though. Cause like if you're on the end I didn't realize this cause I was completely out on this flight, but like, 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. And I was like, this is just, like, this is how we fly. This is not what the TWA commercials of the 50s and 60s and the, the height of, of, of flight.

CJ: That's not the promise. This is not what they promised us. Yeah. I, we have a red eye coming up. I haven't done one for several years. And I, I remember after I did the last one that I would never do one again. Like I was like, I, this is awful. Like I hated every second of the day

Colin: Yeah,

CJ: So yeah. Any, any any tips and tricks are Yeah,

Colin: is that with the kids or just you?

CJ: with the

Colin: that, that'll probably make it a little bit more complicated. But I would say if, I don't know if you're up for it, but like I did do like half a weed gummy on the plane. I was just like, I need this. to make this work. So I mean, I trust that more like I know it'll be a few hours versus an ambient where I'm like, I don't want to be waking up like even more tired or

CJ: yeah, totally. Yeah. That'll help for sure. Okay. I've also heard like, yeah, just do your same like bedroom routine or whatever, like at the airport, like wash your face, brush your teeth, like do the whole same thing that you would do before you go to bed and then like just do it and then get on the

Colin: Yeah. I mean, like screens obviously are an issue. Like, it's already you're starting late, like, Honestly, I don't usually stay up till even midnight and my flight wasn't till midnight. Things like magnesium, tart, cherry juice, all those kinds of things can also help. So all the sleep stack stuff that everyone likes to talk about, this is the time to use it.

CJ: Yeah. Have you seen those take talks or Instagram reels of people, raw dogging

Colin: Yeah,

CJ: Yeah. They just like stare, they do nothing. It's like, I saw this one that is the guy was like you know, six and a half hour flight, no snacks, no drinks, no water, no screens, no music, just no going to the bathroom. You just stare at the back of the seat in front of you for six and a half hours. Part of me is like tempted to try it. Just like, it's, it just seems like such a meditative. Thing, but

Colin: for me, I get annoyed by everyone else on the plane, like I need to like movies are probably the easiest way that I get through flights, if I can work a little bit of write or read or something that's always good too, but the idea of like, like, I hate being Having to go to the bathroom on the plane because it's small and

CJ: Mm-Hmm.

Colin: that. But, you know, so then I, like on a long flight like this, like I'll try to be like, okay, we're going to get, we're going to use the restroom in the middle. So I only have to use it once, not try to drink too much, but drinking water, enough water, especially when you're flying is important too, for all just feeling normal, not having jet lag. Movies are good. Yeah. There's like the tick tocks of people just watching the map across the whole thing. And I don't know, like you got to take care of yourself on these things. I don't think it's worth trying to like win a medal for some meditative monk state, but yeah.

CJ: And then so you got to the conference and was it kind of several tracks or single track and then like rough idea of like how many people were there and kind of like, where was it at and

Colin: Yeah, it was an industry city in New York city. So kind of like food hall, bunch of businesses and food, food vendors and stuff. And so there was like a event space for the main track was there were two tracks. I don't know if they were actually split by a topic, but you could go between the two rooms depending on what topic you're into. And then there was an unconference that was running both days as well. We, we can talk about it here cause this is, This is a safe place, but it was interesting to see like 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 maybe even mentioned it in the last episode. And it was just really weird to see that, 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, like pulling the ladder up behind you, literally kind of stuff, but it's people who aren't even necessarily in DevRel anymore. And there's just a whole lot of justifying re's existence or justifying the function of Derel. And we've mentioned it before, but like a lot of the stuff that we do at Discord just doesn't look like normal, well, quote unquote normal derel. And when we worked at Orbit, we saw this too. Every company does it differently. So you to, to say Derell is dead is. Dumb because it's not one thing, but every company is different. I think Kelsey Hightower said DevRel is whatever the person paying you says it is, right? At Stripe, it's going to be different than Shopify is different than a developer first company versus a developer plus company. Is it more community focused? Is it content focused? It's all different things. Like what 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, you know, the videos, it was, it was CJ. So it was an interesting vibe to the conference. Like there were definitely people who mentioned some of those articles and the, the, the perception of it. Obviously a lot of people also trying to get jobs. So I think that also perpetuates it a little bit like, Oh, if everything was in, you know, the high times of DevRel, then everyone would just have a job. And it's like, well, it turns out there is unemployment in every industry and DevRel is not. does not escape that too. So hopefully some of those people are able to meet people and get jobs or connections through, through this though.

CJ: Yeah. I think as long as companies are working with developers as customers. There will be some form of DevRel and dev marketing and content creation and community building and all of that is like important if your customer is a developer. And so yeah, I can't imagine a world where DevRel really permanently goes away and in all different aspects, I think it'll definitely shift and change over the years, but yeah, I think At every single one of these companies, there is definitely some sort of need, whether that is a full time thing or not is debatable, but there's certainly like that activity is important and valuable and

Colin: Yeah. Well,

CJ: kind of a bummer to hear that folks are saying that it's dead though, because it was like, it's by far one of my most favorite roles for sure.

Colin: yeah, I'll share some of the articles in the links and I'll share one with you too. That one comes from Casey who started at Twilio danger, Casey. And they're in kind of more product role now. And I think that they're an example of like, they were, Twilio was kind of the quintessential DevRel, right? Like the time to first hello world, the, which is great for sending a text message. It's an amazing demo to curl and send a text or ring a phone call. And now with AI, like we can do so much with that. And there's a lot at some point, I think DevRel did become how many conferences can you go to? And there's some very valid points. It's like. It is weird to go to a conference when every speaker is a DevRel. It feels like ad after ad. And again, not every DevRel does talks the same way either. Like, there are some people who make a talk and pitch it to every conference on the planet. And then there are people, I think like you and I both approach it a little bit differently, and we craft a talk for the conference. And sure, it doesn't quote unquote scale, but like, It makes for a good talk that isn't a sales pitch. Even if we're dev advocates, we're not necessarily pitching. Like when I did mine, it was not pitching orbit. It was, we had this problem at orbit. This is how we fixed it. This is how you might approach build versus buy or whatever in your company. And it wasn't then go use orbit. So obviously if you're. Running a tools company and you're at a dev conference, you are being paid to chill your tech tools. So I think that is, there's a fine line of being the, the over, overly salesperson versus truly advocating for something.

CJ: Were there any like trends or things that seemed interesting in terms of like what modern or like, you know What is devrel gonna look like in 2025 in terms of I don't know I guess I'm thinking stuff like short form video content and or like stuff that's sort of you know Beyond like docs and SDKs.

Colin: 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 strategics, torsos 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 the next company with them. Maybe they're doing something indie or something. So those two were interesting. One was from Roku. And the other one's from bear Douglas from pine cone. They spent time at Twitter and Slack doing dev dev rel stuff. So those two were probably like the most quote, like mature. form of Deborah. And I 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 of the, there will be, all their talks will be released. So even if you couldn't make it, they will be on Debra Khan's YouTube channel. But there was one on video from Kevin, I'm 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 unconference talk. So I didn't really get a sense to answer your question, like of like the future of DevRel. And I think I kind of went with my own assignment of how are we going to think about maturing DevRel at discord? That was kind of my homework of what does it look like as we, if we can build out the full team for it. And it didn't really check any of those boxes, but like the unconference around what people are using, who's also responsible for the docs and all that kind of stuff was, was fun. I, I think I am a docs person at heart, so,

CJ: It's, it has been really interesting to see that responsibility falls in different companies. Where like at Stripe, the docs were technically supposed to be written by the product team, but we had like a giant team of docs writers that would also sometimes write. The docs. And then we had an editor who would like, make sure all the tone was the same. And then I know tons of other companies where docs might be written by DevRel, or they might be written by, you know, support, or they might be written by marketing or something. And so, yeah, where that falls is, is pretty interesting. Especially like. I don't know the different flavors that we talked about before that kind of like the four different types of documentation.

Colin: Yeah,

CJ: cool.

Colin: that was DevRel con.

CJ: Nice. Nice. Sounds like a fun trip.

Colin: What were you working on while I was running around New York?

CJ: Oh gosh. Last week. Oh, actually, you know what? Logan and I took a trip to Chicago. So you were, I think when you were in New York, we were in Chicago for the first time. It was awesome. It was a father son trip. The first one this year. I'm doing another one later this year with Grayson. We're going to go to DC. But Chicago was awesome. It was my first time going and we like, Just played and had tons of fun. We went and did like this boat tour for architecture and we went to a bunch of museums and his favorite thing that I think, like, it made me a little bit nauseous, but it was one of those like flight simulators where you get in the actual cockpit and as you're like rolling the joystick, it actually like rolls over the entire cockpit. So you can feel like you're upside down or like, you know, you're diving straight forward or whatever. It was, it was pretty epic. Super fun. But yeah, definitely a little bit nauseating. So, but yeah, Chicago was Chicago was pretty, pretty sweet. I think I would definitely go back probably just Nicole and I do some more adult stuff, go to shows and eat out at more restaurants and things like that.

Colin: Yeah it's, it's it's not a cheap dinner and I haven't been yet. It is on my bucket list, but if you if you guys really enjoy food and you and Nicole go back, gotta go to Alinea.

CJ: Okay.

Colin: we'll put a link to it, but one of my favorite chefs. Really crazy story. If you I'll put a link to the, I think it's a chef's table story with him. There's something that happens to him in there that it's just like such a crazy story. I won't spoil it here, but very cool restaurant. I mean, it's definitely one of those like Michelin star, like very expensive restaurants, but if there's ever a special occasion, it's on my list as well.

CJ: The food was good. I love deep dish pizza. We had that, but I think it was not as good as New York. So like, I remember like every single of food and well, I mean, I, I, yeah, like the pizza, the pizza, I think actually the pizza in Chicago. I don't know. We had like a slice on the street, like in New York. So different, you know, not easy to compare, but the, like just in general, overall, every bite in New York was just insane. And Chicago was like hit or miss a little bit, but yeah, that's funny. We did go, yeah, we went to this like museum of science and industry, and they had like a double Oh seven exhibit going on, which was pretty sweet to see, like, he's like Aston Martins and like, you know, props and stuff from the movies. So that

Colin: that's a, that's a good one to have a museum on. No shortage of things to show.

CJ: yeah, yeah, totally. It was a blast. So

Colin: And you're back in back in enum land and work?

CJ: 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

Colin: Foot guns.

CJ: 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, 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,

Colin: that the, for 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.

CJ: 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. Or some very small fixed set of values that could be assigned to something, then you 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 terms of like how it's technically implemented, you can do it at the database level, Postgres supports enums you can do it at, Like the model level in rails, where you have a column that is either a string or an integer. And like, you know, if you want super, super fast, speedy, whatever, then you might decide to store an integer in the database, but then rails has like these, um, you know metaprogramming 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 like a status field and you have pending and submitted and canceled or something, those, you might consider making those in enum where in the database, you actually store just like zero, one or two, but zero might be mapped to like pending one might be mapped to submitted and two might be mapped to canceled. And then you'll get methods on your object. Like you know, thing dot submitted question mark, and that will return true or false depending on whether or not it's submitted. So there's like a, 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 like a line item. And each of those estimate items would be tied to an item type. So in the beginning it was fine. It 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 know, exteriors need like fascia and columns and stairs and like all kinds of other stuff. And so Eventually it was like, okay, now we're trying to encode way too much just into the name of the enum. So we got to a point where like the name of the enum was like paint, square foot, exterior siding, whatever. And that points at number like 94 or something, you know, and that's like, okay, we're like abusing it too much. This should be a proper model where the model has like a name and maybe a slug and an ID and like, you know, does it accept paint colors or does it not? And is it a. This individual unit, like, are we going to paint each of these? Or are we going to paint one of them? 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.

Colin: How How does that work with when you want to change or update or add to a model? Is there some sort of versioning or anything like that built in?

CJ: So usually if you're adding, you add a new, you can add a new enum without it being a breaking change. If you are like, if we decided, you know, 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.

Colin: I mean, in the sense of the models themselves, like if,

CJ: Oh,

Colin: if you've completely changed the model options or, you know, we have a new thing that like usually additional things are, are move, like they break forward and you don't really need to worry about it, but then if you're changing up stuff, how does that work?

CJ: Right. So yeah, when you're using an enum, if you, 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. So

Colin: I mean, I guess you're working with things in the real world. So like, it's not like we're going to find something that we've never discovered before a fourth, a fourth dimension. It's like, okay, how, what is the width, the depth and the height? We know there will not be yet another measurement that we have to worry about.

CJ: Exactly. Yeah. So yeah, just kind of doing surgery, replacing that with models, and that's been a big project. Yeah, just like putting a bow on and a little cherry on top of the calendaring stuff, but for the most part, like, the calendaring, staffing, clock in, clock out stuff is all Pretty much wrapped up. So

Colin: Very cool.

CJ: yeah,

Colin: Yeah. I think definitely update your blog posts, but I think a blog posts around death to enums or something might be interesting too.

CJ: yeah, okay. Yeah, I think that's coming in hot. Ooh, another, yeah, I can't remember if we talked about it last time, but I have a blog post in mind about splitting Redis instances, like one for view caching and one for sidekick, which was a thing that bit us and took a while to figure out

Colin: that.

CJ: yeah, what's going on over there, project tracking, you got some, yeah, what,

Colin: Yeah, I guess.

CJ: your preferred

Colin: Oh man, I guess DevRel is like more of my brain is right now, but we've been trying to figure out how to track what we're doing. When we do so many things, we do a little bit of everything. We, as a company uses 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 a solved problem everywhere all the time, but the challenge is if you common 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 template rabbit hole and bought a few temp project templates to see how other 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. Then actually doing the work. So we traveled a really long circle around. So 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. They'll probably be a different project. That's like an inbox. And then we'll move things into our project 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. Like when I go home and just like. Not have to worry about it or if someone goes on PTO or something like it's all in there. We might end up doing some sort of like top five thing instead of trying to figure out like how do we tell everyone what's important and what's not important. Like we could just say what is important and everything else is below the line. I don't know. Have you had any need to demonstrate like urgency and importance and stuff like that?

CJ: Yeah, and we, we actually had a similar discussion with our team. At the offset a few weeks ago where we were like, why do we need to put tasks individual tasks into projects? Like if I know that there's something that needs to be done Can I just like create a task assign it to myself and do it and we kind of made a A rough rule that like every task must be assigned to a project. And so we use 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, 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 they 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 like very little about. Like internal productivity and like us getting stuff done. It was like almost all about like, yeah. How do we communicate to other teams, how, and what we're working on. And yeah, exactly. Like where in the priority does their tasks fall? So, 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 Craftwork 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 2x 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, yeah, 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. That's part of another project. That's actually higher than this. And so maybe someday we'll come back to these 15,

Colin: those are listed as fast follows. And then how often does the fast follow actually happen? And yeah, yeah. That sounds very similar. I do like, I'm sure that there's research being done on this, but it's like that I've been able to point to in any project I've been in. I think what I'm coming to terms with on our, Team is that like, there is enough stuff going on for like a full time air traffic controller. Like, I guess that's a project manager really at the end of the day, but because of we're like parallel to every other team and there's things that can pop up tomorrow that need to go out next week that moves everything around. And so like the issue is right now we do the traffic controlling and the work and the follow ups and all that stuff. And so things get. You know, it's just hard to keep everything in sync. And I've still got note cards that I write things on. And I've still got a sauna notion. And very similarly, a lot of the Asana stuff, like using the built in project updates and project like analytics and stuff will be interesting. We've never used those as DevRel, but like being able to do like a weekly recap that goes up to people above us. So they know what we're working on. I think you mentioned like, was it 15 fives in the past?

CJ: Yeah, 515s. Yeah, yeah,

Colin: those kinds of things. I think we, we used an app called 15 five at panty drop and like, that was nice to like, what did you do this week? Cause there are some weeks where I do so much little tiny things, but if you then told me like, what was your impact this week? I'd be like, shit. Like, I know all those things needed to get done, but if we looked at like the core priorities of either our team or the company or whatever, did I move towards that or did I just like shuffled? deck chairs around on the Titanic type of situation. And so you don't always want to get caught. Obviously there's tasks that need to get done that roll up to someone else's priority that is core to the business and stuff. But just so that you feel like you have like autonomy and purpose and all that, it's like, you also want to be able to knock off like rewrite of the docs you've been trying to do or the migration of the enums, Right. So that you can put it behind you and say it's done.

CJ: Yeah. I think a lot of it too, on the tactical side, not on the project management side, a lot of it is about energy 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. So like having a mix of like stuff that you're pumped about and stuff you're, That, 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's buried somewhere, you know? So

Colin: I've been thinking about it more and more like a conductor of an orchestra where you have space and noise. Right. And so you have 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. And. 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. There's 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, thank. 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, and intentionally context switch. Cause yeah, to your point, you're going to burn out. You're going to leave if not. So

CJ: you feeling like, or I guess I'm curious like where you get your inspiration and motivation and vision from? Is it like the company, you know, the CEO is like writing some vision doc and then you're taking that 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?

Colin: 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 up 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 good developer platform or good experience. So like if the docs are wrong, let's correct them. Go get some quick wins and review and merge some PRs and ship some new docs and stuff like that.

CJ: Yeah, it's, it's a tough balance to strike. And yeah, like I think I've at least. Enjoy building stuff really quickly for people that I'm like interacting with day to day. And so, yeah, it can be, it can be challenging if the vision comes down from like super, super high up that field might feel disconnected from what, what you're seeing on the ground. And so yeah, I don't know, but yeah.

Colin: Well, in smaller companies, like you are closer to, like, the whole team can be in.

CJ: yeah, yeah, yeah, that is, that is nice.

Colin: versus like a discord, a stripe slack, like not everyone's going to be in the same room. So the vision can change and game a telephone and all sorts of stuff.

CJ: Yeah, totally. What else is going on? We already talked about DevRelCon. Have you ever read that book, Steal Like an Artist?

Colin: Don't think so. Still like an artist from Austin Cleon clone.

CJ: Yeah.

Colin: How is it?

CJ: So Mike sent me this book and I had, apparently I had read it before. I, I don't know. On my Goodreads it said that I had already read it. I, I might've listened to it, but this was the first time like reading the physical version. And I. Really liked it. I thought it was kind of, it was like 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 like newspaper poems or something like this, where he kind of like takes a newspaper and then uses a Sharpie to like black out parts of the words. And so what remains, it becomes like a poem. So it was like taking some other thing and then doing that. So there's like a lot of artistic little kind of blurbs and tear outs 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, like in, in my case, I was thinking a lot about like devs that I look up to and have kind of like followed their career over time. You know, major, you know, major folks like Jim Weirich and Sandy Metz and Gary Bernhardt, also like content creators, Ryan Bates, Abdi Grimm Kent Dodds, and then also, you know, people who I've worked with or collaborated with who I thought had like just insane work ethic and high productivity and we're just like really successful. But one of the recommendations was like, go find the people who you look up to and then figure out who are, who are the people that they looked up to and kind of like follow the family tree up and do research and try to figure out kind of like, The foundational reasons that, or, you know, kind of like core values that might've driven that. So that 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.

Colin: 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, 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 I 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?

CJ: no, I finished, I finished it. Yeah.

Colin: Does it apply at all to the literal steel, like an artist of AI and, and

CJ: that's interesting. It, it actually, it perfectly does. And here's how, so I think like one of the most core tenants of the book is basically this concept of like an artist doesn't just like, Imitate a, like the same exact artist. Like they're, they're not going to pick one person and do something just like them. What they're doing is like looking at a whole field, like 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 in stealing like just the good bits and then remixing it to be their own thing, instead of just being like, okay, I see, you know, Colin's got that really cool. Hat on, I'm going to put on the same exact yellow hat. It's 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, you know, just like yeah, exactly. Yeah.

Colin: Interesting.

CJ: but it was, it was interesting to me because I, I think oftentimes, When people are learning how to code, they say, Oh, I want to build clones of things. And it's a great way to learn, like, let me build a clone of Reddit or let me build a clone of Facebook, or let me build a clone of, you know, Netflix or something, just to try to get an idea of like, how would they go about writing the CSS and structuring the data model and building out the backend and whatever of all these different platforms, it's a great way to learn. Like little tools and tricks. But then at the end of the day, being able to take all of those pieces and instead of making something that mirrors perfectly someone else's site, you want to be able to make your own site that has, you know, the, all of the best parts or what you think are the best parts of those other sites. So

Colin: goes into the, the buckets thing. Like there are so many financial tools out there. And then like, we're like, well, we want to do it a little bit differently. And I had to laugh because I was listening to mostly technical and I guess Aaron Francis is also building his own tool, but like only for himself. And it's also going to be a project management tool. And also it's like a super app for themselves. And there's like, I just don't like the way that most people. do these things. And Ian was actually using a new tool that I'll have to find that does what a lot of these tools do, but doesn't do the budgeting piece. Because like, unfortunately, and fortunately, once you hit like a certain income, like you just need to make sure that the buckets are right, literally, right. Instead of the indiscreet. Like, do you want to categorize 20 transactions or do you want to just make sure the buckets, right? So good name, by the way, TJ,

CJ: Yeah. Yeah. Buckets. cjav. dev. We're, we're, we're, I don't know, maybe we've got to put up a domain for that thing and just like let people run loose. I, I hit up Stripe again with some feedback and we'll see what they say, but yeah, things are just still not working as expected, so I don't know. We'll see if it ever lands,

Colin: I'm hoping to have some more time to work on that and some other fun projects trying to get back into, I think we've talked about so many project ideas on here, the conference room, booking and calendaring and I'm feeling, feeling the itch. I need to steal like an artist a little bit and just make some stuff, even if it's not a net new thing, like just working on buckets and like, we know what we kind of want to see. I still am using co pilot very like. I don't do the transaction recording like I did the first month or two that I did it, but seeing the buckets and how it works has been helpful. But still stuff I would do differently and buckets itself. And yeah. I think there's, there's a big topic that we'll be able to talk about in a future episode as it pertains to co working spaces again, and business and, and all that stuff. But I think we can probably leave it there.

CJ: Yeah, there's your there's your cliffhanger. So you got to stay tuned. Yeah. Follow for part two.

Colin: Yes. Well, good hanging out. Where can people find notes for the show?

CJ: Yeah. Head over to buildandlearn. dev. And yeah, we'll drop links to all the resources we talked about. And yeah, we'll catch you in your earbuds next time. Thanks for

Colin: Bye friends. All audio, artwork, episode descriptions and notes are property of CJ Avilla, Colin Loretz, for Build and Learn, and published with permission by Transistor, Inc. Broadcast by