CJ Avilla

Co-Founders, Layoffs, Ruby Memory, Docs Product

Show Notes

In this episode, we'll touch on office setup and soundproofing, with a focus on effective techniques and materials. We talk about the challenges and strategies in finding non-technical co-founders for startups, emphasizing the importance of shared values and complementary skills. The episode also delves into the impact of AI on the tech industry, particularly concerning recent layoffs. Additionally, we discuss technical topics like API documentation, memory management in Ruby and Rails, and the art of content creation and screencasting.

Resources:
Full Transcripts

CJ: Welcome to build and learn. My name is CJ.

Colin: And I'm Collin, and we're back to catch up. How's it going, CJ?

CJ: It's pretty good. We usually record sort of midday, and for me this is a little bit later in the afternoon, so yeah, starting to wind down for the evening, and since it's the middle of winter, it is pitch black outside, which is very, a very common thing in New England apparently.

Colin: Yeah, I love that my camera is daytime, and yours is nighttime.

CJ: Yeah, it looks like, yeah, you look fresh faced and bushy tailed and ready to rock for the day.

Colin: I do have two very large Elgato

CJ: lights. Oh, okay. maybe that's it. You've got great lighting. Yeah.

Colin: a little bit.

CJ: Is that window that's in view of your camera? That's an actual window, right?

Colin: This thing?

CJ: the one on the other side. Oh, I

Colin: Oh, I see. yeah, there's a window this way.

CJ: not like a fake, faux light thing. No, okay,

Colin: Yeah, and this is not going to translate well to podcasting, but these little things behind me are a project that I haven't finished yet. we're going to make that door disappear.

CJ: yeah, it looks like maybe some sort of curtains or something, like

Colin: they're actually like sound absorbing, wood panels. So they're like walnut. Fronts with sound absorbing on the back. You, I think you see them in all the desk setups and all the YouTube. the new YouTube thing these days, but I'm also a sucker for them. It's very I don't know, Whiskey Room

CJ: I don't know, whiskey room vibes. Yeah, and it's funny because

Colin: Yeah. and it's funny because this room when I'm on my work calls, people are like, what room are you in? Because there's actually three doors behind me. And so everyone's we don't even understand why this room could even be in your house that you have three doors because one goes to an HVAC, one goes to a patio and one goes to the hallway.

CJ: HVAC, one goes to a patio, and one goes to the hallway. Roaring and so I put all these giant blankets on the wall on the other side of the wall that are like absorbing all of that roar And it helped a ton with just like sound quality But I also fight with the piano which is like right above me So the kids will be like doing their piano lesson mid meeting or whatever and yeah, it's interesting

Colin: Yeah. People like moving blankets because they're wool.

CJ: I

Colin: picked up like a target weighted blanket. It's like a 50 pound blanket that I have just pinned to this other wall. a lot, I mean it doesn't look pretty, but it's cheaper than a lot of the sound treatment stuff out there.

CJ: there. Yeah, mine are just giant moving blankets. They're just like two huge moving blankets that are, yeah, tacked up on the wall.

Colin: Yeah. Cause these things are cool behind me, but they're like, I don't know, 300 for two or two to four of them I think. And this blanket was like 20 bucks. So it's easy to spend money in AV stuff for sure.

CJ: West Boss, did like a whole series of videos about how he built out his office and got very technical about how sound transfers between things and, buffering, like even the wires in the walls and stuff like that. It's whoa, that's,

Colin: We should get him on for a show just on that because I think the three of us have done a lot

