Build and Learn

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

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


Creators & Guests

CJ Avilla
Developer Advocate @StripeDev. Veteran. 📽 Building with Ruby, Rails, JavaScript
Colin Loretz
I like to build software and communities. Building software at @orbitmodel 🪐 Coworking at @renocollective 🎙Sharing software learnings on @buildandlearn_

What is Build and Learn?

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?


Welcome back.

Doing pretty good.

How are you?


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.


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.


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.


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.



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.


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.




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


I like that.

They had this term.

I don't even know if it's a real
world, but that dot documentarians


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.



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.


like, what am I doing
with my life right now?



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



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.


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.


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.


So it's like a lightning talk, almost
like a weekly lightning talk about

the Stripe API for internal folks.


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.




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.


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.



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.


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.



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.


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.


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.


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


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.



Are you able to pull it
up, to pull up Asana?

I'm just curious how many
tasks I have assigned to myself


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.


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.


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?


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.


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.


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.


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.





those lines,

Oh, go ahead.


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


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.


always go that way.



You know how it is.

I was gonna say, that's okay too.



All, I'm curious about the calendar stuff.

Cause we've been also fighting calendars.



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.


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.


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.


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


Like I'll use, Jumpstart rails
for that most likely and do that.

So yes,


so begins the, the coworking space
software that you've been fighting

against building That's just
starts over here at the calendar.


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.


Just launch it from the ID.



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?


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.



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?


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.




Sounds like fun.

Sounds like a lot of good stuff to learn.

Should we wrap it

I think let's do it.


at time.

Thanks for joining us.

As always, you can check out our
notes for the show at buildandlearn.


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.


Bye friends.