Slow Productivity, Write The Docs

Show Notes

In this episode, you'll hear about the Write the Docs conference in Portland, a must-attend for anyone in the tech writing community. CJ and Colin chatted about the unique, community-focused vibe of the event, which was akin to RailsConf or RubyConf, and shared some standout talks. One highlight is Calvin Fung's "Beyond Words: Strategies for Leveling Up Your Tech Writing Career," where he details practical tips for documenting your work and aligning it with your job description to advance your career. They also discuss creative ways to enhance documentation using interactive elements, and offers tips on how to get involved and meet people at conferences.

You'll also hear about "Slow Productivity," Cal Newport's book that has us rethinking how they manage their workloads. We'll discuss the book’s core principles: (1) doing fewer things, (2) working at a natural pace, and (3) obsessing over quality. This leads to a deep dive into managing distractions, the anxiety around being constantly responsive, and the value of deep, focused work. Plus, they share updates on fun projects at Craftwork, like organizing painting crews with a drag-and-drop interface and rebuilding a pricing engine. Finally, they touch on their DIY approach to calendar management and Colin’s adventures in learning Unity for game development. This episode is packed with insights and practical advice for balancing productivity and creativity in the tech world.


Full Transcripts

All right. What's up? How's it going? Colin? Welcome back. Doing pretty good. How are you? Great. there was a conference this last week, right? The docs I've heard really great things about it. And a lot of my docs writing friends, have given talks and recommended going before. And I think, it was one of those that I've always wanted to go to. so yeah, how was it? Yeah, it was great. this one was in Portland. There is an Atlantic one that's virtual and then an Australia one that's dates and stuff are going to be coming out. So for our global audience, if you want to check out the Australian version or tune into the virtual one, all the talks, thankfully go online too. So even for the Portland one, they'll be coming up, but it was really cool to have such a, Specific niche topic instead of it being like a generic tech conference. Or I think a lot of tech conferences lately are like product announcement conferences for the companies that run them. so like Stripe sessions is next week and it's fun, but it's very much, big feature launches. thought leadership bringing in, open AI to come chat, for interviews and stuff. What I liked the most about write the docs is it felt like community conferences like RailsConf or RubyConf very community focused, very just lovely community smaller. So you actually get to meet people. and they had a bunch of really good talks and like an unconference lightning talks, things like that. So I, I actually was a volunteer for this one. So I was helping, speakers get miked up and make sure their slides are working and everything. And a little hack if you're going to a conference, to get involved. I think this is because I've run too many events, but I can't really just enjoy. Sitting in the audience, I need to be like doing something and it helps me to then meet the speakers. going from getting them set up to, talking to them afterwards and then adding them on LinkedIn and hanging out, at the, at lunch and stuff like that. It's just, it's a good way to meet people if you don't know who's going to be there. so free little tip for you. That's a great tip. Yeah. were there any talks that really stood out so I was still aware of all the talks cause I was in the wings. So I was there in case like Mike's died and stuff like that. So I was listening to all the talks. a good friend of the show, Calvin Fung, he was one of the speakers. And he did a really good talk that was focused on how to document and track your work and tying it to your job description and levels so that when you have a conversation about getting to the next level or getting a promotion it's not left to chance like And how to work with your manager to prove that like the list that you're following and the artifacts you're creating to prove that you're ready for a promotion are the ones that they agree with. so there's no surprises. If you're a single writer on a team and you don't have a really well defined job description, then Like basically like you, you make one for yourself and you track it and you're using like a progress tracker, like in a video game. that talk we'll definitely share when it comes out, but I think it was very much appreciated by the audience where it seemed like a lot of people were either looking for work or trying to figure out how Break into that next level of, I've been doing everything right, but I'm getting passed up on promotions or new projects, things like that. sometimes the things that are happening in our head is not necessarily what's happening in reality, or we just do the work. I'm very guilty of this. Like I'll just do things because it's my job and I don't necessarily go shout it out there and then nobody knows that it happened. I take those for granted because they're easy for me. But you should document them and have that little like brag document that you can use for reviews. Yeah. This is something we've talked about a couple of times in the show, having a brag doc or a set of five 15s or some sort of, documentation or just writing down what you're doing. Journaling what you're doing week to week can be super helpful. Super helpful to just like in terms of motivation, but also to make these arguments. That looks like an awesome talk, from Calvin and it is called beyond words, strategies for leveling up your tech writing career. So I'll have to go watch that. it was good. That one, honestly could apply to any job. but I think for documentarians, especially like they don't always, they're already writing a lot. So writing about the writing or writing about what they're doing is not always the first thing that they reach for. there was a really good talk about using this one's pretty, relevant to you, which is having, you've done so many great videos on programming and Stripe and how to build things. And it was a lot about like how to use other things than just words in your documentation. So how to include. illustrations, graphs, videos, but they are big thing because we've always talked about on the show how maintaining video based docs is like extremely time heavy and expensive at the end of the day. And they actually made the call out of it's boring. your videos are not boring CJ, but it's boring to just show code on screen. And it comes out of date so fast that like video should probably be used for concepts that don't go out of date. And then those are evergreen and you can update the words around it maybe every now and then you might need to come in with a new voiceover or whatever, but they actually use drawings instead of onscreen. Because you do have a little bit of, called like key man risk when you have a certain person who's known as the face of the docks or the face of a company. we saw this a little bit with planet scale and, Aaron Francis too, with everyone thought. you know that he's the face of planet scale to the point where people thought he was the owner of planet scale. Yeah. but, yeah, so pretty cool. Just, different ways of thinking about that. One of the talks was on tool chains for authors where, we have things like open API specs and all these great tools like Markdown, but man, some of the tools out there, like a lot of authors still do their work in Microsoft word, And having labels and tags in a word doc that then get generated into a schema that then get turned into a printed book. Like that talk, I was like in pain watching the stuff that you had to do for Microsoft. but then she had also done a bunch of more, online first tool chains too. some of these companies you're documenting things and it gets really, Printed out on paper delivered to a manufacturing floor. And anytime there's a change to it, it has to be reprinted and put back on the floor. We take this for granted that we can just push and merge, PR and it's done. but yeah, working in the physical world is, it's always a little bit more challenging. So Totally. one of the talks that looked really interesting in terms of the title that I would love to go back, and check out is the one about, interactive code snippets, like in the docs. It looks like it's called code in content using dynamic interactive elements in your technical writing. Yeah. So that one was from Taylor from Redockley. They talked a little bit about Mark doc. They talked a little about MDX. they talked a little bit about redock. Lee, it wasn't like a sponsored session, but it was cool to see, like, how do you verify and validate that like your code samples work? And, I would say that this conference I think was more writers than coders. So a little bit more mysticism around. Docs is code a little bit like I think like a git for technical writers would be a big hit with this crowd well, so maybe that'll be a talk submission for next year. But sweet. Yeah. It, I was curious what the composition was at least, or your perception of it in terms of dev rel versus docs, writers versus engineers that build docs products. yeah, it was a pretty good mix It was a lot of writers. I like that. They had this term. I don't even know if it's a real world, but that dot documentarians Okay. writers, because you have ops and CI and CD, you have dev rel, who sometimes writes the docs, sometimes doesn't, in our case, we wear the technical writer hat. We also are the editor and the deployer and, we'll do videos and stuff. But, There were some people who work on open API stuff. There were all sorts of across the tool chain. So from that perspective, it was cool because you're going to be meeting, it's not just, Oh, I'm a software engineer at X company. It's, I'm a tech writer for a life sciences tool that you've never heard of. And there's a high bar for getting that Because tooling spits out information that needs to be right. So it Some of my favorite colleagues from Stripe were docs writers so I might have to go to the next write the docs just to try to bump into some old homies. We'll see. I think we should take a build and learn goes on a road show. We do a live at ride the docks. Yeah. Yeah. It'd be a blast. so last episode you teased this book called Slow Productivity by Cal Newport. And, uh. we agreed that we were going to read it by the next time we were recording. And I was like, you're ready. And this is like a meta realization while trying to listen to a book about productivity, or about like slow productivity in particular. I recognize that I don't have. Seven hours or whatever in a week where I'm like, just free to chill and listen to a book or listen to podcasts or whatever, like between walks and like all this stuff. And I found myself listening. We'll get into the content of the book, but I found myself listening to sections that were like. if you're multitasking and, here's an example, like the person is doing this and they're filling out these documents for HR and they're doing that and whatever. And they're doing all these tasks poorly and slowly, and it's causing them all the stress. And I'm like, listening to that while I'm trying to multitask myself, like submitting or like reviewing a PR and responding to something on Slack and doing 10 other things. I'm like, wait a second. I like, I'm literally being told in my ear that this is bad for me. Like I should slow down a little bit honestly, some of these books, they, you could be reading it when you have all the time in the world and you're like, this book is so like obvious to me, but books like this, and I would say essentialism and atomic habits, like you can read them. And if you don't have this problem, you don't get it. And if you are doing what you're talking about, it's like a lightning bolts. Yeah. like, what am I doing with my life right now? Yep. Absolutely. It's a good wake up call. it was, yeah. so I guess like, the first thing you shared was a podcast episode. and so I went and listened to that first and I thought that it did have a pretty solid overlap with the content in the book. I can't remember what the name of the podcast Yeah, the podcast was the afford anything podcast, which I think it was a good foil to talking to Cal because, Paula pant is like in the fire community. She's a real estate investor and she's very much would self describe herself as a, hustle or, In the best, in the good way of describing that, like she's go all the time. She's got lots of big things she's trying to accomplish in her life. and you can actually see it in that interview and we'll relink it as well, if you don't have time to listen to the whole book. Cause you can see her struggle a little bit with the idea of not being on Twitter, or not being on social media. And he does make a big case for the fact. It's that's wasting your time. if you really want to. do these large tentpole milestones in your life to produce books of, great work or whatever. you can get distracted in the small really easily of I need to do 20 different tweets this week and see which one goes viral. And it's is that really your audience? Or is it just, spending time and I saw this with bootstrap web too. one of the guys over there was talking about how he'll just, he's spending every morning now crafting like a bunch of tweets and hoping one of them hits. And I was like, that's Half of every day that you're spending on Twitter. And I find myself spending less and less time on Twitter. I don't know that's the best place to put all that energy. maybe your blog, your newsletter, things like that, where you control that makes sense, but ultimately just like the title of the book, it's going to be a slow climb. Like when you look at Cassidy Williams, newsletter subscriptions over time, I guarantee you, it's not a hockey stick. It's probably the slow March of putting out a newsletter every single week for years. And just getting more and more subscribers and she's writing thoughtful content each week. It's not like a bunch of little pithy tweets that you hope one of them gets viral for some, clickbait reason or something like that. the connection that I only made after listening to the book was that slow productivity is named after a lot of other phenomenon that came before it. one of them was slow food. or something like that, right? Like instead of fast food, it's like being super intentional and slowing down and really enjoying the meal. And you sit down and there's all these different like courses that come out and you're enjoying each of the different flavors and things like that. And there's been a bunch of other quote unquote slow, movements, but, yeah, slow productivity is really interesting. There's three different core tenets, One is do fewer things. Two is work at a natural pace. Three is obsess over quality. And, I think part of it that struck me the hardest too, was like, it's something I've been struggling with a little bit. I can't remember how much we've talked about this on the show is that, we've done a couple of personality type tests at Kraftwerk just to figure out where people are on the team and how they fit with each other. And one of the results from the tests shows you basically like what you think a good employee should be. Versus what you actually are or something, or like what you think, someone should be doing versus what you think would be like good for you to do. And that mismatch in my head has been becoming more and more obvious that I think a good employee should be hyper engaged on Slack or discord or email or like all of these places. And, your personal SLA should be super, super low. And you want to respond to everybody and unblock and make sure that you're not the reason why anything is slowing down and also be checking off lots of different tasks and committing tons of code and writing, like shipping PRs and shipping content and shipping this and shipping that like, that's what I've painted in my head is the picture of what a good employee is. But the reality is Oh, in order to do good work, you've really got to like, Slow down, pick one major project that is actually going to move the needle for the business. Even if that means like ignoring slack or ignoring other things in lieu of your big project. and yeah, so that, that kind of struck me as okay, shoot. I, I want to have really impactful work. But I'm not able to do that if I'm spending most of my time, being hyper reactive, hyper responsive, and also on the like treadmill of trying to just check off as many tasks as possible per week. And so it's Oh, it's actually better if instead of shipping 20 features a week. You ship half of a feature per week, but that feature ends up being like a really big, important feature or something, like, think the challenge with that is, are you actually shipping 20 features? If you look at things. Yeah, exactly. And like when 20 features and shipping none? Yes. Or are the, are the 20 features like, small things like bug fixes and, oh, now we can order the list this way, or, now we have some other like really simple CRUD interface to do X, Y, or Z, or we have this simple API integration versus a whole new product area or something that's very particular to our business or something. Yeah. I think some of this is a little at odds with startup culture too, right? We're like obsessed over quality and this natural pace. It's okay, if we only have so long to prove this out, can we really obsess over quality if we're like, maybe we're working on the wrong thing and we need to do a few, hits a bat type of situation where we need quality to a certain point? And natural pace is fine. But like at the same time, if we showed up and said, we're going to do all a hundred things at once to see which one works, like your team is going to get burnt out. So it's a give and take for sure. And to your point there, if I didn't defend my time and there are some days that feel like this very easily, I could be playing whack a mole on pings and emails. And alerts and other people demanding my time. And so I've been trying to figure out like this, like poll, polling or poll, like pulling work off of the thing where it's like maybe at certain times of day, I'm going to go check all the pings and then write down what I need to do later instead of doing it right away. Or do I have an office hours of some sort, right? And I love how some of this is people will make these demands of you because it doesn't cost them anything. But the moment they have to come to office hours, or they have to go add it to your list, they sometimes just are like, just kidding. I'm not going to fill this out. Unfortunately they might go ask someone who is not defending their time, or they go figure it out for themselves, which is what we hope. There were a couple of different tactics that I thought were really interesting. one of them is having a docket clearing meeting. So you just have a standing meeting. Once a week or something where you and your team, your, the people you're collaborating with, you run through, discuss anything that needs to be discussed, hash things out that need to be hashed out so that everyone can get back to work. another one was simulated pull, which is yeah, just, everything goes into some queue. And then when you are free from your like deep work, you can break out and then pull the things that need to be pulled. And then the other one, yeah, it was like holding office hours. And what I thought was really interesting is that Cal Newport, he like his software engineer by training, right? Like he's his computer scientist by training. And a lot of these things are things that tech companies do, right? Like the docket clearing meeting to me is let's have a standup, a weekly standup where we're going to run through and do like ticket triage and see like, where's the tickets. And then the poll based simulated poll is okay, all the tickets go into linear or JIRA or whatever. And you don't assign them to anybody until. The there's like free time for them to like, actually do it. The office hours is something that the support team at Stripe used to do where it was like, to avoid getting hit up all the time by account managers or product teams or whatever, they would hold office hours so that. on a weekly basis, folks could show up for that one hour and ask any questions they want and get direct help, on the things that they need help for. And I think that really streamlined a lot for them. Did people use those office hours? they did. And I think part of the key to it was that. Justin Michael, who's like amazing engineer for each office hour, he would create a custom like presentation. That was really fun. And like a, an infographic type situation that would show a Stripe workflow. And so it would seed the office hour with a discussion. So it wasn't just like, all right, I'm around during this time for you to come. Yeah. So it's like a lightning talk, almost like a weekly lightning talk about the Stripe API for internal folks. And Cause that's the pushback I've gotten so far when I've said I want office hours to no one, there'll just be you sitting here by yourself because and their argument was like fires don't happen when you schedule your office hours. I'm like, yeah, the point is this is not a firefighting session. And Yeah. Exactly. what is it? I know that there will be fires, so that's fine, but it doesn't happen. Everything should not be a fire. It's the important thing. Yeah. and I think the book really focuses on this idea that. They went through a lot of historical figures. If you zoom in on any one day, you might find them in a park or out in nature. And there was actually a lot of focus on nature. Granted, a lot of these people also were pre computer. Uh, some would argue we should all be spending more time in nature. Nature, but that when you zoomed out that there are these big, Nobel peace prizes and big discoveries and work, but they had that deep work time. And then they had that time to go away and think and let things run in the background process. Like thinking about, radioactivity, but I'm not done yet. And I'm going to go off and think about it and something that you do just clicks while you're out doing something else. Totally. Yeah. One of the things that we're doing right now at Craftwork is re imagining how we handle pricing. And one of the things we're planning to do is rebuild our price engine. And. I, like when I started thinking about this is when I started reading the book and then I've realized that, I, if I really just slow down and think about pricing and pricing engines and data models for pricing and things, then stuff starts to click into place and I started to make discoveries. Like a lot of times when I'm not at the computer, so I'm like, chopping wood in the backyard or I'm out walking the dog or I'm, driving to the dump or, just random times where I'm like, Oh, what if it did this? Or what if you could, build a rule engine that had certain conditions that apply this way or whatever. It's huh, it's like a paint by numbers where each of the little cells are getting filled in with color. In the background when you're not even thinking about it on purpose. And yeah, you've just got to wait until it's a full, bright, vibrant picture before you sit down and do the work, or do the like production of the work, I don't know. That's the same with sleep. Like we need sleep and we need time away to let garbage collection go. It's like your brain's gotta let go of some things and then discover some new things and make some new connections to other things and chopping wood in the backyard. you can't really focus on anything else, but your brain's still chugging away on something back there. That's right. Yeah. Yeah. I don't know. It's a great recommendation. I, yeah, I took a lot away from it and I think. There are likely several adjustments I'm going to make to the way that I think about stuff. is there anything you've already put in place or you're thinking about? I'm trying to figure out, I want to do office hours. So I'm trying to figure out how we can pull that off. I think the big one is like the days where I find myself playing whack a mole with pings and hunting down things That's how I don't want to feel so I'm trying to figure out like does that mean scheduling deep work? The problem is when you schedule it Sometimes it gets derailed by a thing and like I don't have control over When some meetings happen like if they're my own meetings sure, but all hands You know, most of those have been scheduled for the year, so I can move around those. We try to do no, no Thursday meetings and we record this on Thursdays, which is how I get away with that pretty easily. but there's always still some meetings that sneak in. So scheduling. Deep work. and ideally going and checking all the pings, like only when I need to, like right now I can see discord has a red dot on it. Maybe I should turn off the red dot. I don't know. Like then I won't know unless I go check it. And it's not telling me it's time to check it whenever there's a dot there. Yeah. One of the, one of the things that also like, became obvious to was the anxiety around response times. And I think part of this is working remote, because you can't just go over to someone's office and if you see the doors open, you go over and Poke your head in and have a conversation in real time. And there is this, again, going back to the, what is a good employee, right? are they always going to be responsive and reactive? It's yes. And so you start to build up this certain anxiety around your own personal SLA. Oh, since I'm remote and most of the team is not remote, if someone pings me on Slack, then, and I don't get back to them. within five minutes or whatever, then are they going to think that I'm just like out chilling on a beach? Yeah, exactly. Or not working or whatever. And so you start to build up that anxiety and that also ties directly to those like little tasks, right? Oh yeah, you're shipping PR, shipping, PR, shipping, PR, but really. If you have something that's big that you're working on, that's massive, you could continue pushing branches or whatever that show differences, but that doesn't necessarily reflect okay, I'm thinking super deeply about this for three days. And like in between meetings, it's a lot of like brainstorming and design type work. And how is that reflected relative to squash and bugs or like responding immediately to someone's pings on Slack with questions or whatever. the other side of this is it did also shine a light on my own behavior and ways that I could change. The way that I interact with people, just being a little bit more thoughtful about when I DM somebody or ping somebody on Slack, is this something that can be an email or should this be a linear ticket or should this be posted in the general channel? Instead of, or in a public channel, instead of a DM, so that maybe someone else who has context can jump into it. should this be a scheduled Slack message? Like maybe it's 7 PM my time and I'm wrapping something up and I don't need to ping the whole team and. At 7. 00 and said I could schedule it for 9. 00 AM the next day, to just be respectful of their time. Yeah. and yeah, it's it's about respect, but it's also about like productivity, right? Like you don't want to interrupt their flow. So I don't know. Yeah. I wish discord had the ability to schedule messages. but we can, we have the ability to send silent messages so they don't trigger notifications, but some people still check their dot, Right. Like it'll create a dot, but it won't send a Mm with Slack, I've. we use Slack for the coworking space. I do try to schedule things for the next day. If I'm, cause I don't really think about I'll be like, Oh, I have this thought about something we should do tomorrow. I'm not going to send it at nighttime when Kristen's not working because she will check it because technically quote unquote, her boss is messaging her. And it's I don't want to be the boss messaging after hours. so scheduling for nine, I love the whole, Or even just remind me about this later. But then you end up with a whole bunch of to dos that are just in this ether that are going to pop back in to, to annoy you later. So I still write, like I use these note card things. They're just like index cards, but. I still write down so much of my stuff so that I don't go into a sauna and then find four other things I could also be doing. it's more of like it, if it doesn't fit on the index card, then there's also a problem. if I can only do no more than 10 things in a day, even if I think I can. So some of that is nice in a sauna, you can create as many tickets as you want forever. and you're going to sign them to yourself and you can be, Super confident that you're going to get to it all and you're probably not going to. So yeah. Are you able to pull it up, to pull up Asana? I'm just curious how many tasks I have assigned to myself Yeah. Let's see. I have 69 to-dos four triage, and 204 in the backlog. Oh, wait, no, that's not just So yeah, I was gonna say, we do a pretty good job of not assigning things to someone until it's theirs, like Cal Newport recommends. So in Asana, I have five, which is very small. There is a list I can go look at that is the DevRel inbox, and there are way more than five. But, I also, in our public repo, there are 50 open PRs. so those have been open since 2022, some of them. So that's still going to be open, but those are things I think about. And I just need to schedule like an hour a week to go at least make a dent in them versus even thinking about them and carrying them around. there's that. I don't think it comes up in the book at all, but there's this idea. Yeah. Of carrying things around in a backpack and a lot of stress and anxiety is stuff that you carry around with you that you don't need to like, write it down, schedule it, whatever it is. It's like that appointment that you're like, Oh, I need, I know I need to do this and you keep writing it down for days and you don't do it, like just do it and you can put that thing down and you don't have to carry it around. And so those PRS are something that. They weigh on me, but they're always, they're not going to go anywhere. So I don't have to carry them around with me. when I was trying to get out of my IRS debt that I paid like years ago, it's funny cause the box is actually sitting right next to me. I physically carried the IRS letters with me, which is the most unhealthy thing you could possibly think. man, so now I have a box of them that I need to go have a bonfire with because they're here to be shredded But I think fire is gonna be a faster way of dealing with those and more entertaining and probably more cathartic in a way, right? yeah, don't carry things around. You don't need to carry around with you. Yeah, I'm going to go unassign a bunch of these things that have, I probably assigned to myself eight months ago and it just we're not getting around to it. and, yeah, the mental overhead of just knowing, or like trying to keep track of those tasks is immense. And. I think every time, the last times that I've left jobs, the last several times I've left jobs, there's been like this huge, like release of stress and anxiety right when you leave the job. And it's Oh, that's because I was carrying around in the back of my head, 45 tasks that like I knew had to get done at some point and then just was never doing them. and. Now that I don't work there anymore, it's not my problem and not my stress anymore, but, yeah, I think writing it down for us, it's linear, just like creating a ticket and not having it assigned to me. yeah. And then when the day comes that becomes the number one priority, then we'll figure out who's best suited to do it, who has an open, who has openings in their schedule, et cetera, et cetera. And we can ship it. nice yeah, Cool. Well those lines, Oh, go ahead. Yeah. We recommend it a hundred percent. we, built a fun feature this last couple of weeks where we can organize teams of painters into like crews. And there's a bunch of drag and drop, so you can, whatever, like we're all used to it, but it was fun to build with stimulus and hot wire and all this like railsy stuff. And it was a fun project because it was one where one of us built the data model. And get stubbed out like a rough UI and then someone else took it and cleaned it up and added some features to it. And then someone else took it and polished it up even more. And then it was just like this ping pong. It was a PR where everyone had commits like in the same PR, and then you ship it and release it to the team and share the updates. And, it was well received. So it was just like one of those really fun. Satisfying features to release that was like very well contained and didn't have a lot of like unnecessary complexity and, or scope creep and everyone got to get in and get their hands dirty. And it ended up being, yeah, as Mike would say, greater than the sum of its parts, in terms of contributions, which was, yeah, it was super fun. Was that all in one PR or is it a series of PRs? It was, this one happened to all be in one PR. It didn't, it shouldn't have been, it ended up being like a thousand lines, but by the end of the day we had all touched it and seen it and talked about it. It's always tricky when you're like, the API is in this other PR and the UI is in this other PR which relies on this other one, so sometimes it's easier to just do that. yeah, in hindsight I would have shipped the data model and a bunch of things first and then the controllers and then we could build on top of it and do whatever we want later and make incremental changes. But, always go that way. Nope. Yeah. You know how it is. I was gonna say, that's okay too. Yeah. Nice. All, I'm curious about the calendar stuff. Cause we've been also fighting calendars. So Yeah. So I have not had any time to play with the cow wind idea that I had, but I went, I don't know if I mentioned it last episode, but I was like, you know what? I'm just going to pay for Robin and we're going to do it. And I went to go pay for it and it was more money than I thought it was. So it was 1500 it is now 5, 000 and that number apparently is enough to make me. Code enough on an airplane while I was on the way to write the docs. uh, we now have a react app that is aware of all of the events that is happening today. You cannot book it yet, but that's going to be the next step is you can tap a button that will book that room for that time, if it's available for 30 minutes. So there's not any user logins. There's no who booked it. It's just, it's booked or not booked. If Kristen or I add events to the calendar, if someone messages us and says, Hey, can we get the room for a certain time? Then we'll add it to the calendar and it will show up. there's some things that like, these are all little rough edges that I'm building it in react. But I want to wrap it in react native because there's some fun features that you don't think about when you run an iPad 24 seven for years, which is screen burn. so Robin has a feature where at nighttime it dims the screen and then on dims it in the morning. So I'll probably do the same thing with react native and just do that. The cool thing is I don't need anything in react native. It'll just be the app will be, Running the react app and then in the background, it's just going to check the time. And then if it's a certain time range, the fun thing is I don't need to build any admin tools. I don't need to make it a setting. Like it's just going to be, is it nighttime? Dim it. Is it daytime? Don't dim it. you don't get to change it unless you change the code. so yeah, it turns out. 5, 000 is the price at which we're just going to build it ourselves. So Now it's okay, 5, 000 is an actual number that you can work backwards from and be like, okay, how much is my time actually worth and how long will it take and how much am I going to invest in it? And yes, that is actually smaller than that number. So, the MVP for this week has been a piece of paper put over all the iPads that just say first come first serve and everyone's getting around, using the rooms and. We'll see. I'm going to just keep working on it. I do want to add like user logins so that you can pre book. I think that's one where people just aren't always in the space when they want to check to see if a room is available, but, that's scope creep and that will go over 5, 000, it's fine. Like I'll use, Jumpstart rails for that most likely and do that. So yes, Yep. so begins the, the coworking space software that you've been fighting against building That's just starts over here at the calendar. yes. If it becomes more than that. once I have a user login, I could see us just adding the stripe IDs because people can't cancel themselves right now, which is good. Like it's nice. They have to come talk to us. We never are going to say you can't quit like we're never pulling anything like that. It's just sometimes they're quitting because they can't get a room or it's feedback that we want to have. And if it's, Oh, I'm moving, it's the beginning of the month. We'll refund them. We'll work with them to figure out how to leave. So it's more like a white glove, exit. You don't get to cancel yourself. It also means I don't wake up To a bunch of people having canceled without us knowing any reason why. So we'll see if we do that. It'd be nice to show like their receipts and their invoices and all that in there too. But we've been doing this for 15 years without that. So I think it's okay if we don't. The customer portal will probably give you quite a bit too, if you wanted to use that. True. Just launch it from the ID. But, Yeah. that's the collective stuff. And then in discord land, I'm been playing around with unity on the side, just trying to see what do developers have to do to make unity a possibility? And I am successfully getting all the events. So like I can see the events, but I don't see right. My, my game is just a cube that spins in 3d space. So the next step is to get the game to actually show up, and then start to do some multiplayer so that every new person who joins will be a new cube. and then we'll see about moving around, as the next step. But it's like a really weird line of is this a unity problem or a discord problem? Moving around as a cube, as a unity. Tutorial, not a discord tutorial. but getting that communication going back and forth will be a little bit of both. Okay. Cool. I have no background for Unity. What's it like, relative to like web development? It's cool. some of the things like it felt pretty heavy, like you have to download this, like unity hub, which then installs the software felt like Adobe but I've downloaded other projects and it's almost root, like environment managers. It was like, Hey, this was made in a different version of unity. Would you like to install the other version of unity? And is aware and launches it and stuff, which is cool. A lot of C sharp, which I do not know. So I am, I was like, this looks like JavaScript or, C, it's. net stuff. yeah, picking that up, figuring that out. there's probably some unity things like, a lot of people say doing things the rails way or whatever. I don't know if there is a unity way or what it is, but I'm still figuring those things out. I feel like when I started learning a little bit of mobile development and just the patterns of okay, this is a screen that's being like pushed onto a stack and then it's being popped off. Like the navigation contexts and the navigation controllers in mobile was just such a different paradigm from web that it was interesting to try to build my mental model around that. And there's just so much in the gaming. Space that I can't imagine how you'd go about like writing code that, uses different shaders and different, whatever, like stuff to display things in 3d, what does that even look like? Yeah. these tools definitely have. Looked at that, like with unity to make this shape spin, like you, you drop the shape into the scene and you have cameras too, right? So you not only move yourself, but also do you move the cameras? Does moving the keyboard mean the camera moves or do you move or both? And, you can write a script. So like to spin the cube, I wrote a script and then I dragged the script onto the cube and it just started spinning. So there's some of that like magic of the IDE that's going on where you're getting the tools matter here. And some of it's okay, once I figure this out, I also want to figure out play canvas and some of these other engines. and I'm sure they're all going to be a little bit different and some of them a little bit. The same, but, there's also, for what we're doing, you need to think about, can this run inside the web? Like we can build a game in unity and it will not run on the web. If you do like crazy shaders and lighting and stuff like that. So right. Interesting. Sounds like fun. Sounds like a lot of good stuff to learn. Should we wrap it I think let's do it. we're at time. Thanks for joining us. As always, you can check out our notes for the show at buildandlearn. dev. We'll have links to all the resources that we talked about. You can go check out the book, join our little book club, and we'll see you next time for 45. Nice. 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