CJ: Yeah, just trying to like soundproof things is interesting. so I posted on Twitter the other day. one of my sons is in swim team once, once or twice a week. And the other, my other son is at home, didn't want to do swim team. And we were trying to figure out like what. What kind of activity could we do that would be interesting, engaging, and like enriching for him? And he loves telling people the news, just like anything that he learns about that he finds interesting. He'll just, as soon as he learns it, he has to run around and tell people. And so I wanted to start teaching him all these different tools for journalism, and just like how to go and talk to people. on the internet through podcasting or through video or through blogging. And so I put together this super short little course on Google Classroom where there's all of these little assignments for him to go through and build out a podcast. And so it's make a title and make a cover art and come up with a description and come up with an audience and then I followed along with, Descript's how to start a podcast flow, but then I boiled it down to what would this mean for a fourth grader? And what is this what kind of like stuff can we also do with AI? So really awesome tools out now. I don't know if you've seen, Google's like music effects labs things. You can do text to music so you can GPT generate a song basically that they can like use in his intros or whatever. So he's generated some intro and outro music and, started doing some recording today. So it's been really cool to watch him experiment with that and fun to just share what I've learned.

Colin: Podcasting is such a good thing for anyone to play with. Cause you gotta, you get to just play with audio. You have to think about what you're going to call it. You get to write a little bit, get to do the description, the graphics. it's a pretty good project.

CJ: project. Yeah, it's fun. once it's up and live, I'll plug it in a future episode so you can go listen, yeah, I think it'll be about gaming and Pokemon and stuff that he's interested in, so it should be good.

Colin: I think that's the way

CJ: all podcasts start. Tell

Colin: this other tweet that you had. You were looking for, kinda like non technical co founder type

CJ: other tweet that you had. I found a website called something like dev meets marketer or something like that, or dev meets sales, where it's At the time it was like, okay, Cupid for founders where you're do you know, founder dating almost? And like founder match, or like Tinder for founders. And I was just curious, like how people are finding co founders because oftentimes you hear from YC or you hear from venture capitalists that they want to invest in companies where there's multiple founders. I'm like, how are people finding who they're working with? so that was the first layer and the second layer was like, it's the new year and I've got a million ideas and things that I want to build and, In the past, a lot of stuff, I try to get it off the ground by myself and I think it would work much better if there were, someone by my side with complimentary skills, just like helping hack and promote and, mostly just like marketing and sales and talking to customers and validating different ideas and telling me like, that's stupid, don't go down that path or Hey, that's like a good idea. Or just being a separate, set of eyes and some, Yeah, I don't know. Some interesting things and conversations fell out of it. But, one thing that interests me about this process is that it is very much like dating. You can't just find someone on the street and say Hey, we should be like co founders. Let's go co found something like oftentimes at hackathons, right? You meet up just like random people and you try to get something off the ground in the weekend for startup weekend. But, I think there's a lot of like compatibility and personality type situations that go into this. I don't know. When you did CloudSnap, how many co founders were part of that?

Colin: there was just two of us to start with and at the time I was the non technical but more technical than most co founders so I kinda took on the CEO role. And then Chris took the CTO role cause he was definitely more technical than I was. and that did mean I rarely wrote code. Like I was reviewing things and doing a lot of prototyping more. I was more PM going out and talking to customers, trying to make sure that we had something that people would want to use and then know that when we build something, someone actually would be there to use it. versus sometimes people. go off and build a thing for years without ever showing it to anybody. and that, that can be really tricky. I think what you're talking about is being a technical person looking for a non technical co founder is really interesting because I think most people in tech have probably had people come to them with ideas. And that, there's, that happens a lot. And it's really hard to go through and figure out who's really serious about it, who's put their own skin in the game, They're not going to have, I don't necessarily think they should go and try to learn how to code and, had varying degrees success at that, but they've at least figured out, they know what their strengths are. They know what they're lacking. They know what they bring to the table. And that might even be like, I have customers ready to go. If you can help me build this type of thing on the other side of it, it's okay, we know we can build lots of things as technical folks. What are those gaps that you're talking about? And even just like when you're building something, you just don't have time to also go out and talk to customers.

CJ: Yeah, and I'm not saying that, technical co founders shouldn't talk to customers necessarily. I just think that, yeah, that's

Colin: They need

CJ: yeah, really bad at in the beginning. And, yeah, they absolutely need to. And. Going back to just like being a creator in general. I think oftentimes we're, maybe I'm speaking for myself that I'm like afraid to launch something or share it widely because I'm not super comfortable with it. And maybe when you are working with someone else, they can be like, Oh yeah, that's totally fine. Just like ship that and let's get some eyeballs on it and start getting feedback. And maybe they're more comfortable sharing it because it's not like their own creation, in a way. And so it gives them a little bit more

