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.
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.
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.