Rach lives in Australia, so for our otherwise U.S.-based team, that’s about as remote as it gets. We’ve always been remote at CodePen, so we have it built-in to our culture already, but that doesn’t mean we don’t have to plan for it, think about it, and adjust things to make sure we’re all doing the best we can. Writing is a fundamental aspect of it all, but even that is funny sometimes because you have to choose where those words will go that make the most sense. Right now, it’s a balance between Notion, GitHub, Slack, and even our codebase itself.
Time Jumps
Sponsor: Split
This podcast is powered by Split. The Feature Management & Experimentation Platform that reimagines software delivery. By attaching insightful data to feature flags, Split frees you to quickly deploy, measure, and learn the impact of every feature you release. So you can safely deliver features up to 50 times faster and exhale. What a Release.
Start raising feature flags (and lowering stress). Visit Split.io/CodePen for a free trial.
Transcript
[Radio channel adjustment]
Announcer: Today, on CodePen Radio.
Chris Coyier: Hey, everybody. CodePen Radio. I have -- and it's been a hot minute -- Rach Smith from the CodePen team. Hey, Rach!
Rachel Smith: Hello. Good day. How ya goin'?
Chris: I should call you Rachel, but you can't Google Rachel Smith. You'll get all kinds of incorrect ones. You've got to search just Rach.
Rachel: Yeah. There's a famous lady, some presenter lady called Rachel Smith, so that's why I use Rach for my website.
Chris: Google knows.
Rachel: And all my online identities. Yeah. [Laughter]
Chris: If you cut out the E-L you get right there.
Rachel: Yeah.
Chris: Super active blogger. Anyway, we had this kind of micro idea to talk about... I want to talk about how we work because that's just fun, generally, and kind of the point of this podcast, generally. You're a thinker on how you work. Related to CodePen or not - or whatever - you blog about it sometimes, just ideas and concepts of how we can be better at what we do.
But it has been a while since we've talked specifically about remote work. A quick look back at the archives, 2016, episode 77, we talked about remote work, in general.
Rachel: Wow.
Chris: Yeah. Because we were wondering, like, "Surely, we've talked about this before," but it's been a hot minute. We've never ever had an official CodePen office. It just so happens that Robert works with me now here in Bend. But not official, and it's not the headquarters by any means.
We've always been all remote. COVID made that a bigger thing - or whatever - but it's still just constantly talked about as a concept. Is it good or not? Is it effective? How to be effective - and that kind of thing.
We are well qualified to talk about that.
[Laughter]
Rachel: We've been doing it for a little while now, haven't we?
Chris: A little while, yes.
Rachel: Before it was cool. [Laughter]
Chris: You'd think it'd be a bullion, but I feel like remote work should almost be an integer value in the database because it's kind of like, "But how remote really are you?"
Rachel: Yeah.
Chris: We're all the way remote. Not only do we not have any offices whatsoever, and we don't really get together anymore, unfortunately. Maybe someday, but everybody is all kidded up and stuff.
Rachel: Hmm...
Chris: It would be a real thing to get us all together at this point.
Rachel: [Laughter]
Chris: But not only that. Rach also lives in Australia, which is about as far away as you can get from most of us who live in the United States. And so, time zone-wise and distance-wise, that's real remote. You really have to think about that and be considered to make this work, and we have for tons of years.
Rachel: Yeah, I feel like I've been lucky in that you guys have been willing to work with me on the fact that I have, you know, my schedule doesn't line up exactly with the U.S. usual workday, so there are lots of companies in the U.S. who won't do that. They say, "Remote U.S. only," because they don't want to deal with other time zones.
Chris: Yeah.
Rachel: So, I'm always appreciative that you guys are willing to work around that. We have our main meetings, like our all-hands meetings and stuff sort of later in the day, so I can get to them.
Chris: Yeah, well, it's not later in the day for you, right? You've always adjusted your workday really early.
Rachel: Yeah. Yeah, well, later in your day.
Chris: Yeah. Yeah. Yeah.
Rachel: Yeah, it's not until, like -- I mean it's not until 1:00 on Western Time, so by the time you're getting to Central and Eastern, it's getting pretty late for, like, a meeting.
Chris: That is pretty late.
Rachel: Yeah, which in most companies you would have that meeting like first thing on a Monday. You know it's kind of like a kickoff for the week's start meeting, but we have ours at the end of the day on Monday because it's my Tuesday morning when that happens.
Chris: Yeah. Yeah. I wouldn't want to have it... I don't know. [Laughter] Sorry it is that way for you, but now I'm so used to it. I don't know that I'd want it right this second.
Rachel: Right. First thing.
Chris: I need a minute in the morning. But I was on the East Coast on fricken' Monday, which I had planned... Whatever. I ended up missing the all-hands because I forgot how weirdly late in the day. It's 4:00 p.m. on the East Coast in the United States.
Rachel: Right. Yeah. It's so late. It's so late.
Chris: It's so late.
Rachel: For the East Coast, yeah. Yeah.
Chris: Okay, so there's the time zone thing, but what does that mean then? We can talk specifically for you and generally. But it does mean that because our overlap hours are so early in your day, if you want to catch anybody at all, it's like you better do it.
Rachel: You know people often want to know what it's like remote working and the challenges of remote working. One of the, I think, things that come up is you have to be very sort of intentional and organized about your communication, and especially so when you're dealing with time zone differences.
When you work in an office, you're under the assumption that everyone is there roughly between the hours between 9:00 and 5:00. There's probably a bit of differentiation there, but usually everyone is around at the same time. And you sort of generally have a whole day to just go and grab someone if you need to talk about something. But when you work remotely, you don't have the luxury of just being able to interrupt people whenever you see them because they're in the same office as you.
Usually, purely remote teams like ours, because you are remote and you have flexibility, most, I'd say, would have sort of somewhat flexible hours too. Definitely, in CodePen, it's not expected that you're sitting at your computer from 9:00 a.m. to 5:00 p.m., and a break for lunch.
Chris: [Laughter]
Rachel: We allow -- we have... As long as you get your work done, it's okay if you need to dip out for a school run, or you need to go do an errand. So, you can't always be guaranteed that that person is going to be online to be able to get your message when you want to get it to them.
Then especially for me, by the time I've hit midday my time, everyone at CodePen -- besides Alex. He's a night owl, though. He's different. He's up all night coding crazy hours).
Chris: Sometimes.
Rachel: Yeah. Yeah. But most people on the team are done for the day (over in the U.S.), so I can't be asking anyone questions after midday my time. It's like I'm on my own.
If something comes up for me and I need a question answered, I need to make that happen in the morning if I'm wanting to get an answer for the next day. Then if it's not in the morning, I have to be okay with the fact I'm not going to get an answer until the next day. So, I have to organize my work in such a way that I'm never blocked, you know, like I'm never, "Ooh, I can't do anything until I have this question answered, so I may as well just sit on my hands until the next day." That's not an option for me, so I kind of always have to have a few things lined up that I can do so if I run into a roadblock for one thing, I can move on to the next and still make progress somewhere.
Luckily in CodePen, there are a million things to do at any point in time, so it's not like... Imagine some jobs would be like this is your job and that's it. Then if you get blocked on your job, then you're blocked. But because I do 100 jobs here, there's always something I can do.
Chris: But I wonder if that is part of your nature - or whatever. But you happen to know a lot of different languages and parts of our stack and all that. I wonder if it was partially fueled by this idea of, like, "I never want to be blocked, so I will learn everything." [Laughter]
I can't just be like, "Oh, that's a Ruby thing. I'll just wait for tomorrow."
Rachel: Yeah.
Chris: How about I just learn Ruby and then it won't be a block?
Rachel: [Laughter] I think that's my personality. It's helpful in that I can unblock myself from things. That's been the result of years of doing that, of being like, "I don't know this. All right. I'll just learn it." Then learning the thing.
But I think because I've just never been satisfied with software projects. I started as a front-ender, and you'd send the info to the backend. Then it wasn't satisfying for me to go, "Oh, well. It's over there, and I don't know what's going to happen to that info now."
I'm always like, "But where does it go? What happens? What happens next? Then where does it go?"
I'm just always curious about how bits of information goes from all the way from the front to the back of the stack. And so, that's why I end up learning, like I learned Ruby while I was at CodePen. I've learned Go. Any backend language we've come up with, I'm not happy with just going, "Oh, well, I'll just let someone else do that," because I'm like, "But I want to know how it works too." Then I end up learning it.
But the side effect of that is that I don't -- I'm never blocked for a to-do. There's always work that can be done, which is great when you are a remote worker. And that comes up a lot.
Chris: Once you crack the nut, too, it's kind of like, "I don't know. It's not that weird." Whatever. It's fmt.printline instead of console.log.
Rachel: Exactly, and that's, I think, a lot of developers will find that once you've learnt two or three languages, any subsequent languages just become easier and easier because you've already got so many of the models around previous languages. And even just the ability to Google stuff. Once you know how to do something in JavaScript, you can be like, "Well, how do I do this in Go?"
You can frame it like, "How do I do this? How do I map an array in Go?" Because you already know it's called "map an array" in JavaScript, you know what to Google. Yeah, so it's just a lot easier.
It's a for loop, by the way. everything in Go is a for loop. [Laughter]
Chris: [Laughter] It's a for loop.
Rachel: There's no mapping. It's a for loop.
Chris: Yeah. It's getting easier for me. I'm a little behind you, but it's been illuminating to me to work more at the data level and the backend level and feel more comfortable across the stack. It's been nice, but there's still... [Laughter]
There's still so much where I'm just like, "Well, that's it!"
[Laughter]
Rachel: Yeah.
Chris: Mm... Yeah. It's a lot of build-related stuff and config. The dev op stuff is just... I definitely don't feel comfortable there yet.
Rachel: Yeah. Yeah. Dev ops, I'd say, I know enough to do some damage.
[Laughter]
Rachel: I know enough, I could take down a site if I wanted to. But I'm nowhere near... I wouldn't call myself a dev ops developer. I'm definitely not even intermediate level. I'm sort of a novice in that. I know enough to get around.
Chris: It almost feels like early days for that stuff getting better anyway. For example, we lean on a lot of that GitHub actions kind of stuff, and I'm not sure that there's a local dev for that that's super good. You can kind of tell when Alex has had a long day at the GitHub action shop because you see commit, commit, commit, commit, commit, commit, commit because all he's doing is triggering another action to see--
Rachel: Hmm... Trying to get the action working.
Chris: Yeah, so it's a commit. Then, you know - I don't know - read Reddit for three minutes while the thing is doing it's thing and come back, see if it works.
Rachel: It's interesting, too, because a lot of the software is being built around -- you used to have a dev ops team, right? You used to have a bunch of guys in a server room. And if you wanted anything operations done, you had to go to them.
My husband, Andy, has worked on teams like that where you have to email a guy, and he's always like some neckbeard dude, and he really has no social communication skills. You're like, "Please, I just want to get my build onto this server." But you have to go through a human. And there's lots of software like GitHub actions and stuff built around just eliminating the people from that process.
Someone like Alex who is really more of an ICE-like, Go developer type than a dev ops person. It allows him to build all of the dev-ops for CodePen, which is no small feat, and to have the software do a lot of the heavy lifting on that, automate a lot of things, and that sort of thing. Yeah, that's helpful.
[Guitar music starts]
Chris: This podcast is brought to you by Split, the feature management and experimentation platform. What if a release was exactly how it sounds, a moment of relief, an escape from slow, painful deployments that hold back product engineers? Free for teams and your features with Split.
By attaching insightful data to feature flags, Split helps you quickly deploy, measure, and learn the impact of every feature you release, which means you can turn up what works, turn off what doesn't, give software innovation the room to run wild. Now you can safely deliver features up to 50 times faster and exhale. Split feature management and experimentation, what a release.
Reimagine software delivery. Start your free trial -- Oh, that's generous, huh? -- and create your first feature flag at split.io/codepen. Thanks for the support.
[Guitar music ends]
Chris: We talked about -- or we're going to -- we planned to talk about just kind of communication in general. It's just a little obvious. There's no job in the world which doesn't benefit from good, clear communication. Written communication is always valuable. Surely, people that work together in the same office benefit from good, written communication too.
But all that just gets cranked up a notch when you're not face-to-face, you're all remote, and all that. So, we've talked about tools like Notion a bunch of times just because it just happens to be a tool that we use for a lot of written communication and other kind of stuff. A very important tool.
Dee and I just talked a few episodes ago about replanning how we're using it for our PM tools and stuff. It truly is important. But you can't half-ass any of that stuff. It's got to be just paragraph after paragraph - or whatever - of good, clean data on what the heck is going on around here.
Rachel: Yeah, it's one skill that you sort of need to develop as a remote worker is written communication because it's really hard, especially dealing in software. It's really hard to clearly write what you mean. There's been so many times where I've written something, and I've gone, "I've done it." Then I talk to a person who read it afterwards, and I'm like, "Wow, they really did not understand what I said at all."
It's so difficult to get that right. I think, if you're a remote worker, you suddenly find yourself having to write a lot, explain yourself a lot, even if it's just in Slack. You can't be putting weird, nondescript, vague stuff in Slack because it's just confusing to people. So, you have to articulate yourself well, and it's hard. It's a real skill to communicate that way.
Chris: Even the where. I don't know if struggle is the right word, but you might even--
I think, two or three times, this happened today where somebody is like, "I have some thoughts that I need to think about," or share or something.
Rachel: Mm-hmm.
Chris: Then it's not actually in Slack. They give you the one-sentence thing of, like, "I was thinking about this, so - link to Notion. I wrote it over there. Go read it over there."
Rachel: Yeah. Yeah.
Chris: Sometimes it's like, "Oh, I wrote a bunch of code, and I need you to think about the code," so where that writing is at the top of a PR.
Rachel: In a PR. Yeah. Yeah.
Chris: Then it's like, "The PR is going to go in, so I'm about to lose essentially what's at the top of that PR, so a new version of what I'm trying to articulate needs to be the message of the merge commit of the PR." [Laughter]
Rachel: Mm-hmm. [Laughter]
Chris: I don't know. In Notion itself isn't just like, "Oh, it's a page," and then you read the page. It's not like a Google doc. It's like, "Well, yeah, but where in Notion?" Is it the special one-off page just because you used it like a Google doc? That's actually pretty rare for us. More likely it's part of a card that has other associated tasks to it or something. Or it's meeting notes that are sitting on a calendar.
Rachel: Sitting in a database. Yeah.
Chris: Yeah, so this, like, where do you write stuff? I wouldn't say you struggle just because I don't see a lot of us asking questions about when and where I should do that, but it is interesting to me how scattered it is.
Rachel: Yeah, it is. We're such a small team, I feel like it's manageable. I can't imagine what it would be like to be, say, on a team of 40 devs and they're all communicating this way. You just spend most of your day trying to keep track of all the stuff people have put everywhere. [Laughter] It'd be crazy.
Chris: I don't know. It'd be tempting to be like, "Just please, people. GitHub only," or something.
Rachel: Yeah. You'd have to sort of be more strict about where you put things. We've fallen into a groove, and it works for us. But we haven't really explicitly laid out where some things go, beyond things like if it's an issue. If it's a bug with the site, we put that in GitHub issues.
Chris: Yeah.
Rachel: But if it's a feature request coming through support, we put that in Notion. We do have guidelines for those sorts of things. As for communications about our individual work each day, yeah, I'll put things in Notion. I'll put things on my GitHub PR. I'll put things in Slack.
Chris: [Laughter] It's really just those three, but the balance is tricky.
Rachel: Yeah. The other day I thought, "Well, I put this thing, this info--" I wanted you and Stephen to have comments on a PR I'd added, and I thought, "Will I put the request for comment in the PR description?"
Then I thought, "No because the commenting system for GitHub PR sucks. I hate reading them. They're just so awkward, and they don't chain well."
Chris: I know what you mean.
Rachel: Whereas in a Notion doc, you can highlight a section of the document I've read and then leave a comment on that specific section. It's just so much better for discussion.
Chris: Right.
Rachel: And so, I was like, "I'm going to put the request for comments and the information in a Notion doc." Then I link to that Notion doc from the GitHub PR. But that was literally a thought process I went through.
I was like, "Will I put this here?" I was like, "No, I'll put it in Notion because it's easy to add comments and be more specific there."
Chris: Right. If there's any degree of speculativeness of what's going on, too, our culture so far hasn't been like, "Do a PR." I think that might change. We literally talked about it today a little bit. We should almost do more speculative PRs.
Rachel: Mm-hmm.
Chris: Maybe we'll just close the PR and not be too sad about it.
Rachel: Hmm...
Chris: But PRs, generally, here, mean they're going in.
Rachel: They're going in.
Chris: At some point.
[Laughter]
Rachel: Oh, like we say they're speculative, and then they go in anyway.
[Laughter]
Chris: They're going in!
Rachel: It looks good to me. [Laughter]
Chris: I know there are these two kinds of comments on PRs, and they're always... You can comment on code, which is nice, I think you were saying.
Rachel: Mm-hmm.
Chris: I have a comment about this file, this piece of this file, whatever. Those can be resolved, which I kind of like because you're like, "Okay. We talked about it." Boop. It's gone.
You can always find it again, but it has some resolution to it. Or you can just leave a comment on the PR, and those you can't resolve. Those are just a permanent piece of conversation forever on that PR, which I always found obnoxious. And I don't have--
Rachel: [Laughter]
Chris: Because you always have to make this choice. You're like, "Okay, I'm going to comment on a piece of code." Am I adding a single comment or am I starting a review? I'm like, "I haven't decided yet, actually, so..." [Laughter]
Rachel: I always do single comments because I'm like, I cannot commit to a review right now.
Chris: Yeah. Me too.
Rachel: I don't know what I'm going to do in the next 30 seconds. [Laughter]
Chris: Well, there's this secondary problem is that if you say, "I'm going to start a review," and then you walk away, they never see that comment.
Rachel: Alex has literally been burnt by that multiple times with me. He's Slacked me and been like, "I left comments on your PR," and I'm like, "Okay."
He's like, "We can have a meeting about it tomorrow," and then I go to the PR, and it's like--
Chris: Nothing.
Rachel: One comment, and I'm like, "Okay, it seems weird that he wants to have a meeting about this single comment, but okay. We'll have a chat."
Then he's like, "So, what did you think? Did you read my stuff?" And I'm like, "What stuff?" Then he's like, "Oh, no!" He forgot to submit the review, and I didn't see any of the comments.
Chris: Yeah.
Rachel: It's so annoying.
Chris: Why?!
Rachel: Yeah.
Chris: I literally don't get it.
Rachel: I think they've had a lot of feedback about how much PR UX sucks on GitHub. I get the sense that they've had a lot of feedback, and I think they are trying to rewrite it right now. I think it's something they're working on.
Chris: Hmm... That's right in their wheelhouse because I always found that interesting that PRs are not a Git concept. They're an implementation of Git concept.
Rachel: Exactly. Yeah.
Chris: GitHub can do whatever they want with PRs.
Rachel: And lay it on top. Yeah. Mm-hmm.
Chris: Which is, I think, a cool position for them to be in, even though there are so many features of Git that you're like, "Actually, that's just built right into Git."
Rachel: It's just Git. Yeah.
Chris: Just Git - all the branching and whatnot. All right. Good documentation and all that stuff. Then there's just meetings, in general.
Rachel: Mm-hmm.
Chris: I was just circling back to remote work, in general, and stuff, and finding time for that. Also, a thing that you've got to get the balance right on. I don't know that we've ever nailed it, but we tend to go in these phases where we're like, "We always got the one." As far as I know, it's never been questioned. Like we have an all-hands.
Rachel: Yeah.
Chris: Sometimes the format of it changes a little bit.
Rachel: We have to see each other once a week, at least. [Laughter]
Chris: Yeah. Right.
Rachel: Yeah.
Chris: I think that would be weird. Nobody has ever been like, "Can we nix this?"
Rachel: Can we nix out of the one meeting? [Laughter]
Chris: Yeah. [Laughter] But then there are sometimes when we start new, bigger things where we're like, "We should be meeting every day!" You know? Then we just have tons of meetings for a little while, and it never lasts because I think it's draining to us all in a way, and we're just like, "But we need to work, too." [Laughter]
Rachel: Yeah, out strip... You get heavy on decision-making, and then, at some point, you can't make any more decisions until you get a bit more implementation done. Then that's when things slow down because it's like, "Oh, we need to actually implement these decisions we've made before, before we can make some new decisions."
Chris: Yeah.
Rachel: Then we slow down. I think CodePen, it's funny. Most people complain about how their company--
It's funny. I listen to Cal Newport, and he talks a lot about work and remote work and how to organize your work. CodePen is the minority in how we structure our work. All this asynchronous documentation and stuff, it's just something developers are used to doing. Because we're a company filled with developers, we're totally comfortable with making Notion docs and writing in the GitHub PR and all that.
Most companies are like, "Oh, we'll just sit on Zoom calls all day." Rather than have to do any asynchronous stuff, would literally just be in meetings on Zoom all day, and that's how we'll do remote work. People get burnt out on it because they're like, "I'm in Zoom calls and I have no time to actually do my work. But because nobody is willing to do anything asynch, everything has to be a conversation." It just becomes this sort of like Zoom call nightmare. I think that's the standard for a lot of remote knowledge work companies that are not dev focused.
But CodePen almost swings the other way. Our natural inclination is to never have meetings. [Laughter]
Chris: Never. We're trying to get it down to zero meetings. Just the one.
Rachel: Yeah. [Laughter] Yeah, so we have to sort of push ourselves to be like, "Ah, no. We should probably have some meetings about stuff," because if you get on your own for too long, you can sort of head down tracks that would have been either unnecessary or you make decisions that would have been better off if somebody else had had some input and had a conversation about it. It's just funny that our company's default mode is the opposite to what most people's default mode, which is have a meeting about everything.
Chris: Yeah. It's just a cultural thing.
Rachel: We're like, "No meetings." [Laughter]
Chris: Formed early, yeah for sure. It's true. People say that about startups and stuff that early DNA gets established and it just lingers forever.
Rachel: Yeah. Well, your guys' original thing, wasn't it before you started CodePen? Was it Wufoo?
Chris: It was the same deal. We had one meeting a week.
Rachel: You used to have only one meeting a week.
Chris: Yeah.
Rachel: And you just work all week on your own stuff. You wouldn't even talk to each other all week, basically.
Chris: Yeah.
Rachel: The only time you even had a conversation.
Chris: That's right. It was kind of before Zoom and stuff anyway.
Rachel: Yeah. You'd have one meeting together on Fridays or something.
Chris: Mm-hmm.
Rachel: I think that's how you three started the company, and you went to CodePen. You just were like, "Oh, we'll just keep going doing it this way."
Chris: Well, because that was successful. Then we went to SurveyMonkey, and it was like, sure, that company is successful too, but it was just all in-person work all the time. We were like, "This is horrible," so despite the success, I'd rather go back to the other thing. [Laughter]
Rachel: Yeah. [Laughter] Yeah, but I think the true thing is a happy medium because CodePen is such an expansive product.
Chris: Yeah.
Rachel: I mean it's so much bigger than Wufoo ever was in terms of the breadth of what this product covers and what it supports, so you can't really just not talk to anyone about what you're doing all week. It just doesn't work.
Chris: Right. Yeah, it's getting wild here. You know there's a tiny little aspect for you specifically that factors into this, too, that I think is interesting is that you are not only remote and in Australia, but are -- I don't know if part-time is the right word for it or contractor structured.
Rachel: Yeah, part-time. I probably do about 22 hours a week on average. That's sort of roughly the amount of time I work. It sort of goes up and down.
Chris: Mm-hmm.
Rachel: Because I've got two small kids, that's what I wanted. This started when I had my first baby, and I just wanted more flexibility in my week. I wasn't really interested in working 40 hours and having my husband work 40 hours and trying to fill all that time with childcare.
Chris: Mm-hmm.
Rachel: I just wanted to see my kids more while they're so little and before they're at school, so that's what I asked you guys if we could do that. I do roughly 20 hours a week.
Chris: Yeah.
Rachel: And that's what we do now, and I love it. I honestly don't know if I would ever go back to 40 hours a week because I just feel like I reckon I'd do 30, like if I had full control of my schedule. Maybe when the kids are older, I'd go for 30.
I just feel like 40 hours a week, for some people, certainly, they can do it. But for me, I just don't feel like I can give 40 hours of my best to work for a week.
Chris: Mm-hmm.
Rachel: Then why bother?
Chris: I'm so curious about that. It seems like that from the outside.
Rachel: Yeah.
Chris: It seems like the 22 hours you do are just really, really strong.
Rachel: Yeah. The way I think about when I was full-time, I sort of went to half-time, and I feel like I could get 75% done of the full-time work that I was doing. Even though I'm cut back to half the hours, I'm producing sort of 75% of what I was doing at full-time, and that's because those 20 hours, I'm giving it my full attention.
When you're coding, you can really only do six hours of hard concentration a day, and then you're just spent. You cannot do any more than that. It's just garbage what comes after that.
Chris: Right.
Rachel: My job is a lot of that. I don't have a lot of admin or meetings and that sort of thing. It's a lot of just thinking about hard problems, trying to solve problems, trying to code.
Yeah, I just feel like it's so much more efficient to just put in a good 20 to 30 hours work. Instead of spending that ten hours faffing around at work and doing a lackluster job, just reclaiming that and being like, "I'm not working those hours. I'm just going to spend that on my personal life." At the end of the day, you still have good output.
I'm all for the 30-hour workweek or 4-day workweek or whatever people talk about now.
Chris: Right. Right. Right.
Rachel: I'm like, "Let's do it! Forty hours is too much."
Chris: Do you think it fell together naturally, though? Or is it literally just because you have less time, you just know that that's what's ahead of you, and there's just less of that faffing or whatever? Or did you have to find that? Did you have to be like, "Okay, I only have... I don't know. I have to think about this more"?
Rachel: What's the law where you make something fit?
Chris: Yeah, the space. Yeah.
Rachel: The amount of time it's allocated, it's very much that. When you approach your week of, like, "Oh, my God. I have these things to do and I've only got 20 hours to fit it in," you just change your mindset, and you just get in, and you do it.
And I also think about what's the most effective thing for me to be doing right now, and it stops me from going down rabbit holes of, like, less effective, I guess, work because I don't have time for that. You know? Whereas if I had a full workweek, like Monday to Friday full day, I think I would have a different approach. I'd be like, "Oh, I've got time to do this because I've got a full week to do it." You do sort of change your approach when you have limited time.
Chris: Yeah. Yeah. I think this little special software world niche kind of fits that mold a little bit. The work happens in this Aeron chair looking at a computer.
Rachel: Yeah.
Chris: It's not like you've got to be like, "Well, I've got to drive out to... I've got to drive 45 minutes away, shoot some video, drive all the way back, download the video, edit it."
Rachel: Yeah.
Chris: There are constraints if that was your job.
Rachel: Oh, totally.
Chris: You literally can't get it done in 20 hours.
Rachel: Yeah. It's like a developer IC is perfect for this. I have some time in my day. I sit down. I smash it out. We have meetings.
Chris: Mm-hmm.
Rachel: Probably one meeting a day max, and maybe I'll have a second conversation with somebody else, so I will have a couple of hours of meetings max in the morning. Then the rest of the day, I can do it whenever. That works for this role.
If I was the manager of a team of 15 devs in some sort of organization where you have that sort of thing going on, I probably couldn't work 20 hours a week because the devs I was managing would need me around more than that. It's sort of just the nature of this job lets me work a part-time schedule, which is amazing.
Chris: Yeah. Mm-hmm. IC, that's where it's at. [Laughter]
Rachel: It's all about that IC.
Chris: All about that IC.
Rachel: Work in a tiny startup. Well, we're not really a startup anymore. Just a tiny company. [Laughter]
Chris: Yeah, I've always struggled with that. Are we, though? I don't know how it works.
Rachel: Andy said to me, "You guys aren't a startup. You finished starting up years ago. You're just a little company now."
Chris: Yeah.
[Laughter]
Chris: Yeah. We're just too old for that stuff. Okay, well, thanks for talking to me, Rach. That was good stuff, everybody. Remote work, it's pretty cool. Tech, everybody loves it.
Rachel: Mm-hmm.
Chris: Take care of yourselves. Be good. We'll get Rach back again soon. Everybody, clap really loudly for Rach in your cars.
[Laughter]
Chris: Okay. See you later.
Rachel: All right. See ya!
[Radio channel adjustment]