Colin: Having that divide helps. It's like a lot of people don't like to edit their own sounds and their own audio and podcasts and stuff. And it's it sounded great. And you're like, Oh, I can't do this. but what you're talking about is very true. Like YC and Techstars and a lot of these folks, they almost always look for people to have a co founder. Because their argument is, if you can't even convince one person to come along on this journey, like, why would we put money into it?

CJ: it?

Colin: but at the same time If you can pull off everything and even better if you could do it without investment. I'm becoming more and more of the don't go the VC route. more of the indie hacker bootstrapped approach but, if you're going to be doing that then it does help to have someone else who's, the other side of that coin. with the coworking space it's a little bit different. But myself and the other owners are a good, push and pull on, I get a little excited about something and then they bring me back to earth, which can help. So we want to be pushing forward, but it's always good to have a little bit of tension on that line so that we don't just fly off into space.

CJ: Yeah. The other thing that has been on my mind too is just in general, that co-founder fit, like how do you find someone who has a personality that gels well with yours, and where you almost kinda have to have Side gig values aligned with a vision that's aligned for okay, we're going to work on this with, nights and weekends with no payoff for, maybe even years. And then once it gets off the ground, maybe we go full time or I don't know, like, you know what I mean? Like, and trying to find someone who, yeah, shares those values and also can get excited about the same things that you're excited about is, yeah, it's interesting.

Colin: Yeah. There's an episode that we can link to from the Hammerstone. Dev podcast, and Hammerstone was a team of Aaron Francis, who we've mentioned before. And, Colleen, I am blanking on her last name right now, but they have chosen to separate and Colleen's going forward with Hello Query and Aaron's focusing on the things that he was doing at PlanetScale and some of his other stuff. And it's a really good conversation because It's them having a good breakup on a podcast they finally are starting to feel that like customer fit with their product, but it's not the end of the journey. It's the very beginning. that little bit of product market fit means there is going to be months, years of work to be done, nights, weekends, whatever that looks like, especially with families and things like that. And Aaron just kind of like, I. Can't do that right now. And it's also very good to be real about that. Cause sometimes co founders will take their other co founders for a ride when they aren't being truthful about how much time and space do you have in your life for these kinds of projects, which is, it's good to be open about.

CJ: about. There are a lot of really awkward and uncomfortable conversations that happen at that early stage. Even After like a startup weekend hackathon, I've had people like, pushing really hard in certain directions. I'm like, yo, we just worked on this for 48 hours. I don't care. do what you want with it.

Colin: Yeah. I start off weekend. Is an interesting one. I haven't seen those as much lately. I don't know if they've died off or just gotten less popular, if you win, I've fallen into it where we won one of the startup weekends and it was like, okay, we're going to try this. And we took a little bit of seed money and we did not get very far. But it's hard because, those, that team was put together on a weekend and they all happen to be in the same event. There was a little bit more intent there, rather than meeting someone at a Starbucks. but there's a guy who reached out to us, I think it was just through Twitter and the dev meetup, but he runs remotejobs. com. And He's the kind of person or he's like the non technical co founder, but he's teaching himself how to code. and he's hacking and doing the, using the templates that are out there, using the job boards and stuff. And he's built himself that nomadic, remote, lifestyle that a lot of people like to talk about. and I think he's doing that without co founders. So it really depends on how much space you have. In your life and all of that because, I could try to make the awkward segue here of what happens when you take too much money

CJ: and

Colin: grow too big.

CJ: there's really

Colin: there's a really good Silicon Valley, link that we'll put in the show notes too, but yeah, this week has been a rough week for tech layoffs. I think especially for companies that grew a lot in 2020, 2021. this week we've got, what, Twitch, Google, Amazon, Unity, and then, we just actually had layoffs today at Discord, which I can't talk too much about, but, by the time this comes out, it'll be almost a month behind us now. rifts across the board, teams getting smaller, all that kind of stuff.

