Subscribe
Share
Share
Embed
In this episode, we celebrate the 20th anniversary of Ruby on Rails, reflecting on its impact and vibrant community. We share Rails origin stories from the late 2000s and early 2010s. You'll hear about different companies' reading and writing cultures, including practices like decision documents, meeting notes, and internal newsletters.
You'll hear updates on current projects, with Colin discussing a major documentation initiative and the challenges of balancing meta-work with actual work. CJ provides an update on a large-scale refactoring project, detailing the process of converting enums to models across various parts of the codebase. You'll also get book recommendations, including "The PARA Method" about note-taking and personal knowledge management, and "Unreasonable Hospitality" which explores creating exceptional customer experiences.
Finally, we discuss the concept of "unreasonable hospitality" and how to delight customers through thoughtful, personalized interactions.
Resources
Resources
- Unreasonable Hospitality - https://www.amazon.com/Unreasonable-Hospitality-Remarkable-Giving-People/dp/0593418573
- PARA method - https://fortelabs.com/blog/para/
- Amazon's working backwards - https://www.productplan.com/glossary/working-backward-amazon-method/
Creators & Guests
What is Build and Learn?
A podcast about software development and developing ourselves as software engineers. Hosted by CJ Avilla and Colin Loretz.
colin_1_08-01-2024_100949:
Welcome back, CJ.
Happy birthday to Rails 20th anniversary.
cj_1_08-01-2024_130949: That is
a surprisingly mature framework.
If I do say so myself.
colin_1_08-01-2024_100949:
is, it's two decades.
it almost can drink.
cj_1_08-01-2024_130949: Yes.
Recently I've been reflecting a lot
about the future of rails and wondering
about, you know, how easy it is to
hire people who want to use rails.
There's a few projects coming up where, it
might be something that I sort of build as
a microsite and hand over to someone else.
And I want to use rails to do that,
but I'm also like, maybe there's not
going to be someone to maintain it.
And I don't know, is that a concern that
you've bumped into from other folks or.
Thought about
colin_1_08-01-2024_100949: not so much.
Like I think, like you said, the
maintainability and like finding
people who know Rails, there's
like this convention that is
not in most frameworks, even.
net.
JavaScript, things like that, where you
can build your structure any way you want.
So if you build it in rails, like
someone who's familiar with rails
is going to be able to pick it up.
And I think the death of that community
is very much, largely overblown.
Like just because rails conf isn't
going to be happening anymore.
It does not mean that.
That all of a sudden, all these
20 years of rails veterans are
going to just disappear and
they're going to switch frameworks.
They're going to, they're
going to go to rails world.
They're going to go to Ruby comps.
They're going to go to blue Ridge Ruby.
They're going to go to, you know,
mountain West Ruby or whatever,
you know, all those different ones.
I think you'll be able to
find some people to support it
cj_1_08-01-2024_130949: totally.
Yeah.
I am also very optimistic and hopeful,
that, the community will continue to grow.
With the future of rails and with
large language models, helping
us write code is the power of
convention over configuration.
is so much stronger when you're using
an LLM and you're in a framework that
expects, you know, these conventions,
because the predictability of
the way to implement something is
influenced by like all of the past art.
And so being able to look
at most rails apps and like.
Squint your eyes a bit and see, okay,
they're all roughly the same shape.
And so if I want to do something that is
similar than, you know, co pilot should
be able to just spit out the things that
you want for rails, whereas it might be
much harder in other languages, especially
like really bespoke new funky languages or
when you're in a really funky environment.
colin_1_08-01-2024_100949: for sure.
Yeah.
I'm curious.
What is your rails origin story?
How did you get into rails?
cj_1_08-01-2024_130949: yeah.
In college.
I took a class about databases and
it was like, go implement, or learn a
bunch of different types of databases,
learn about the cap theorem and how to
set up relational databases, what are
no SQL databases and things like that.
And at the very end, the project was
like, To go set up a rails application
and use associations, rails associations,
and try to like, just see the power
of, an ORM and what it can give you.
And so my first ever
experience was touching it.
I think probably this was
probably like 2009, 2010 ish.
but then I didn't really do
anything serious with it until 2013.
colin_1_08-01-2024_100949: Nice.
cj_1_08-01-2024_130949: Yeah.
What about you?
colin_1_08-01-2024_100949: I can't
remember how I first found it because I.
I was already starting to use it.
So in two, let's see, in college,
I was the editor of the web
editor of the college newspaper.
And we were using a platform
called college publisher, which
was like all the schools used it.
And what was cool is that then
college publisher would go sell ads.
Against all these newspapers and then
put them in the website and we would make
commission make some money off of that.
MTV bought College Publisher and they won.
They took away all of the ad revenue
from everybody And they just plastered
it with MTV ads, like they thought that
was their target demo, And so we decided
as a newspaper to start our own software
and probably not the greatest idea in
the world, but we decided to build our
own CMS, for publishing the newspaper.
And that was when I remember, I
actually wish I had it on my shelf
here, but I've been and I have a
stack of my first Ruby on Rails books.
that, It's very timely and they're
hard to give up even though they're
like comically out of date now.
but I remember going to RailsConf
in 2007 and I don't know if it was
2007 or 2008, but someone got up on
stage and demoed this like Rails app
wrapped around Git and letting you like
create pull requests and see comments.
And that was like the
early version of GitHub.
And it was really cool because
this was like back when Y was
still going to Rails confs.
And there were a lot of people who
I just did not know who they were.
And they were not really
well known at the time.
So then we fast forward.
I remember specifically leaving that
first Rails book on an airplane.
and I'm a college student.
So you know, it's not insignificant
to like, Oh, I got to go buy
this computer book again.
And so I went and bought it again.
I hope someone found it and
came to, to be a Rails developer
after they found that book.
But, yeah.
We built the CMS, we ran it for
two years, because I think I
was like sophomore, junior year.
And then we quickly realized
that I'm going to graduate and
no one can support this thing.
And we moved to WordPress, and I left the
Rails world for a little while, and went
full throttle into the WordPress world.
but I think since then, the newspaper's
been on WordPress and still rocking.
and then I've come back to
Rails many times since then.
cj_1_08-01-2024_130949: In
terms of like use cases, a
newspaper is a great use case for
WordPress.
CMS, easy to edit, whatever.
but yeah.
Wow.
So you've been in the, in and
around rails for a super long time.
That's so
colin_1_08-01-2024_100949:
Yeah, it feels like a long time.
I know that we used to
have a Reno RB group.
I know that I think maybe even Twitter
helped me get into Rails, just because
I think it was built on Rails in
the early days, or at least Ruby.
And so it was the known quantity.
And I No, that I was on
Twitter pretty early.
I don't know when those all intersected.
It's like I could have ended up in Django
and my path would be very different.
Or like I found with WordPress,
it was just that you're not likely
to find a programmer who's going
to be running the newspaper versus
someone who can do WordPress plugins
and themes and stuff like that.
So just made sense.
cj_1_08-01-2024_130949: I remember
one of the first startup weekends.
I don't know if you remember the year
that startup weekends was kicked off
in Reno, but, we did the hackathon.
and then I remember being at the
collective, like working on our
startup after startup weekend.
And there was a Reno RB talk
that night at the collective.
And this was like back when
we were in the upstairs
colin_1_08-01-2024_100949: The clubhouse.
cj_1_08-01-2024_130949: yeah, clubhouse,
like locations, many locations ago.
And someone gave a talk on Capybara.
And also like just, I think it was, yeah,
just like different test frameworks that
they were using and having success with.
So it's probably 2010, 11 ish.
And I remember thinking, Whoa,
like Ruby is such a cool thing.
And we were building like our startup
weekend hackathon tool with net.
And I was like, Yeah.
I was like embarrassed that we were
using like a corporate, you know, not the
cool, hot new frameworks, that Ruby was.
colin_1_08-01-2024_100949: Yeah,
it was a golden era, I think, for
software and like the internet.
Just like people building things for fun.
I feel like some of that is coming back
around I think like less AI pendant
startups I don't think we need more of
those in the world as much as we need
these like fun little internet toys and
Things that you just do for fun and I
think Yeah, we'll see where that comes,
but like 2008, 2012, like that four year
period was just like such a golden era for
frameworks and tools built all on rails
or built, you know, tangentially, or,
you know, things like node knockout node
was starting to come up around then too.
so yeah, happy birthday to rails.
cj_1_08-01-2024_130949: Yeah.
Very cool.
Very cool.
I wanted to just like chat a little
bit about reading and writing
cultures and what your experience
was with them and what I've seen.
this sort of started because there's
a few cultural habits and things that
I picked up from Stripe that I really
like, and that I'm trying to bring over
to craftwork, the latest of which being
a decision document where you work
together in written word on a shared
Google doc to try to come to a decision.
I remember when I first started at Stripe
being insanely intimidated by how much
reading and how much writing there was.
Many things if you wanted to
get them done, the way that you
did that was by writing a doc.
A lot of stuff doesn't really
happen without, support and
stakeholder buy in and whatever.
And when you're at a small
company, you can just make a
comment and then it happens.
Whereas at a bigger company, you
need a little bit more organization.
And so by writing a doc, you can get
stakeholder buy in and iterate on the
thinking behind the doc and other things.
But I do remember thinking,
wow, this is a ton of reading.
And like the first month of Stripe,
I probably read more than I had,
like in the previous several years
combined, just, pouring over, whether
it was like onboarding or new, Teams
would publish newsletters on a weekly
cadence of here's what we met about.
Here's the progress we made.
Here's where we're at.
Here's what we're thinking for the future.
Here's what's next.
there were so many different cultural
things around reading and writing.
And I don't know.
I think it's a interesting to learn from.
And I'm curious, like in your, in
your career so far, would you say
that the companies that you've
worked with and for have had a really
strong reading and writing culture?
And what does that look like for you?
colin_1_08-01-2024_100949: Yeah, I
think the last couple of companies,
especially with the advent of notion,
I know like when I worked with
Strava, they use Dropbox paper a lot.
it was just docs and docs.
at Orbit, we had a pretty heavy
notion culture because it was
so both reading and writing.
Because we were distributed from San
Francisco all the way to East Europe.
Especially I think with the async nature
of work to be able to, again, like outline
all the things, get stakeholder buy in,
also get any sorts of side effects that
maybe you didn't think about that someone
else has experience with things like that.
and at discord, we do things like, PRDs
for product review, RFCs for technical
things before we write any code.
it's definitely interesting.
And it's funny that When we talk a little
bit later about what we're working on,
there is that, like how much meta work
do you do versus doing the work, but
in bigger companies, you can't just
ship it without any consideration for
what it's going to do to the user, to
the team, to how a lot of people expect
things to work today, things like that.
So I think it does help to fully
flesh things out and then pump the
brakes a little bit and just make
sure that you thought through things.
cj_1_08-01-2024_130949: totally.
It sounds like, uh, Amazon's
working backwards culture seems
pretty powerful to where they I
think they write the press release.
I didn't know about the fact document,
but like writing a press release of
what the new product will be announced,
like how it will be announced and then
writing a frequently asked questions
document that kind of helps you think
about what people ask about that.
is interesting.
Another thing that I've heard of Amazon
doing on the dev side is like starting
with an API design document or like
almost starting with an open API spec.
I think they use something else called
Swifty or something, but, starting
with that open API spec, writing
the examples, writing, here's the
arguments that go in, here's the
response you're going to get back.
And then using that as a
sort of guiding document.
both are examples of working
backwards, but, yeah, I don't know.
Both of those sort of seem useful.
I don't know.
Sometimes it can be tricky and feel a
little bit fake to try to write a press
release, like before you know the product.
it's almost you're doing a, Oh, gosh.
What is it like?
Sometimes in an interview, you'll do
role playing or they're like, okay, now
I'm going to be the customer and you're
going to be the salesperson or whatever.
try to sell me on this thing.
It's okay, this feels a little bit cheesy
colin_1_08-01-2024_100949: Sell me this
cj_1_08-01-2024_130949: right?
Yeah, exactly.
Exactly.
colin_1_08-01-2024_100949: like the FAQ
document though, because it's putting
yourself in the shoes of the customer.
And even if it like, say it's
something we're working on, if you
can't write a press release about
it, should you be building it?
Is it going to improve
the customer experience?
Is it going to improve some bottom line?
Is it going to, is it going
to move the needle at all?
If you really can't write that post,
there's probably some reflection to do.
when we build things and we announce
them, we write these posts in our
Discord developer server called DDevs.
And we almost always
write a changelog thing.
And most of the time, it
gets written afterwards.
but I have this saying that I
don't know where I picked up.
I'm sure it's from somewhere where
it's begin with the end in mind.
And it's very similar to working backwards
in the Amazon way, but I have taken to
like writing the docs first or once I see
a PRD or an RFC, I think okay, and this
is like for developer products, but this
could be the same for what is the, what
does the instruction manual look like?
What does the user update look like?
Whatever it might be.
And just writing the
docs first, because then.
If you try to explain someone how
they're going to use it or how it's
going to affect them, you're going to
anticipate the questions that they have.
You're going to put
yourself in their shoes.
what about this?
And what about this?
And that way you're not like,
announce the thing and then be
inundated with reactive comms.
And you guys didn't think about this
or, you know, what other things are
you going to put out that you know,
are half baked or something like that.
cj_1_08-01-2024_130949: you think
that, being a documentarian or being
a docs writer becomes harder when.
You might not have the same developer
experience, like not having like actually
built the, build stuff in the past.
Like I could imagine it being really
hard to be that thoughtful and
anticipating someone's questions if
I hadn't used a rest API, but I'm
trying to write the docs for rest API.
I
colin_1_08-01-2024_100949: that's,
there's like lots of layers there
because like it depends on what the
rest of the API is even doing, right?
if you've never implemented subscriptions
in Stripe, do you know the gotchas?
Do you know the things you have
to consider and like dunning
periods and failed cards?
And the API design is probably not going
to show you all those things because those
are like things that happen in real life.
I like to think of it almost like TDD
where like writing the docs first is
the test first and maybe it's, you're
literally writing tests first or,
instead of an API design, I think just
writing in pure words and like painting
a picture of what the dream state is.
I do think it gets into that meta
work of Oh, we have to move fast
and we can't get the dream state.
So what does half look like?
And it's would you write a press
release for half of this thing?
are you going to be triumphantly
celebrating this thing if
it's only half, or is it only
celebratory if it's fully finished?
so I think it's important.
I think.
what you're calling out is just like
making it inherent in the culture that
this is something we do here versus
Colin does this and CJ does this, but
everyone else is doing their own thing.
you know, what does that culture
look like and how can you build that?
You mentioned a few other things
like five 15s meeting notes.
How do all those kind
of roll up into this?
cj_1_08-01-2024_130949: think there
are also, other cultural things like,
okay, if we have a meeting coming up
cause there's a Google calendar event
for it, then in the description of the
calendar event, there's a link to a doc.
It's expected that you've read the
doc before left comments and we've
had like a thoughtful discussion and
we have everything out on the table,
before we actually meet and then once
we meet, there's also like notes of
who said what during the meeting.
With action items at the bottom, and
you've you've gone in with a clear,
agenda of what you want to, brainstorm
or make a decision about or whatever.
and then you come out of the
meeting with clear, next steps and
who's owning what and, you know,
or deeper connection, in some way,
deeper collaboration in some way.
So that like meeting notes is another
one where I'm that I am trying to bring
to the crew like, all right, before we
meet, let's always have an agenda that
has like several things on it when we
meet, we'll go over those things after
we meet there's action items and there's,
you know, things that are everyone
at the meeting can take away from it.
so that becomes also like a living
artifact of What was the decision
that was made and why, and what
were like some of the thoughts that
were behind it and why, we do have
a lot of documentation in notion.
That's just you know, company
documentation about like holidays
and, you know, how do you book a trip
and how do you, I don't know, like
basic stuff in notion, but, yeah,
that's also really valuable though.
having consistency.
And, I don't know, just standard
processes about how things work and
should work and, maybe like documenting
processes too, in Notion is valuable.
I don't know, another one that
comes to mind too is readme.
in your GitHub, readme for your
project, does it have all the
instructions to get set up?
Does it have all the instructions
for, like, how to use the
tools that are inside of that?
Code base and, and so on.
So yeah, lots of little
different writing artifacts.
I've been trying to rack my brain
about, it's been a while, but like
just other things that, that I
really liked from Stripe even before
that, I think my VR had a pretty.
like more of a deck heavy
culture where it was like, okay,
we're going to have a meeting.
So let's put together a
Google slides presentation.
Everyone's like responsible for
a slide and you have to go in
and add bullets about X, Y, or Z.
so yeah, there's definitely
like different ways to
do it, but
colin_1_08-01-2024_100949:
the deck one is interesting.
Like we have multiple teams and multiple
all hands and to be honest Like I would
prefer a bulleted pre read and then if
there's stuff to show and deck and all
that stuff Like that's one thing but
if the all hands is the first time ever
hearing about it Like I don't Yet no
questions I have and during these usually
we have questions in a separate session.
so there is time for that, but I do
enjoy like the pre reads ahead of time.
So you're not like coming into a meeting
and everyone only has, you know, some
people are coming in late and some people
can't make it and some people on PTO
and in bigger companies like having both
the pre read and the post read means
that if you missed it, you can just
read that and you can comment on async.
If you.
And I think that creates a healthier
culture than, you know, a lot of
people say Oh, if you're not in the
office, you're probably not, you
know, as connected to your team.
And you're probably not
going to get promoted.
It's that's because you've got
a really in person culture.
And if you missed it, you missed it.
And no one's taking notes.
Cause I think there's like that, even
in boards and stuff for like nonprofits.
And so it feels like the secretary
seems to be the job that nobody wants.
And.
Sometimes it's a literal role and
sometimes it rotates between all the
board members of who's writing the
minutes or the notes for the meeting
and That feels like something AI could
solve a little bit like let's just have
once this is good enough Have it write
the notes for us We have an AI that does
this and it also pulls out the action
items and who talked and who did what?
So that's super nice
cj_1_08-01-2024_130949:
Which one are you using?
colin_1_08-01-2024_100949: It's homegrown
It's only, it's like internal, like
only inside of our like team discords.
Yeah.
cj_1_08-01-2024_130949: that's cool.
I just recently tried tactic with a Q out.
there's a few that I'm just like bouncing
between just experimenting and trying
to see Which is the least intrusive?
Because I find that like when there
have been a couple that I've tried
that join the Google, like the
Google Meet call or the Zoom call,
it joins as like a separate person.
It's who is this creepy like other person?
And there's others that are much less
intrusive where it's like a Google Chrome
extension that just happens to be there.
Oh,
colin_1_08-01-2024_100949:
you want other people on the
call to know that's happening.
Like these are all internal calls.
So we all, and they joined the discord.
So like this bot joins the discord.
We are discord.
So we can.
Record the audio, send it over, you know,
and I think because we home built it, it's
not like we're sending all of our private
meetings off to open AI or whatever.
and then it afterwards creates
a notion doc with all the notes.
It has some fun flair where it then
takes all the people who are in there
and based on their behaviors creates
a screen play based on how people
were like acting in the meeting.
they're like, this person, in the
theme of, Deadpool, and this person was
Deadpool, this person was Wolverine, and
yeah, it's just really, it's very much
like, when it works, it's pretty funny,
and then above that, it has the action
items and the actual meeting notes.
cj_1_08-01-2024_130949: Nice.
I like that.
It's like adding, yeah.
Adding a little bit of a RIS to
colin_1_08-01-2024_100949: Little whimsy.
cj_1_08-01-2024_130949: the culture.
Yeah.
the last thing that I wanted to mention
too, before we move on, is that like one
of the behaviors that I recognize from
some of the like higher level engineers
that I worked with, at Stripe, it's
like L4, L5 at other places, I think
they would be considered like L6, L7
is that they send internal newsletters.
So whether, whatever meetings happen,
maybe you like take the meeting notes
and you send an email after with just
to the people who were at that meeting,
or maybe to the teams that were at that
meeting about here's what we talked about.
And here's what we're going to do.
and then the really like high functioning
folks would take, those meeting notes.
And, maybe over the course of a
month, synthesize all of those
and then publish an internal only
newsletter that would be sent to a
Google group that anybody could join.
and that gave them a lot of visibility.
And it also was like a way to
just like brag about their team.
So it like elevated their team.
And yeah, if you're out there and you're
you know, mid level and you want to
get promoted, I think this is a pretty
effective way to Get discovered is to
write an internal newsletter that is,
you know, bragging about your own team.
So
colin_1_08-01-2024_100949: Yeah.
I don't think I think in startups
you don't see as much of this type
of culture and stuff cause they're
small and they got to move fast.
But there's this habit of when
you're, whether you're fundraising or
bootstrapping or whatever you're doing,
usually it's given as investor advice,
which is everyone you're meeting and
talking to you ask if they can, if you
can put them on your newsletter, or
say Hey, do you want to get updates?
You're not asking for money.
Like you say, Hey, I want to have coffee.
I want to, you know, give you a pitch,
but maybe you're asking for advice.
Similarly, if you want
money, ask for advice.
If you want advice, ask for
money type of situation.
So ask if you can be like, Hey, maybe
it's not the right time for you.
Can I put you on updates?
If you're bootstrapping, it's also
valuable because then when you're.
Putting out updates on Oh,
I'm trying to do this thing.
I'm trying to hire, I'm
trying to do whatever.
Like you now have this list that
you can use when you do a beta, when
you do a Kickstarter, when you do
whatever, you now have this following
and maybe it's Twitter, maybe it's
email, whatever that might be.
but it's more like building
public that you can control and
creates a list and a following.
And, I've been talking to somebody
who's trying to start a coworking
space and I'm like, you can't
open on day one with no customers.
you need to have pre sold this place.
people need to be having pre committed to
the first three months and you open full,
do not maybe half full, but I see posts
of Oh, I'm starting a business and I have
no customers on day one and I've spent two
years coding and no one's ever seen it.
or coworking space opens and
it's three months in and we
haven't had a single tour.
This is where you got to write down
and talk about what you're working on.
and I think all of this helps, right?
There's these internal
newsletters, external newsletters.
If you're a one person team, create your
own little council that you're talking to
and documenting and getting feedback from.
cj_1_08-01-2024_130949: I love that idea.
I'm going to steal that.
The like investor updates, but like to
colin_1_08-01-2024_100949: Yeah.
I want the, the board of the
personal board of directors, right?
cj_1_08-01-2024_130949: yes.
Yeah.
So good.
So good.
cool.
What are you building?
What are you working on these days?
Colin?
colin_1_08-01-2024_100949: Yeah, this
one kind of follows up with this, but
I hit a point yesterday where I was
like, I just need to start writing.
so I'm working on a big docs project
again, and I realized that I was
like getting caught up in answering
questions and in some cases,
like verifying that some of these
things work the way that they do.
I was doing a little bit of reorganizing
Asana tickets and then I spent like an
hour in Asana and I was like okay that
was an hour that I did not get actual
work done like the meta work sometimes
is the work when you're like delegating
and having a team but like I'm the one
who's going to be writing these docs so
I like closed everything put myself in do
not disturb and just Turned on some good
music and just started writing and I got
like Surprisingly like a good skeleton
and everything built out And like I think
I was telling myself like let's get this
done by the in two weeks from now And I
think I'm gonna get done like tomorrow
Which will be at least like a first draft
so that then the team can go read it
And a lot of it in what we just talked
about is stuff that has not shipped yet.
And so I want to document and point
out like this doesn't work the way
we think it does, or we're missing
something or Hey, like this thing
that we're doing is going to like
by the time this episode comes out,
hopefully all of this will have shipped.
So I can talk about it, but like some
of it is Hey, this breaking change does
affect people more than we think it will.
And this is the guide that they're going
to have to follow to, to do that upgrade.
cj_1_08-01-2024_130949: Nice.
It's exciting when you like get
a big chunk of work done that you
didn't, that you thought might take
longer, but, yeah, it worked out to
be much,
colin_1_08-01-2024_100949: I've
got all the raw material already.
It's just it's easy to feel like you're
being productive by moving it around
and it's no, like we need to turn
this into gold now and do the work.
How about you?
cj_1_08-01-2024_130949: Totally.
Oh gosh.
doing a big refactor, changing a bunch
of things from enums to models still.
And, yeah, anyone who's done that knows
that there is, it's like a three PR
process at least to make the new field,
migrate all the data from the old field
to the new field, deprecate the old field.
make sure you're not using the old
field, update all the tests and
then remove the old field, drop the
column and then move on from there.
and we've got I think we ended up touching
like 20 different models and like of
those lots and lots of different stuff.
very close, but,
colin_1_08-01-2024_100949: Are
you doing that model by model,
like three PRS per model?
Or are you doing one giant, make
all the new columns across all the
models and then migrate all the data?
cj_1_08-01-2024_130949:
It's a little bit of both.
I did like a big group together
at once and then updated like the
integration points for all of those.
And now I'm doing another big
group and then I'm doing, I'll
be able to do the last big group,
but yeah, it's, it was interesting
trying to think through how to attack it.
Cause depending on where you
start, it can end up being like,
colin_1_08-01-2024_100949: This
code's dependent on this code.
cj_1_08-01-2024_130949: exactly.
Yeah.
The first in the first time
I went through, it was like.
It was actually like seven or eight
PRS that were all, you know, a couple
of hundred lines here and there.
And then the second time I did it, I
was like, Oh, I think I could do more.
Let me just bite off,
like a whole big chunk.
And so that PR was like 1500 lines or
something and touched a hundred files.
And there was like two or
three bugs that fell out of it.
And so that one was like, obviously
a little bit more cowboy ish.
But, yeah, I think just, yeah.
Yeah.
doing it in
chunks.
So we're almost there.
colin_1_08-01-2024_100949: I'm sure
the first one taught you how to do the
next one in a slightly different way.
cj_1_08-01-2024_130949: Yeah.
There's a lot of, so have you ever
used the strong migrations Okay.
Yeah.
So the, I'm like pretty new to it,
but what's nice about it is like,
It helps avoid these like foot guns
of okay, I'm dropping a column.
And then I'm trying to use that data from
that column to populate a new column or
something, or I'm renaming something.
And it, when you try to run the
migration, it's oh, actually
you should do this in two steps.
And here's the steps that you should do.
And first you should add a check
constraint in one migration.
And then in another migration,
different transaction or whatever,
You check the check constraint, change
the nullability of the column, and
then re add the check constraint.
And so it makes it so that you
have less downtime instead of
just being like, All right.
I'm deploying now.
Everyone hold on.
colin_1_08-01-2024_100949: Insert the
hold on to your butts gif right here
cj_1_08-01-2024_130949: Yeah, exactly.
Yeah.
You get like a flood of errors
from production that like are just
transient do it like mid deploy or
whatever.
So yeah, I think we definitely
had a handful, but I tried
my best to minimize like the
colin_1_08-01-2024_100949:
Yeah, I know I've used it.
I don't know under the hood how it
works, but I, it reminds me a lot of
like terraform plan versus apply where
it's let's do a dry run of this and
see if there's anything that we didn't
think about or like how long would
it simulated, like how long would it
take simulation like wise so that we
can plan around downtime or whatever.
but if, have you used terraform at all?
cj_1_08-01-2024_130949: just a
little bit.
yeah, just experimenting for some striped
content, but
colin_1_08-01-2024_100949: Yeah, when
it works, it's you feel so powerful.
Like you're just like, all right,
I'm planning this thing and we're
creating all these services and all
these boxes and all these databases.
And you're just like, terraform
it up, terraform it down.
it's very nice.
cj_1_08-01-2024_130949: That's so cool.
I, yeah, I do remember feeling you
know, when you like grab the little
scale, auto scale bar and you're
like, all right, let's auto scale
this thing up to 10 boxes or whatever.
It's so funny because
you feel so powerful.
And also I don't know.
I it, because when I was doing
this in the past, I was the one
paying for the Heroku boxes.
It always made me nervous to be like,
all right, we're gonna scale this up to
20, You know, 20 workers
right now to chew through
colin_1_08-01-2024_100949:
just thrown money into a fire.
cj_1_08-01-2024_130949: yes, exactly.
Terraform is gasoline to the
money fire that is like AWS
colin_1_08-01-2024_100949: Yeah.
I'm sure that there are still startups,
but there was one called cloudability.
They probably are still around that
manages your, watches your cloud spend
and like detects anomalies, which I
feel like in an AI world and all this,
it should be so much easier, like
just send all your cloud watch logs to
something and be like, do you tell me
if we see a spike in price or like this
box is running and no traffic's going
to it and you know, all that stuff.
So cool.
cj_1_08-01-2024_130949: along those
lines, I like totally got saved the
other day by open AI's spend limit.
I think I put my platform limit at
20 bucks and I wrote a background
job or I kicked off a background job
to re summarize all of my articles.
And, And all the podcast episodes or
something, and it went through and while
it was doing it, there was like a bug and
sidekick was just retrying the job over
and over and over until I spent 20 bucks.
I was like, oops, like I just kept
retrying to summarize and like
when the summary came back from
opening, I like wasn't going in the
database because there was no field.
I was like,
colin_1_08-01-2024_100949: They're just
like, throw this data away, go get it
again, throw it away, go get it again.
cj_1_08-01-2024_130949: Yeah,
try again, but yeah, there was, I
don't know, I've got some videos on
YouTube probably from about a year
ago that was how I built my like,
summarization for articles on my website.
It was, it's so funny looking at it
because back then the context windows
were so small that I had to do this
crazy chunking thing where it was
like break up the entire article
into 20 different chunks, summarize
each of the chunks and then summarize
the summaries into a new summary.
And now it's just just take the
entire thing, throw it at GPT four.
And it gives you a beautiful summary.
That's a thousand times better
than what we had before.
colin_1_08-01-2024_100949: Amazing.
cj_1_08-01-2024_130949: yeah, crazy
colin_1_08-01-2024_100949: Yep.
On the learning front, I'm very excited
about the book you're reading, but I'll
quickly tease mine because I just got it.
I have not started reading it yet.
I'm blaming Aaron Francis and, more
Ian Landsman for this one, but I use
Obsidian in the most messiest books.
inconsistent way.
And he has been running into
this, trying to find the perfect
notes, obsidian sinking situation.
And he keeps mentioning the Paris system.
So I picked up the Paris system book.
I don't really want to do this like
whole second brain, huge, like repository
I have to keep up, but I want to add
some sort of structure and I have
not successfully stuck to something.
So this area, the Paris stands for like
project area responsibility, and then
It's something else for the last A.
and we'll talk about it more in the future
episode I think once I get through it.
cj_1_08-01-2024_130949: I also
want to read this and I'm just now
starting to get curious enough that
I think I'm going to start one.
Mike just showed me he's using log sack.
I think, other people that
I've seen use obsidian.
And I was noticing that I have been
taking notes that have nothing to do
with work, but are like stuff about
life, like people that we run into or
like parents of our kids, friends that
I want to be like thoughtful about.
those interactions or networking and,
maybe we have stuff going on with the
rental property or whatever, like just
things that are happening, vacation,
whatever, like stuff that's happening
that I want to take notes about that
I want to be linked together and right
now I'm literally just sending myself
colin_1_08-01-2024_100949: yeah.
We gotta upgrade that game.
cj_1_08-01-2024_130949: I know.
Yeah.
And so I, part of it for me though,
is that it has to be easy to
update on mobile and on a desktop.
and so I don't know.
Yeah, maybe let's like do
an
colin_1_08-01-2024_100949: do an
episode on, second braining for sure.
cj_1_08-01-2024_130949: yes, yeah.
definitely worth digging into.
I was actually going to ask
you right before we started
about a second brand.
I didn't know that Paris system was
colin_1_08-01-2024_100949: It's one of the
many, one of the many that are out there.
So I'm not sure if I'll stick to it,
but I've also gone down the rabbit
hole of Asana and notion and people
use their notion to organize their
life and have all these like trackers
and notes and stuff like that.
And I've paid for a few of them to
see like how their templates work
and how that, and it becomes this.
meta work again of maintaining
and grooming your notion.
I need a system that
can get out of my way.
but, yeah, I think, what
book are you reading?
And I'm curious how far you are
because it's one of my favorite books.
cj_1_08-01-2024_130949: Oh, really?
Okay.
Yeah.
So I just finished this book
called unreasonable hospitality.
it is amazing.
Mike recommended it.
We're actually reading it as like a
book club, like a company book club.
And, yeah.
So what was your introduction
to this or like, how did you
colin_1_08-01-2024_100949: So I found
it, Somewhat through co working so like
I guess it shouldn't be surprising but
like hospitality I mean co working and
hospitality is like the new buzzword right
now Where everyone went from like we are
community instead of just office space
and then now it's like really focused on
hospitality Which I think is swinging too
far in another direction where they're
like, you need to have baristas and like
these 4, 000 espresso machines on site.
And it's I know none of you are
making enough money to afford this.
So it's just throwing
good after bad, I think.
Similar to restaurants, though,
you have such low margins.
And what I love about this book is it
comes from one of the founders of 11
Madison Park, which is on my website.
bucket list of restaurants to go to.
just this idea of someone expects one
thing, but then you do one thing times
a hundred, and you didn't need to,
and you're not charging for it, you
did it to bring surprise and delight.
and yeah, I just think like
some of the stories that they
do are like, so over the top.
But also so amazing.
so I think it makes a lot of sense for
you and, you know, in the team to be
doing this, cause there's a lot there
where people don't expect little moments
of surprise and delight when interacting
with somebody across the text message
or, you know, checking into an Airbnb or,
you know, any of those steps along the
way are opportunities for that surprise.
cj_1_08-01-2024_130949: Totally.
the book is all about how to form
authentic human connection with.
The people that you're serving
and that, by doing so you will
see outside unexpected returns.
And, so the, there are so many
really fun examples throughout
the book that they give about,
just insane stuff that they do.
you know, one example might be if
someone is sitting down to dinner
and they mentioned that they have to
get up midway to go feed the meter.
they'll just ask Oh, what
does your car look like?
And where'd you park?
And then they'll take care of it.
They're just like, go out, feed the meter
for you so that you don't have to get
up and go and little things like that.
Also, you know, someone mentions that it's
their birthday to the reservationist the
day before, then when you come in, they've
already like Googled your name, they know
what you look like and they can welcome
you by name and say happy birthday,
welcome, and bring you in, take your coat.
You sit down, have your dinner.
And then after your dinner, they already
know which coat is yours through all
these different like little systems
that they've built to scale
their like hospitality.
and yeah, I think it's,
it was really inspiring.
And also there's this, role at
the company that they've created
called a dream weaver, which is
like a person who is responsible for
building these ad hoc one off magical
moments or like moments of delight.
There was a couple of people that I
worked with at Stripe, Edwin and SMCA
Sam, who would go on Twitter and people
would post about like their experience
with Stripe and they would come up with
these like crazy over the top things.
And so like Chris Oliver, they
sent him like this massive,
like one of those giant checks.
Cause he like made a joke about you
know, what if the Stripe API had
like this giant check thing and.
Other people, they sent you know,
little, there was one that I think
it was like a skateboard shop or
something, and they sent them like
a skateboard, like a little finger
skateboard deck with like their own logos.
And, yeah, just like really interesting
ways to, be unreasonable about how
you serve your customers and how you
like show up for them individually.
and just build that authentic connection,
which I think really goes a long way.
colin_1_08-01-2024_100949: there was a
little bit of this like movement with
delivering happiness from Tony Hsieh
and Zappos because they're, they also
believed very much in this and it was
funny because someone at the collective
was like, that, that, I just read the
book and there's no way that would happen.
And, somehow this was in the earlier
days of Twitter when you could tweet
and actually cut through some of the
noise, but I think he tweeted at,
Zappos and GaryVee That like, I bet
they won't send us a pizza and they
both sent pizzas to the collective.
And the funny thing was like
Gary V sent a local pizza place.
Someone from Gary V's team probably
found a local place and sent a pizza and
Zappos sent like Domino's, but we got two
pizzas and, It was interesting because
like we were not necessarily customers
of either of them, but it was that,
that, I think that was really popular
and in vogue at the time of doing things
that people don't expect and all that.
But I think the important thing is that
like they truly care about doing it.
When I see it happening and some of
the coworking and stuff, it's Oh,
our, we got a building and we threw
Ikea in it and no one's showing up.
So now we're going to, Community wash
and say, Oh, but we're so focused on
community and they don't really mean it.
And so then community was like,
Oh, community didn't work.
So now let's do hospitality.
And it's almost like hospitality washing.
It's okay, how can you,
how is that possible?
Like you're still offering this amazing
experience, but like you can tell that
they, with this dream weaver role and
every little interaction, like they have
baseball signs to be able to tell people
things, when it's time to refill water,
instead of yelling across the street.
The space or having someone even have
to ask for water that they're just,
they're anticipating, or like we talked
about earlier, like what their needs are
versus doing it to make another dollar.
Like they know this is going to cost them.
But when you're thinking about where
am I going to go to dinner for a
celebration, a big moment in my life,
like the meter one is a good example.
The people are spending 500 a
person on dinner to have to go
out and put money in the meter.
Seems like a mismatch of the experience.
So that is a simple thing.
The pizza one I really loved.
We're like, we're in New York and
we never got to have New York pizza.
So they like send out someone, they
get pizza, bring it to the chef.
The chef like does it up a little bit,
doesn't change it too much, but does
fancy presentation and they're like,
you know, here's your full dinner.
But then also we wanted to
really make sure you had some
New York pizza before you left.
cj_1_08-01-2024_130949: Both Colin
and I have read it and remembered,
several stories, but the book is
just jam packed with like dozens and
dozens of different stories of like
how they delighted their customers.
So I think it's a great way to
get inspired too, if this is
something that interests you about
Oh, how could I do that for my.
Whatever, fill in the blank
business,
colin_1_08-01-2024_100949: And it
doesn't have to cost money either.
Like I think some of those are
expensive options, but they
have high ticket customers.
So like even little thoughts like, you
know, in our case when members come
in, like we could just say hi, but like
taking that extra time, like when we
do tours, I do look people up and if,
especially if they're software people,
cause I don't think they expect us to
know who or what their companies are.
And it's if we know what the company is,
if, It helps because I'm in software,
so I know these companies like it, it
just goes a little bit further and I
guarantee nine times out of 10 we end
up getting that member more than if they
went to some other place and they're
like, didn't even have a greeting at
the door and there's no one there to
even figure out what the next step is.
You could just meet this,
the anticipation, but
you're going that next step.
And it could be an email.
It could be a phone call.
It could just be like remembering
something about somebody and
bringing it back around and
having them be heard or seen.
it doesn't have to be these huge,
grandiose, things that cost money.
cj_1_08-01-2024_130949: Yep.
Totally.
colin_1_08-01-2024_100949: Cool.
cj_1_08-01-2024_130949: highly recommend.
colin_1_08-01-2024_100949: Yeah.
We'll put some links
for sure for that one.
and the Paris system we'll do the build
and learn book club, the Paris system.
cj_1_08-01-2024_130949: nice.
Yeah, let's do it.
colin_1_08-01-2024_100949: Very
cj_1_08-01-2024_130949: You can
head over to build and learn.
dev to check out those links and
resources and transcripts and
all the notes from this episode.
Thank you so much for
listening and hanging out.
colin_1_08-01-2024_100949:
We'll see you next time.
cj_1_08-01-2024_130949: Bye friends.