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