CJ: that kind of stuff. Yeah, I thought, the bleeding was over and that teams did their reset in 2023 and that. we were going to go into 2024 with nice, healthy organizations, but totally not the case. And I don't know, yeah, I don't know what the deal is or how long this is going to last. It's a huge bummer, for everyone. I guess the other, piece of this too is that, like, how much is AI, impacting these jobs, right? I also, outside of These sort of like tech specific jobs. I also saw a bunch of people getting laid off from like movie studios and animation studios where they're like, yeah, we're not gonna need any animators anymore We're just gonna use like AI from now on. It's

Colin: Yeah, this role this week has been pretty content focused. So a lot of gaming industry, right? Unity Prime video, some Prime Studios folks So a lot and I think my friend who runs a lot of things in the tabletop RPG space Has shared that like it's flowed down where it's like gaming's been hit Tabletop things like D& D are not as popular or selling out as much as they were before. You know, there's groups like Critical Role that are doing really well, but kind of gaming, which I think is interesting. I don't know if we just gorged ourselves on content during the pandemic and everyone staffed up because of it, thinking the good times were never going to end or what the deal is. and a lot of people are upset that movies aren't doing well in the box office, but I don't know. I don't know if those are related whatsoever. I think it's just been like I'm excited to go see Dune, still in the theaters.

CJ: it seems to like a lot more people are creating content. we're making this podcast, right? And there's a ton of people who are making TikTok videos and YouTube shorts and whatever. And maybe just the sheer volume of entertainment. is getting to a point where, the big studios aren't able to keep up as much. It's almost in the same way that new, newspapers mostly lost all of the wind beneath their sails when, blogging and articles became popular. I don't know. but, yeah, it's a huge bummer for anyone who's losing their job,

Colin: Definitely. Yeah, if you're looking for something, we got, we'll put some links to some remote jobs and some tech job links in the show notes, because I've had a lot of people coming to me asking, what jobs I know about, somehow I've gotten that as like a reputation as the person to go to when someone's ready for another job, but

CJ: view you as a connector and someone who knows about opportunity. Yep.

Colin: For

CJ: Yeah. so Yeah, similarly, or along the same lines, we are hiring at Craftwork still, so we've got some super promising candidates that we're talking to this week, but if you are interested in writing TypeScript or Ruby and Rails and React Native and doing some machine learning stuff, we are, yeah, we'll likely be hiring at some point when you, when you hear this later,

Colin: Very cool. What are you, building this

CJ: this week? Gosh, it's been a really productive week. I was sick last week and so I felt sluggish and unproductive and this week has been super productive and I'm, yeah, it feels great. a lot of it has been API integrations. One of them is with this company called Deputy, which is a platform that we use for scheduling and timesheets. it's how the crew clocks in and out and the automations we're building is so that we can tell customers which crew members are going to be coming to their house when the project happens. And we can also build out like some calendaring and scheduling tools internally. So that's been super cool. we also use a tool called Post Hog, which is for like product analytics. They actually have a kitchen sink type situation. They do, yeah, product analytics, they also do a B testing. They also do like feature flagging and then they separately have almost like a business intelligence suite where they have like data warehouse type situation. And, It's, yeah, so an interesting tool and we've been using them for tracking, like front end marketing analytics and, UTM params and things like that. And what we're doing now is piping back different project and conversion type events back into post hogs so that we can measure like the full pipeline and start to get some proper attribution and figure out, which marketing channels are working and which aren't and. yeah, that's been pretty interesting. So

Colin: Nice. Yeah, I like Posthog because they've got all the data that you're, like, gonna want in one place so you can do feature flags,

CJ: rather than

Colin: trying to connect two things together and say, show this to people who've done this thing.

CJ: Yeah. It's been, pretty good product so far. Another thing that's been really interesting as we're researching business intelligence tools is. How many have Jupyter Notebook style interfaces now built into them? I think we looked at hex. tech and posthog and, Supa or Meta, Metabase and a few others where it's like, Oh, you can write SQL queries and get back a table. Or you can write Python to interact with that data that was just in like the previous cell. Very cool, interactive business intelligence stuff. I haven't messed with business, like BI suites since college. like Microsoft, BI or whatever.

