Subscribe
Share
Share
Embed
We discuss visiting NYC, DevRelCon, red-eye flights, and why enums are terrible.
Some of the bits and bobs mentioned in this episode:
- DevRelCon
- Chef's Table (S2E1 Grant Achatz) / Alinea
- Steal Like An Artist by Austin Kleon
- CJ enumerating lessons about enums
Some of the bits and bobs mentioned in this episode:
- DevRelCon
- Chef's Table (S2E1 Grant Achatz) / Alinea
- Steal Like An Artist by Austin Kleon
- CJ enumerating lessons about enums
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.
CJ: What's up, Colin?
Welcome back from DevRelCon.
How was New York City?
Colin: was pretty humid.
It was, you know, visiting
New York in the summer.
Always fun to go down the subway.
when it's almost 100 degrees outside.
CJ: Yeah, is it this is not
your first time to New York.
And were you there for the
whole week or was it just kind
of a few days or what did that
Colin: Yeah, I actually took a red eye
on Wednesday night and got there an
hour before the conference started.
And then
CJ: I don't know.
Colin: thankfully I was
able to sleep on the plane.
I have taken that same red eye and not
been able to sleep the entire time, which
then just wrecked me for the whole day.
So I made sure that I
would sleep on the plane.
Barely got any sleep.
Like my whoop detected that I just
didn't sleep, even though I know I did.
Then I had to figure out, you know,
it's been a minute since I've been
in New York, so I had to like figure
out how do I get from JFK to the
conference using, you know, air
train to the This line to this line.
That was actually really easy.
It was like, this is, was like a,
like a personal development trip.
So like discord wasn't
paying for something.
So it was like, we're
training the whole thing.
Like what's the cheapest way to get there?
Cause I think it was like 150 Uber
ride to get to their conference.
So yeah, I've got to the conference.
Had all my stuff with me all day, just
straight from the airport and just had a
lot of coffee and did the first day and
then got to go to the hotel and yeah, it
was there for the weekend after as well.
Just, it didn't make sense to like fly
across the country and then fly right
back as soon as the conference was over.
CJ: hmm.
So what are your tricks for trying to
sleep on the plane for, for a red eye?
I don't know.
Colin: Yeah, I mean so many people like to
do like ambience and stuff and that stuff
scares me a little bit I just don't want
to ever have to have something like that.
So I have an inflatable some sea to summit
pillow that I take so I don't have to
like I think the pillow is important But
I don't want to like carry a giant pillow
everywhere So this one like collapses down
into nothing and you can just inflate it.
I mask Noise canceling headphones, usually
AirPods, or if you have like over the
ear ones, it's always tricky though.
Cause like if you're on the end I didn't
realize this cause I was completely
out on this flight, but like, and
no one needed to get up, but I was
in the aisle and like, if you need
to get up to go to the bathroom and
you're on the inside and everyone's
sleeping, like it's not a great.
I don't know.
Airplanes are so weird.
But on the return flight,
it wasn't even that late.
Like, people were passed out and
you could see people trying to,
like, climb over seats and stuff.
And I was like, this is just,
like, this is how we fly.
This is not what the TWA commercials
of the 50s and 60s and the,
the height of, of, of flight.
CJ: That's not the promise.
This is not what they promised us.
Yeah.
I, we have a red eye coming up.
I haven't done one for several years.
And I, I remember after I did the last
one that I would never do one again.
Like I was like, I, this is awful.
Like I hated every second of the day
Colin: Yeah,
CJ: So yeah.
Any, any any tips and tricks are Yeah,
Colin: is that with the kids or just you?
CJ: with the
Colin: that, that'll probably make
it a little bit more complicated.
But I would say if, I don't know if
you're up for it, but like I did do
like half a weed gummy on the plane.
I was just like, I need this.
to make this work.
So I mean, I trust that more like I
know it'll be a few hours versus an
ambient where I'm like, I don't want
to be waking up like even more tired or
CJ: yeah, totally.
Yeah.
That'll help for sure.
Okay.
I've also heard like, yeah, just do
your same like bedroom routine or
whatever, like at the airport, like
wash your face, brush your teeth,
like do the whole same thing that you
would do before you go to bed and then
like just do it and then get on the
Colin: Yeah.
I mean, like screens
obviously are an issue.
Like, it's already you're starting
late, like, Honestly, I don't
usually stay up till even midnight
and my flight wasn't till midnight.
Things like magnesium, tart, cherry juice,
all those kinds of things can also help.
So all the sleep stack stuff that
everyone likes to talk about,
this is the time to use it.
CJ: Yeah.
Have you seen those take talks or
Instagram reels of people, raw dogging
Colin: Yeah,
CJ: Yeah.
They just like stare, they do nothing.
It's like, I saw this one that is
the guy was like you know, six and
a half hour flight, no snacks, no
drinks, no water, no screens, no
music, just no going to the bathroom.
You just stare at the back of the seat
in front of you for six and a half hours.
Part of me is like tempted to try it.
Just like, it's, it just
seems like such a meditative.
Thing, but
Colin: for me, I get annoyed by everyone
else on the plane, like I need to like
movies are probably the easiest way
that I get through flights, if I can
work a little bit of write or read
or something that's always good too,
but the idea of like, like, I hate
being Having to go to the bathroom
on the plane because it's small and
CJ: Mm-Hmm.
Colin: that.
But, you know, so then I, like on a long
flight like this, like I'll try to be
like, okay, we're going to get, we're
going to use the restroom in the middle.
So I only have to use it once, not try
to drink too much, but drinking water,
enough water, especially when you're
flying is important too, for all just
feeling normal, not having jet lag.
Movies are good.
Yeah.
There's like the tick tocks of people just
watching the map across the whole thing.
And I don't know, like you got to
take care of yourself on these things.
I don't think it's worth trying
to like win a medal for some
meditative monk state, but yeah.
CJ: And then so you got to the conference
and was it kind of several tracks or
single track and then like rough idea
of like how many people were there
and kind of like, where was it at and
Colin: Yeah, it was an
industry city in New York city.
So kind of like food hall,
bunch of businesses and
food, food vendors and stuff.
And so there was like a event space for
the main track was there were two tracks.
I don't know if they were actually
split by a topic, but you could
go between the two rooms depending
on what topic you're into.
And then there was an unconference
that was running both days as well.
We, we can talk about it here cause
this is, This is a safe place, but it
was interesting to see like how much,
there's been a lot of articles about
the death of DevRel and we've talked
about it on the show before we maybe
even mentioned it in the last episode.
And it was just really weird to see
that, that energy from some folks
who aren't even in DevRel anymore.
And I'm not sure what the goal is.
It's like, is this for your own
personal, like, like pulling the
ladder up behind you, literally kind
of stuff, but it's people who aren't
even necessarily in DevRel anymore.
And there's just a whole lot
of justifying re's existence or
justifying the function of Derel.
And we've mentioned it before, but
like a lot of the stuff that we do at
Discord just doesn't look like normal,
well, quote unquote normal derel.
And when we worked at
Orbit, we saw this too.
Every company does it differently.
So you to, to say Derell is dead is.
Dumb because it's not one thing,
but every company is different.
I think Kelsey Hightower said
DevRel is whatever the person
paying you says it is, right?
At Stripe, it's going to be
different than Shopify is different
than a developer first company
versus a developer plus company.
Is it more community focused?
Is it content focused?
It's all different things.
Like what you did is very
different than what I did.
We probably had lots of overlaps,
but like, you know, You were
very much a face of the docs.
Literally when people would start, you
know, the videos, it was, it was CJ.
So it was an interesting
vibe to the conference.
Like there were definitely people
who mentioned some of those articles
and the, the, the perception of it.
Obviously a lot of people
also trying to get jobs.
So I think that also perpetuates it a
little bit like, Oh, if everything was
in, you know, the high times of DevRel,
then everyone would just have a job.
And it's like, well, it turns
out there is unemployment in
every industry and DevRel is not.
does not escape that too.
So hopefully some of those people are
able to meet people and get jobs or
connections through, through this though.
CJ: Yeah.
I think as long as companies are
working with developers as customers.
There will be some form of DevRel and
dev marketing and content creation and
community building and all of that is like
important if your customer is a developer.
And so yeah, I can't imagine a world
where DevRel really permanently goes away
and in all different aspects, I think
it'll definitely shift and change over
the years, but yeah, I think At every
single one of these companies, there is
definitely some sort of need, whether
that is a full time thing or not is
debatable, but there's certainly like that
activity is important and valuable and
Colin: Yeah.
Well,
CJ: kind of a bummer to hear that
folks are saying that it's dead though,
because it was like, it's by far one
of my most favorite roles for sure.
Colin: yeah, I'll share some of
the articles in the links and
I'll share one with you too.
That one comes from Casey who
started at Twilio danger, Casey.
And they're in kind of
more product role now.
And I think that they're an example
of like, they were, Twilio was kind
of the quintessential DevRel, right?
Like the time to first hello world, the,
which is great for sending a text message.
It's an amazing demo to curl and
send a text or ring a phone call.
And now with AI, like we
can do so much with that.
And there's a lot at some point,
I think DevRel did become how
many conferences can you go to?
And there's some very valid points.
It's like.
It is weird to go to a conference
when every speaker is a DevRel.
It feels like ad after ad.
And again, not every DevRel
does talks the same way either.
Like, there are some people
who make a talk and pitch it to
every conference on the planet.
And then there are people, I think
like you and I both approach it
a little bit differently, and we
craft a talk for the conference.
And sure, it doesn't quote unquote
scale, but like, It makes for a
good talk that isn't a sales pitch.
Even if we're dev advocates,
we're not necessarily pitching.
Like when I did mine, it
was not pitching orbit.
It was, we had this problem at orbit.
This is how we fixed it.
This is how you might approach build
versus buy or whatever in your company.
And it wasn't then go use orbit.
So obviously if you're.
Running a tools company and you're
at a dev conference, you are being
paid to chill your tech tools.
So I think that is, there's a fine line
of being the, the over, overly salesperson
versus truly advocating for something.
CJ: Were there any like trends or
things that seemed interesting in terms
of like what modern or like, you know
What is devrel gonna look like in 2025
in terms of I don't know I guess I'm
thinking stuff like short form video
content and or like stuff that's sort
of you know Beyond like docs and SDKs.
Colin: There was, there was a, the talks
that were most interesting to me were
around like partners and kind of going,
there's like this concept of head torso
and tail developers in your company.
So the head being like those strategics,
torsos being, you know, kind of
like, we have a contract with you
and you're a partner of some kind.
And then you had a long tail of
just every DIY dev that finds
you and is figuring it out.
Maybe they're learning, maybe they might
bring it into the next company with them.
Maybe they're doing
something indie or something.
So those two were interesting.
One was from Roku.
And the other one's from
bear Douglas from pine cone.
They spent time at Twitter and
Slack doing dev dev rel stuff.
So those two were probably like
the most quote, like mature.
form of Deborah.
And I think where a lot of people
want to be like, they are not
justifying their existence.
I guarantee it.
Right?
Like they know exactly what the
power is that they, that they're in.
I didn't go to any of the, there will
be, all their talks will be released.
So even if you couldn't make it, they
will be on Debra Khan's YouTube channel.
But there was one on video from Kevin, I'm
blanking on his last name, Kevin Lewis.
Just around like how to create
that video production, like.
Process and stack for yourself.
The one that was most valuable
to me was actually docs and SDKs
and it was an unconference talk.
So I didn't really get a sense
to answer your question, like
of like the future of DevRel.
And I think I kind of went with my
own assignment of how are we going to
think about maturing DevRel at discord?
That was kind of my homework of
what does it look like as we, if we
can build out the full team for it.
And it didn't really check any of
those boxes, but like the unconference
around what people are using, who's
also responsible for the docs and
all that kind of stuff was, was fun.
I, I think I am a docs
person at heart, so,
CJ: It's, it has been really
interesting to see that responsibility
falls in different companies.
Where like at Stripe, the docs were
technically supposed to be written
by the product team, but we had
like a giant team of docs writers
that would also sometimes write.
The docs.
And then we had an editor who would like,
make sure all the tone was the same.
And then I know tons of other companies
where docs might be written by
DevRel, or they might be written by,
you know, support, or they might be
written by marketing or something.
And so, yeah, where that falls
is, is pretty interesting.
Especially like.
I don't know the different flavors that
we talked about before that kind of like
the four different types of documentation.
Colin: Yeah,
CJ: cool.
Colin: that was DevRel con.
CJ: Nice.
Nice.
Sounds like a fun trip.
Colin: What were you working on
while I was running around New York?
CJ: Oh gosh.
Last week.
Oh, actually, you know what?
Logan and I took a trip to Chicago.
So you were, I think when you
were in New York, we were in
Chicago for the first time.
It was awesome.
It was a father son trip.
The first one this year.
I'm doing another one later
this year with Grayson.
We're going to go to DC.
But Chicago was awesome.
It was my first time going and we
like, Just played and had tons of fun.
We went and did like this boat tour
for architecture and we went to a bunch
of museums and his favorite thing that
I think, like, it made me a little
bit nauseous, but it was one of those
like flight simulators where you get
in the actual cockpit and as you're
like rolling the joystick, it actually
like rolls over the entire cockpit.
So you can feel like you're upside
down or like, you know, you're
diving straight forward or whatever.
It was, it was pretty epic.
Super fun.
But yeah, definitely a
little bit nauseating.
So, but yeah, Chicago was
Chicago was pretty, pretty sweet.
I think I would definitely go back
probably just Nicole and I do some more
adult stuff, go to shows and eat out at
more restaurants and things like that.
Colin: Yeah
it's, it's it's not a cheap
dinner and I haven't been yet.
It is on my bucket list, but if you if
you guys really enjoy food and you and
Nicole go back, gotta go to Alinea.
CJ: Okay.
Colin: we'll put a link to it,
but one of my favorite chefs.
Really crazy story.
If you I'll put a link to the, I think
it's a chef's table story with him.
There's something that happens
to him in there that it's
just like such a crazy story.
I won't spoil it here,
but very cool restaurant.
I mean, it's definitely one of those
like Michelin star, like very expensive
restaurants, but if there's ever a
special occasion, it's on my list as well.
CJ: The food was good.
I love deep dish pizza.
We had that, but I think it
was not as good as New York.
So like, I remember like every single
of food and well, I mean, I, I,
yeah, like the pizza, the pizza, I
think actually the pizza in Chicago.
I don't know.
We had like a slice on the
street, like in New York.
So different, you know, not easy
to compare, but the, like just
in general, overall, every bite
in New York was just insane.
And Chicago was like hit or miss a
little bit, but yeah, that's funny.
We did go, yeah, we went to this like
museum of science and industry, and they
had like a double Oh seven exhibit going
on, which was pretty sweet to see, like,
he's like Aston Martins and like, you
know, props and stuff from the movies.
So that
Colin: that's a, that's a
good one to have a museum on.
No shortage of things to show.
CJ: yeah, yeah, totally.
It was a blast.
So
Colin: And you're back in
back in enum land and work?
CJ: Enum land, I am, I
have a new rule of thumb.
No Enums.
Death to enums.
Enums are just like creating
so many, so many problems, so
Colin: Foot guns.
CJ: have decided that, yeah, it's
just, this migration is just awful.
So yeah, we haven't, we have I have
this big blog post about like ways
that you should do enums, right.
And I'm, I'm going to go make an
edit to that and just say, just
don't, don't ever use enums.
It's just such a messy, such a
messy, uh, migration to fix switching
from an enum to a proper model.
And now that we have the model, it's
so much more flexible and there's so
many more things we can do with it.
And yeah, just like breaking it
out and actually being able to
encode way more than just a string
into the value of the enum and,
Colin: that the, for like someone
who maybe hasn't played with enums
or is just joining us, like, is that
going to be the biggest trade off?
Is that like, usually, yeah, it's just
a string or some sort of int value.
CJ: right.
Yeah.
So usually I think probably the
rule of thumb typically for enums
is like, if you have some very
small fixed set of things that.
Or some very small fixed set of values
that could be assigned to something,
then you might want to use an enum
where, you know, it's either one,
two, or three, and it can't be any
other value in terms of like how it's
technically implemented, you can do it
at the database level, Postgres supports
enums you can do it at, Like the model
level in rails, where you have a column
that is either a string or an integer.
And like, you know, if you want super,
super fast, speedy, whatever, then you
might decide to store an integer in
the database, but then rails has like
these, um, you know metaprogramming
tools that expose methods so that
you can call methods on your model.
And those can get mapped to names.
Which are attached.
So for example, if you have like a
status field and you have pending and
submitted and canceled or something,
those, you might consider making those
in enum where in the database, you
actually store just like zero, one or
two, but zero might be mapped to like
pending one might be mapped to submitted
and two might be mapped to canceled.
And then you'll get
methods on your object.
Like you know, thing dot submitted
question mark, and that will
return true or false depending
on whether or not it's submitted.
So there's like a, a lot of nice little
conventional things that you get from it,
but we were using it for an item type.
In our case, that's like for an
estimate, can you, an item type
might be the walls or the trim or the
ceiling or the crown molding or the
window casings and things like that.
Inside of a room.
And so you would build up these
estimate items for like a line item.
And each of those estimate items
would be tied to an item type.
So in the beginning it was fine.
It was like, okay, yeah, you can do the
wall ceiling trim and crown molding.
And then over time it was like,
okay, now we're painting exteriors.
Now we're painting cabinetry, which
needs like inside boxes, outside boxes.
You know, exteriors need like
fascia and columns and stairs and
like all kinds of other stuff.
And so Eventually it was like, okay,
now we're trying to encode way too
much just into the name of the enum.
So we got to a point where like the
name of the enum was like paint,
square foot, exterior siding, whatever.
And that points at number like 94 or
something, you know, and that's like,
okay, we're like abusing it too much.
This should be a proper model where
the model has like a name and maybe a
slug and an ID and like, you know, does
it accept paint colors or does it not?
And is it a.
This individual unit, like, are
we going to paint each of these?
Or are we going to paint one of them?
Are we going to paint it by the
square feet or by the linear foot?
And so a lot of that encoding can happen
in a proper model that is like really
hard when you're just using an enum.
Colin: How How does that work
with when you want to change
or update or add to a model?
Is there some sort of versioning
or anything like that built in?
CJ: So usually if you're adding, you
add a new, you can add a new enum
without it being a breaking change.
If you are like, if we
decided, you know, we have.
Pending submitted, canceled.
And if we wanted to add some other one
that was like waiting review or something,
we could just make that number four.
Colin: I mean, in the sense of
the models themselves, like if,
CJ: Oh,
Colin: if you've completely changed the
model options or, you know, we have a
new thing that like usually additional
things are, are move, like they break
forward and you don't really need to
worry about it, but then if you're
changing up stuff, how does that work?
CJ: Right.
So yeah, when you're using an enum,
if you, if it's in the database,
it needs a database migration.
If you're using an enum in the model, you
can add to it or change it from the model.
If you're using a separate
data model instead of an enum.
That gives you a lot of power to like
hand over the keys to non technical users
who can just click around in the UI.
If someday the sales team decides that
they want to support painting, you
know, flower pots or something, they
can just go in and add a new item type
for flower pots and like, it should all
just work as expected without having
to like make a change to the code.
So
Colin: I mean, I guess you're working
with things in the real world.
So like, it's not like we're going to
find something that we've never discovered
before a fourth, a fourth dimension.
It's like, okay, how, what is the
width, the depth and the height?
We know there will not be yet another
measurement that we have to worry about.
CJ: Exactly.
Yeah.
So yeah, just kind of doing
surgery, replacing that with models,
and that's been a big project.
Yeah, just like putting a bow on and a
little cherry on top of the calendaring
stuff, but for the most part, like, the
calendaring, staffing, clock in, clock
out stuff is all Pretty much wrapped up.
So
Colin: Very cool.
CJ: yeah,
Colin: Yeah.
I think definitely update your
blog posts, but I think a blog
posts around death to enums or
something might be interesting too.
CJ: yeah, okay.
Yeah, I think that's coming in hot.
Ooh, another, yeah, I can't remember if
we talked about it last time, but I have
a blog post in mind about splitting Redis
instances, like one for view caching and
one for sidekick, which was a thing that
bit us and took a while to figure out
Colin: that.
CJ: yeah, what's going on
over there, project tracking,
you got some, yeah, what,
Colin: Yeah, I guess.
CJ: your preferred
Colin: Oh man, I guess DevRel is
like more of my brain is right now,
but we've been trying to figure
out how to track what we're doing.
When we do so many things, we
do a little bit of everything.
We, as a company uses
sauna for a lot of stuff.
We also use notion for a lot of stuff.
We have get hub for a lot of stuff.
And what's tricky is not necessarily
like, where do you put all the tasks?
It's.
What is, if we only have two people's
worth of time, what is the most
important things for us to be doing?
What are things that are popping
up that we don't know about?
What are things that we know are going
to come up that we don't think about yet,
but we don't want to keep it in our brain?
And like, this feels like a solved
problem everywhere all the time, but
the challenge is if you common view
that board by yourself tomorrow.
It's hard to know what of these
things are hard, take a long time.
Are things that we can do in our sleep
things that we already did unless
we really have a good system for it.
And this kind of goes back to
the slow productivity episode
that we talked about, where.
When someone does come with, with
something that they need you to do, like
asking them to go put it on the list and
they'll see how many other things you're
doing and they'll be like, Oh, maybe I'll
just do it myself or maybe it's actually
not as important as I thought it was.
But like today you couldn't do that
because you'll be like, Oh yeah,
they just have a lot of stuff.
Let me just put this on
the top of their pile.
And the problem with that is that we
don't either know that it's been added.
And that can be solved all sorts of ways.
So we're just trying to think
through like how to do this.
And we've mocked up a thing in
notion to just play around with
like different concepts and ideas.
And I went down this like notion
template rabbit hole and bought
a few temp project templates to
see how other people are doing it.
And man, people are doing some crazy
stuff in notion, which is awesome.
But then you're spending more
of your time curating notion.
Then actually doing the work.
So we traveled a really
long circle around.
So now we're going back to Asana in
part because the team can also see it.
We're just going to try to
figure out how to make it more.
Like you don't get to just
add things to our list.
They'll probably be a different project.
That's like an inbox.
And then we'll move things into our
project that we, if, if it's in the inbox,
you can count on the fact that we haven't
seen it yet till it's been processed.
So we're still figuring
it out, but it has helped.
Even the notion has helped to take
things out of my head so that I don't
have to carry them around with me.
Like when I go home and just like.
Not have to worry about it
or if someone goes on PTO or
something like it's all in there.
We might end up doing some sort of like
top five thing instead of trying to
figure out like how do we tell everyone
what's important and what's not important.
Like we could just say what is important
and everything else is below the line.
I don't know.
Have you had any need to
demonstrate like urgency and
importance and stuff like that?
CJ: Yeah, and we, we actually had
a similar discussion with our team.
At the offset a few weeks ago where
we were like, why do we need to put
tasks individual tasks into projects?
Like if I know that there's something that
needs to be done Can I just like create
a task assign it to myself and do it and
we kind of made a A rough rule that like
every task must be assigned to a project.
And so we use linear
for project management.
I don't know if that was one of
the ones that you checked out.
But that's like also a company
wide thing that we're using.
So if we were.
Had a place using Asana.
We, we would certainly use Asana.
I don't know if Asana has
the concept of projects.
But where we landed was like every
task should be attached to a project.
And then what we've done is put
those projects into initiatives.
And I think they used to be called
roadmaps or something in Asana.
And so like when we meet with the
stakeholders from different teams,
we'll pull up their roadmap and be
like, here's all the projects that
we know we're working on for you.
And like rough statuses of each of those.
Here's the two that are
in flight right now.
Here's like, what's on deck.
And then here's everything under that.
But I think the biggest takeaway
from that meeting was that the main
Reason for doing all of the overhead
regarding project assignment and
project management was for reporting up.
It was like all about visibility
up and like very little about.
Like internal productivity and
like us getting stuff done.
It was like almost all about like, yeah.
How do we communicate to other teams,
how, and what we're working on.
And yeah, exactly.
Like where in the priority
does their tasks fall?
So, but yeah, back to your, one
of your earlier points about like,
when you look at a ticket, you don't
know, is this big, is this hard?
Is this going to take forever?
Is there like how many
unknown unknowns are there?
And there, that's like a very challenging
thing that I don't think I've ever been
on a team that got super, super right.
We've done, I've been on teams that
have tried the like Fibonacci thing.
We've tried the t shirt sizing thing.
We've tried like a bunch of different
approaches to measuring tickets.
I think in my experience.
Breaking things down as far as
possible can be really helpful to
trying to like estimate out how
long something is going to take.
But yeah, even then there's a lot of
times where like you don't know what
you don't know until you get into it.
And so roughly what I've been finding is
that the projects that we're working on at
Craftwork When we sit down to like design
it or think about it, we might write out
like 40 tickets or, you know, 35 tickets.
By the time it's done, we have
like 85 tickets or something.
And so it's like, you know,
more than 2x the number that
we thought we were going to do.
And of those 85, like 15 of them
end up just like never being done.
Ever.
They're just like stuff that we thought
we were going to do that ends up in
this bucket of like, yeah, nice to have,
but not happening until like, yeah.
So like a project, like the priority of
the project is actually, there's like a
cut line where like, after you've finished
a certain amount of the work related
to a project, it's like, okay, we're
cutting right here because there's work.
That's part of another project.
That's actually higher than this.
And so maybe someday we'll
come back to these 15,
Colin: those are listed as fast follows.
And then how often does the
fast follow actually happen?
And yeah, yeah.
That sounds very similar.
I do like, I'm sure that there's
research being done on this, but
it's like that I've been able to
point to in any project I've been in.
I think what I'm coming to terms
with on our, Team is that like, there
is enough stuff going on for like
a full time air traffic controller.
Like, I guess that's a project manager
really at the end of the day, but because
of we're like parallel to every other
team and there's things that can pop
up tomorrow that need to go out next
week that moves everything around.
And so like the issue is right now we
do the traffic controlling and the work
and the follow ups and all that stuff.
And so things get.
You know, it's just hard
to keep everything in sync.
And I've still got note
cards that I write things on.
And I've still got a sauna notion.
And very similarly, a lot of the
Asana stuff, like using the built
in project updates and project like
analytics and stuff will be interesting.
We've never used those as DevRel, but
like being able to do like a weekly
recap that goes up to people above us.
So they know what we're working on.
I think you mentioned like,
was it 15 fives in the past?
CJ: Yeah, 515s.
Yeah, yeah,
Colin: those kinds of things.
I think we, we used an app called 15
five at panty drop and like, that was
nice to like, what did you do this week?
Cause there are some weeks where
I do so much little tiny things,
but if you then told me like,
what was your impact this week?
I'd be like, shit.
Like, I know all those things needed
to get done, but if we looked at like
the core priorities of either our team
or the company or whatever, did I move
towards that or did I just like shuffled?
deck chairs around on the
Titanic type of situation.
And so you don't always
want to get caught.
Obviously there's tasks that
need to get done that roll up to
someone else's priority that is
core to the business and stuff.
But just so that you feel like you
have like autonomy and purpose and
all that, it's like, you also want
to be able to knock off like rewrite
of the docs you've been trying to do
or the migration of the enums, Right.
So that you can put it
behind you and say it's done.
CJ: Yeah.
I think a lot of it too, on the
tactical side, not on the project
management side, a lot of it is
about energy and enthusiasm and like
how pumped you are to do the work.
And if you open up that project list,
wherever it is, and you're like just
dreading every single project on there,
like you're not going to have a good
time and you're probably going to leave.
So like having a mix of like stuff
that you're pumped about and stuff
you're, That, you know, like your
vegetables, but also you got to
have a cookie every once in a while.
That's like, all right let's just
like, you know, play with the CSS
animation on this, in this button
that's buried somewhere, you know?
So
Colin: I've been thinking about it
more and more like a conductor of an
orchestra where you have space and noise.
Right.
And so you have space between the
notes is what makes it into music.
If they all play at once without any
thought, then it's not going to be good.
And.
Yeah, you have to have some small wins.
It can't just be the big, huge, you know,
maximum effort tasks after, like you
can't run a marathon over and over again.
There's gotta be some like tasks to
come back and just clean some stuff up
that we knew we needed to do and come
back and maybe even just do a small bug
fix that people have been asking for.
And everyone's like, Oh, thank.
You know, that, that might get
more attention than the big
scary thing, but the big scary
thing also still needs to happen.
So kind of having like some good
little stop stopping points along the
way where you can look backwards and
just take a break or, or switch gears
and, and intentionally context switch.
Cause yeah, to your point,
you're going to burn out.
You're going to leave if not.
So
CJ: you feeling like, or I
guess I'm curious like where
you get your inspiration and
motivation and vision from?
Is it like the company, you know,
the CEO is like writing some vision
doc and then you're taking that
and deciding what projects to do?
Are you working with directly
with like product managers from
other teams to decide what to do?
Like kind of where does, where does
your remit, I guess, come from?
Colin: yeah, for me, it's mostly
going to be from product and they've
already done all of the up the
chain to the, all the way up to
the CTO and CEO and done all that.
So by the time it gets to us, it's
like, this is what we're focusing on
either quarter or half a year at a time.
And so like, we kind of know like what
things we're going to be releasing.
What things do we need to monitor
and join product meetings and talk
to developers and stuff ahead of
time, start getting docs ready.
Is the feature done enough
that we can start docs?
Can we get the engineers
to write the docs?
So we can edit them.
So yeah, it kind of
goes in waves like that.
And then we get like PRS for stuff
that just might not be correct anymore.
So there's, there's the less vision
stuff, but the vision of like,
we want to have a good developer
platform or good experience.
So like if the docs are
wrong, let's correct them.
Go get some quick wins and review
and merge some PRs and ship some
new docs and stuff like that.
CJ: Yeah, it's, it's a
tough balance to strike.
And yeah, like I think I've at least.
Enjoy building stuff really
quickly for people that I'm like
interacting with day to day.
And so, yeah, it can be, it can be
challenging if the vision comes down
from like super, super high up that
field might feel disconnected from
what, what you're seeing on the ground.
And so yeah, I don't know, but yeah.
Colin: Well, in smaller companies,
like you are closer to, like,
the whole team can be in.
CJ: yeah, yeah, yeah,
that is, that is nice.
Colin: versus like a discord, a
stripe slack, like not everyone's
going to be in the same room.
So the vision can change and game
a telephone and all sorts of stuff.
CJ: Yeah, totally.
What else is going on?
We already talked about DevRelCon.
Have you ever read that
book, Steal Like an Artist?
Colin: Don't think so.
Still like an artist
from Austin Cleon clone.
CJ: Yeah.
Colin: How is it?
CJ: So Mike sent me this book and I
had, apparently I had read it before.
I, I don't know.
On my Goodreads it said
that I had already read it.
I, I might've listened to it,
but this was the first time like
reading the physical version.
And I.
Really liked it.
I thought it was kind of, it was
like a fun read and the way that
it was laid out was kind of fun.
He also has another book, I think it's
called like newspaper poems or something
like this, where he kind of like takes
a newspaper and then uses a Sharpie
to like black out parts of the words.
And so what remains,
it becomes like a poem.
So it was like taking some
other thing and then doing that.
So there's like a lot of artistic
little kind of blurbs and tear
outs and ways to look at stuff.
But Yeah, I really enjoyed it.
I thought there was
good reminders in there.
For example, like figuring out people
you draw inspiration from for like
anything, like in, in my case, I was
thinking a lot about like devs that
I look up to and have kind of like
followed their career over time.
You know, major, you know, major folks
like Jim Weirich and Sandy Metz and
Gary Bernhardt, also like content
creators, Ryan Bates, Abdi Grimm Kent
Dodds, and then also, you know, people
who I've worked with or collaborated
with who I thought had like just insane
work ethic and high productivity and
we're just like really successful.
But one of the recommendations was like,
go find the people who you look up to
and then figure out who are, who are
the people that they looked up to and
kind of like follow the family tree up
and do research and try to figure out
kind of like, The foundational reasons
that, or, you know, kind of like core
values that might've driven that.
So that was kind of interesting to
think about and also like think about
areas where I might be curious to
find some more folks to like learn
about and maybe be inspired by.
Colin: Yeah, I think
this book comes up a lot.
Along with the war of arts as well.
Cause I think a lot of it also
comes down to like motivation,
inspiration, creativity, and like,
are you getting it from other people?
Like every thought.
Right.
Even when we talk about ideas on here,
it's like, we get afraid that someone's
going to steal our idea and go and do it.
Right.
And everything is a copy
of something at some point.
It's like, is it even once I have
like an idea for something, I
know there's like 10 other people
who are probably thinking on it.
Maybe are they actually doing
it as a whole other question?
Like, do you, cause it
takes a lot to do something.
So I do wonder, like, I'll have
to read this book, but I wonder.
How this is framed.
Like, have you, are you in
the middle of reading it?
CJ: no, I finished, I finished it.
Yeah.
Colin: Does it apply at all to the literal
steel, like an artist of AI and, and
CJ: that's interesting.
It, it actually, it perfectly does.
And here's how, so I think like one
of the most core tenants of the book
is basically this concept of like
an artist doesn't just like, Imitate
a, like the same exact artist.
Like they're, they're not
going to pick one person and
do something just like them.
What they're doing is like looking
at a whole field, like a whole bunch
of different artists and looking at
each piece and saying, what's the one
thing that I really like about that.
And in stealing like just the good
bits and then remixing it to be
their own thing, instead of just
being like, okay, I see, you know,
Colin's got that really cool.
Hat on, I'm going to put on
the same exact yellow hat.
It's like, okay, cool.
You're not, you know, you didn't really
come up with your own thing, but yeah.
And so in that way, I do think that AI,
because it is combining so many different
sources, like it is steel, like steel,
like, I guess it's like steel, like an
LLM, you know, just like yeah, exactly.
Yeah.
Colin: Interesting.
CJ: but it was, it was interesting to
me because I, I think oftentimes, When
people are learning how to code, they
say, Oh, I want to build clones of things.
And it's a great way to learn, like,
let me build a clone of Reddit or let
me build a clone of Facebook, or let
me build a clone of, you know, Netflix
or something, just to try to get an
idea of like, how would they go about
writing the CSS and structuring the
data model and building out the backend
and whatever of all these different
platforms, it's a great way to learn.
Like little tools and tricks.
But then at the end of the day, being
able to take all of those pieces
and instead of making something that
mirrors perfectly someone else's site,
you want to be able to make your own
site that has, you know, the, all of
the best parts or what you think are
the best parts of those other sites.
So
Colin: goes into the, the buckets thing.
Like there are so many
financial tools out there.
And then like, we're like, well, we
want to do it a little bit differently.
And I had to laugh because I was
listening to mostly technical and I
guess Aaron Francis is also building
his own tool, but like only for himself.
And it's also going to be
a project management tool.
And also it's like a
super app for themselves.
And there's like, I just don't
like the way that most people.
do these things.
And Ian was actually using a new
tool that I'll have to find that
does what a lot of these tools do,
but doesn't do the budgeting piece.
Because like, unfortunately, and
fortunately, once you hit like
a certain income, like you just
need to make sure that the buckets
are right, literally, right.
Instead of the indiscreet.
Like, do you want to categorize
20 transactions or do you want to
just make sure the buckets, right?
So good name, by the way, TJ,
CJ: Yeah.
Yeah.
Buckets.
cjav.
dev.
We're, we're, we're, I don't know, maybe
we've got to put up a domain for that
thing and just like let people run loose.
I, I hit up Stripe again with some
feedback and we'll see what they say,
but yeah, things are just still not
working as expected, so I don't know.
We'll see if it ever lands,
Colin: I'm hoping to have some more
time to work on that and some other
fun projects trying to get back into,
I think we've talked about so many
project ideas on here, the conference
room, booking and calendaring and
I'm feeling, feeling the itch.
I need to steal like an artist a
little bit and just make some stuff,
even if it's not a net new thing,
like just working on buckets and like,
we know what we kind of want to see.
I still am using co pilot very like.
I don't do the transaction recording
like I did the first month or two
that I did it, but seeing the buckets
and how it works has been helpful.
But still stuff I would do
differently and buckets itself.
And yeah.
I think there's, there's a big topic
that we'll be able to talk about
in a future episode as it pertains
to co working spaces again, and
business and, and all that stuff.
But I think we can
probably leave it there.
CJ: Yeah, there's your
there's your cliffhanger.
So you got to stay tuned.
Yeah.
Follow for part two.
Colin: Yes.
Well, good hanging out.
Where can people find notes for the show?
CJ: Yeah.
Head over to buildandlearn.
dev.
And yeah, we'll drop links to all
the resources we talked about.
And yeah, we'll catch you
in your earbuds next time.
Thanks for
Colin: Bye friends.