Colin: Those ones are interesting because it's like, everyone needs one and when you get big enough, you gotta go with the big enterprise one and there's a bunch of money involved. I remember. At Strava, I think we started out using segments and they just quickly got too big for segment you still got to put that data somewhere. It doesn't get stored in segment. And so they were using something called Snowplow, which they self hosted and it's like an open source, BI tool in that vein of like customer events and things like that. All sorts these days.

CJ: totally. Yeah. And it's do you want a data warehouse or do you want a visualization thing that will just let you build dashboards and charts for your existing data sources? Or do you want, yeah, these notebook tools where you can have data scientists write all these different queries. And yeah, it's definitely been a learning curve there. Yeah,

Colin: Yeah, sending emails every fifth time someone does something, stuff like that, where it's oh, I don't want to keep track of that.

CJ: yeah. yeah, it looks like you're working on some, some more Docs stuff.

Colin: Yeah, so I'm stuck in DocsLand. mostly about things I can't talk about yet, but I can talk about what I'm trying to do. we have a thing in, we have our docs in a repo. And that's all public. So anyone can contribute to our docs today. And we have another thing that's in another repo and I have docs in there. And so I want to basically hydrate our public docs with those other docs and make sure that everything plays nicely and that we don't have like drift between. The two, so if you think of it as like an SDK type thing, how do we have versions of that, docs of that, but then we have the API docs, so very similar to when you were at Stripe, you guys had the Stripe SDKs, the API. Has versions, all that kind of stuff changes over time. So in the discord docs, we don't actually really have a good versioning system in the docs itself. It's more look at the table. What version are you on? That is what applies to you. So we aren't going to have versions anytime soon, but I'm just trying to think through, like, how do we not end up copy and pasting documentation? How do we not have drift? How do we not make it, manually corruptible? So that's what I'm working on.

CJ: on. Nice. Yeah, we've been talking a lot internally about generating OpenAPI specs so that we can consume it from our React Native app and our Next. js frontends. And I've been surprised that the tooling isn't really there in Rails. There's Oh, or like to, it's not there to like automatically do it for you. I expected you could just drop in a gem and say I'm using JBuilder. And then it would just figure out all the different types and be able to build the whole spec for you. But it's not that easy. The state of the art, as far as I can tell, is you have to write tests in our spec that then will map to, the open API specs that can be generated. But in order for those to get spit out, you actually have to write the tests and we should have the tests. And I'm not discounting that in any way, but it feels like a painful way to keep them in sync is to have to constantly write tests.

Colin: Do you then have to annotate the tests or do you annotate the source, the main source code for things like descriptions and labels and categories? Because that's the thing, we have an OpenAPI spec today, but we haven't finished, I think it's called tags and descriptors, right? we use one of the tools to generate, CLI, but because there's no categories and everything, it's here's all the functions you could possibly call. And so we're going to be adding tags, we're going to be adding descriptions so that, that CLI is more useful. especially when you have, start to have endpoints that look the same or get called at a different context.

CJ: in different contexts. Yeah, so within, I'm pretty sure you write it within the test. but I'm not, yeah, not sure.

Colin: That would make sense because then like where the spec is generated from all comes from one place.

CJ: Yeah. So the default when X is using our spec, we're using many tests, so there's going to be some differences there, but like when you say, okay, describe blah, it blah, or like it gets. thing, then I think like the test description can be used as like the body of the whatever you're describing. But yeah, I'm, I know there's some sort of, yeah, some sort of DSL that's in there that's like really tightly coupled. And if you want it to, generate good public facing documentation, I think it'll be challenging to maintain.

Colin: then you have to flag each of those if they're public or private. You have to flag them if they're going to be in certain versions. there's a lot that goes around this.

CJ: Yep.

Colin: if you want to have examples, if you want to have examples that can be run. I guess the test itself could be the example, but it's not always that clean. Yeah,

CJ: you generate the spec, then you can use the R Swag UI and R swag. API. Gems and those can just take in the spec and then they can make it so that you can, make test calls or whatever directly from the UI, like Postman or something, but,

Colin: Yeah, ReadMe has a bunch of really good, Libraries for this in JavaScript, but they have an OAS to snippet, which will take the, spec and turn it into a code snippet for you.

CJ: a code snippet

Colin: Like a curl, you can say curl, Python, whatever you want it to be. and then there's another one that will actually let you like run it. So that you can do the playground style type stuff and inject your tokens into it

CJ: type stuff and inject your tokens into it. Now that we're on the outside, it's oh, that's actually like super helpful.

Colin: Yeah. I'll send you some things cause I've seen, I've been playing around in those tools as well. And there's one where you're like, when you generate the whole JSON, it's pretty.

CJ: alarming. Yeah.

Colin: then there was one where that'll convert it to YAML, but also put it in folders of each resource. So you

CJ: So you can

Colin: see it better and you can go edit it. And then when you're ready, you can like have it rebuilt back into the single file. Cause it's not fun to go navigate that, by hand.

CJ: right? If you look at the. the OpenAPI spec for the Stripe API, which is publicly available, it's on GitHub, slash Stripe slash OpenAPI. it's insanely long. the YAML files are just monstrous.

Colin: And yours is in YAML. I think ours is in Jason.

CJ: JSON. Yeah, I think the repo might have several versions, but the, again, because Stripe isn't built with Rails, it's built with, a bunch of homegrown tools. The place where you describe what you want the resource to look like is all in the same spot as, the actual API, endpoints and resources are defined. And in that world, your documentation and your implementation are in the same place, and it was very handy. It was super, super nice. yeah, I was expecting and hoping for something similar in Rails, but No.

Colin: Yeah. and there's some other tools that will decorate. Open API. So once you generate it from your code base, you can have another step that decorates it. So maybe, you convert those more developer friendly descriptions into localized And, dev marketing, strings and stuff like that.

CJ: That's cool.

Colin: Yeah.

CJ: Yeah, I was half thinking maybe we ought to just feed all of our models and all of our J builders and all of our routes into Jet GBT and just be like, Hey, generate an open API spec for me. He's done this huge

Colin: might be faster. You never know.

CJ: Yeah, tricky to maintain something like that. And I don't want it to fall out of sync. is the, are the docs that you're working on, something that would have an API behind it? Or is it like more SDK docs?

Colin: it's something completely new, so it's not like an SDK for the API. It's different. But yeah, even now, like our own API specs, some people are starting to use it. It's still very much developer preview. We tell people not to build anything with it because it might change. especially around those like circular references, the schema references or errors, stuff like that. and we're trying to make sure that like our types match the types That you expect in this spec and things like that. there's some things that can be many types. That's always fun or a bunch of union types.

CJ: Yep. Very tricky. Yep.

Colin: We love some APIs though.

CJ: yeah, exactly. So another thing we've been working on a lot, craftwork is trying to get our memory bloat down a bit we're on render and we're still very small, tiny startup, we've only been running our rails out for about six months. And so we hope and expect that maybe a four gig box on render should do just fine, but we keep bumping against the memory. Like sealing there. And so the last couple weeks I've spent just like learning a ton about how memory management works in Ruby and Rails and just like keeping an eye on renders memory chart. And. One of the things that I learned was that you can just call gc. start. There's like this gc module that's available. and that will kick off garbage collection for you. We had a couple of jobs where I was like, Oh, at the end of this job, maybe I ought to just kick off gc. start because it's, uploading a bunch of images and creating a whole bunch of stuff. But, so that was interesting. And then. Ruby comes, out of the box, Ruby uses an allocator called malloc. It's like the default allocator, I think, for C. But you can switch that to different allocators, apparently. And one of them is jemalloc. Which, on render, you just set an environment variable. That points at some SO thing and then it starts back up and is better at memory. handles memory fragmentation better and, yeah, just helps avoid bloat a little bit. I was also super excited to upgrade to Ruby 3. 3, which we did, and that actually gave some like pretty noticeable, like speed improvements, which was cool. And then, yeah, we, so we use, Sentry for error tracking and alerting. Shout out if you want to, sponsor the show. But the tools that Sentry gives you for looking at memory management don't work on render. render is agreed to support the agent that comes from Scout APM. And so we've been exploring and using the free trial for Scout this week. And it is pretty cool. seeing all the different, background jobs or controller actions and then how much they increase the memory ceiling, Based on the methods that are called or whatever and you can see traces and they give you a lot of details about here's how many allocations that were made as part of this and here's your N plus one queries and here's like specific methods that are taking a long time. so still learning a ton about Scout APM, which, yeah, it's been pretty cool. to learn about, but yeah, we still haven't, we still haven't completely solved it. But

Colin: There's been like a whole new discourse around the cost and time around using things like Vercel and Render and Fly versus running on a box yourself, or I know that 37signals has moved all their stuff off cloud, which It's probably just their own cloud somewhere else. It's just off public clouds. They're not running in DHH's closet somewhere. but I don't know. I still, I mourn the Heroku days of just slapping something up and getting it going. And I know render and fly and things like that are making that easy again, but I don't know. There's a golden age of Heroku.

CJ: Yeah. I think that over the last six months or whatever I've learned a lot about Render. And it's almost to the point where it feels like Heroku in that you just push and go, and there's like little things you gotta fiddle with now and then, but, I, yeah, I still think it's a little easier than using something like Docker or, AWS directly, but,

Colin: having to do real DevOps and having to go out and do all that stuff, like, when you are a small team, there's Pros and cons to it.

CJ: Yep. Absolutely. Yeah.

Colin: yeah,

CJ: Yeah. I don't know. it's fun. Memory management is interesting and I'm glad that we don't have to think about it usually. But, I think Ruby and Rails definitely make it easy to suck up all the memory.

Colin: right

CJ: it's all

Colin: and usually throwing more money at it works for a little while until you're like, okay We're spending too much money. Just throwing money at this thing. let's see what's going on.

CJ: Yeah. And oftentimes there's Oh, you could just do an includes here, or, Oh, you could just, exclude 95 percent of all of the records that were returned because you're not actually using them in any of these results. Or, Oh, you could cache these into a dictionary, And then reuse the dictionary instead of hitting the database a million times. yeah, lots of different little things, little tips and tricks for performance that we've still got to do. So

Colin: fine tuning This conversation reminds me. I got some heroku emails today from a project. We both worked on

CJ: project we

Colin: like, the build failed to release. I'm gonna have to go look at what that is

CJ: have to go look

Colin: Because I haven't touched it in years, so we'll see.

CJ: touched it

Colin: We'll check in with Julie and make sure her business is still running.

CJ: I'll check in with Julie and make sure her business is still running. I don't know, it's, part of me wants to move them off and move them to render. I'm gonna wait, I think, a little while until SolidCue has some time to, to bake a bit. I don't know if you've looked into it too much, but I'm excited to not need to use Redis and just have you pay for your web, you pay for your worker, you pay for your database, and that's it, and you don't have, this extra little,

Colin: throw things on the queue.

CJ: the queue? Yeah, exactly. Little thing dangling off on the side, but,

Colin: Yeah, I think a lot of the infrastructure stuff is why I haven't finished my Google Calendar Discord app. Because I'm getting into that point now of needing to like subscribe and unsubscribe from events and get notifications. And I'm like, this will work for me. But the moment we have a hundred people using it, or a thousand, that's a lot of notifications of meetings and calendar events being moved around and all that kind of stuff.

CJ: right? Yeah, going back to the, the deputy integration that we're working on, A lot of that is calendaring and schedules and whatever, and as people. a shift goes up, and then an employee gets assigned to a shift. Then those shifts get published, and keeping all that in sync, if people move around, or they, they're, they call in sick, or they, have to take some PTO, or whatever, and all of those things are shifting and changing, and trying to keep it all up to date is, I don't know. It's tricky, and that's one of the things that's sucking up memory, is okay, we're, making a bunch of API calls, and creating a bunch of objects to build all these automations, but, yeah. Screencasting.

Colin: Yeah, I guess the only thing I'm really learning right now, other than wrangling GitHub repos, is I've been going through Aaron Francis's screencasting course. So Aaron has like a unofficial sponsored slot on this show today. And a few of the last episodes too, but yeah, it's really well done. he makes amazing video content. So it's great to see like him take that skill, turn it into a course showing us how to do that. because I really want to be able to get good at creating more video. Like we just don't do video content for our work right now. my colleague has done a few videos, but it's not like our core muscle of pumping them out. I think we have editors and stuff too. So it's not that we have to do all the work, but. Gonna practice with my own stuff, I've got some ideas for projects I just want to build, but build them either on stream or do some recordings,

CJ: Yep. Yeah, the name of the game is Make That Content, right?

Colin: Yep,

CJ: Is, what are the, the software tools that he suggests in that course?

Colin: I'm still in the pre tools phase in the course, but I think he's doing Final Cut or something like that. I don't think it's like ScreenFlow, which is what I'm most familiar with.

CJ: Got it. Cool.

Colin: So I'll check and

CJ: and,

Colin: we'll revisit this in the future in a future episode, but I'm mostly excited to see his shortcuts because he does a lot of like record, stop, record, stop, and how do you bring all those together quickly and drop the ones you don't want.

CJ: And am recording, like screen recording directly from Descript. And, by recently I mean I've only made 3 or 4 videos this way. But, my previous workflow was like, record in ScreenFlow, do some editing in ScreenFlow, export, wait 20 minutes, load it into Descript, wait 20 minutes for it to transcribe, and then do some more editing, apply Studio Sound, do a bunch of stuff, export, wait 20 minutes. It was like, oh my gosh, all of those, Advent of Code videos. It was like an hour a day of just waiting on something to like export or import or transcribe or whatever, even on an M1, Yeah, completely working on revamping my flow to make it as smooth and short as possible so that it can be like, okay, record something real quick, get it up, get it out, and, yeah,

Colin: Yeah. we're doing that with this too, right? we're using a different tool. So this will be the first episode that we're recording with Squadcast. So this will go straight into Descript. I'm curious to hear if it sounds any different, but We were already paying for this one, so we got rid of Zencaster, sorry Zencaster, we love you.

CJ: you.

Colin: but we're gonna see how this works. One last tool, cause I was doing the same, we would export it from there, then share it in Dropbox back and forth to get it into Descript, and Are you editing? Am I editing? It's just let's get this out the window as fast as we can.

CJ: Yeah, right now it's just fun, right? We're just doing this for fun. We don't have editors. We don't have anything. We're just hanging out. And, yeah, so the lower touch, the better. I think, one interesting thing for screencasting that I started playing with was, I think it's called key caster. yeah, key caster, you can like brew install this and it shows what you're typing, as you're typing it. And. The goal there is make a couple videos about, keyboard shortcuts and things for, moving around and, switching between windows and tabs and how do you edit text and then move between lines and,

Colin: how do you see CJ's Vim wizardry in action?

CJ: That maybe, yeah, I haven't done any Vim videos yet, but, Yeah, I think that'd be fun. It'd be super fun to just

Colin: you're recommending that everyone install their own keylogger.

CJ: It is a keylogger and there's, it's funny on the GitHub repo, it's all open source. So the, on the GitHub repo, they're like this, you don't want to let people have your key access to your keyboard. Like you can, here's how you download this thing and go make sure that it's safe or whatever, but yeah, it's going to become. Just an on screen keylogger for my videos, we'll see.

Colin: I think I will be adding that to my personal computer, not my work

CJ: computer. Yes, yeah, it's yeah, I don't know. Fun stuff, but. Absolutely. Yeah.

Colin: Very cool. I think that'll do it. As always, you can head over to buildandlearn. dev and we'll include links to all the show notes and resources that we talked about today.

CJ: Alright, that's all for this episode, folks. See you next time.

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