Subscribe
Share
Share
Embed
What is it like to ship software in big tech? Sean gives us his experience from multiple companies and what he’s learned. It's probably not what you think. It doesn't matter if you're vibe coding features or bash-ing devops, we all need to remember why we were hired.
Links:
Links:
Creators and Guests
What is Fork Around And Find Out?
Fork Around and Find Out is your downtime from uptime. Your break from the pager, and a chance to learn from expert’s successes and failures. We cover state-of-the-art, legacy practices for building, running, and maintaining software and systems.
Welcome to Fork Around and Find Out, the podcast about building, running, and maintaining
software and systems.
Hello and welcome to Fork Around and Find Out.
I am Justin Garrison and with me is always is Autumn Nash.
How's it going Autumn?
I'm just waiting for the dad joke that's coming out of this.
Just anticipation, okay?
We're going to build up to it right now, right?
And today on this show, we have Sean Getiky, who's going to talk to us all about a blog
post he wrote a little while ago about how he ships products at big tech companies.
Welcome to the show Sean.
Hey, thanks.
Great to be here.
I'm not going to start with dad jokes right now.
I do want to get some background here though, because I read this blog article, which by
the way, you are a very prolific writer on your blog and I love it.
Thank you.
I was like, you are writing almost every day about something and at least for the history
that I scroll back into, how do you do that?
Well, I think I seem more prolific than I actually am, because I have several like
drafts on the go at any given time.
And usually I'm either not productive or I am productive.
When I am productive, I sort of clear a lot of drafts.
So there'll be days where I publish like two or even three posts, which I think is not
a very good idea if you're a blogger and you want to like maintain an audience and get
people reading.
That's actually too much.
But, you know, blogging is not my main thing, so I do it anyway.
But there are like weeks where I don't publish anything and I don't I don't do any work.
So.
And I mean, RSS feeds exist for a reason.
So people should subscribe if they want to keep up at their own pace.
But this this blog post specifically, I know it made the rounds a little while ago as around
on Tacker News and some other people, how you ship at big tech companies.
I don't know if you ever mentioned which tech companies you were talking about if you're
allowed to talk about which companies you were working at.
I know Autumn and I both worked at Amazon in the past.
So we were at big tech.
Autumn is currently at Microsoft, so still big tech.
So we've we've been around.
I don't know about what is your experience with that in the past?
Yeah, sure.
Happy to talk about that.
And I think it's I think it's really important as well, because a lot of I write about this
too, in other places, but it's really hard to get like representative experience in the
tech industry, because companies are also different.
And you have to stay at a company a really long time to sort of figure out how things
work there.
And by the time you've stayed there five years, the situation has changed underneath you anyway.
So like, I think it's really important to say, you know, here's who I am and where I've
worked.
And for many engineers, it's not going to be like particularly useful to them at all.
But hopefully there's enough people who work in similar kind of big SaaS companies that
this kind of resonates.
But all that aside, Zendesk and GitHub are my two sources of like big tech experience,
basically, with about a five years stint at both and a little bit of work at like tiny
companies in the meantime.
But yeah, Autumn, you and I are kind of colleagues, I guess, or almost colleagues.
Get get our Microsoft subsidiary.
It's crazy, though, because going just between two big tech companies, it's so different.
And I feel like where we were 10 years ago or five years ago felt so different, you know,
like so much has changed.
Like I think a few episodes ago, we were talking about the difference between like just
that infrastructure has grown in the last 10 to five years.
And just think about the height of COVID versus now and the tech community.
It's wild how much things have changed.
Yeah, for sure.
I mean, the when I joined Zendesk, it was all like virtual machines and microservices
and like the rise of Kubernetes.
And that's entirely like nobody talks about that now.
There's like three or four kind of cycles that have gone by.
And then, of course, the other thing is that working in tech got real, real, real
different after about twenty twenty one, twenty twenty two.
Yeah, once once the interest rate was gone and investment was kind of disappearing,
then hiring wasn't paying as well.
And then it was about cost savings.
And now we've had a lot of people leaving.
But just think about what it was to like, I mean, like, I don't know, like.
Two thousand and fifteen, two thousand and I mean, even nineteen and two thousand
and twenty two was like a completely different ballgame.
You know what I mean?
Those two were like and then you see the peak of COVID and it is wild how far we
fell like every time there's like stuff going on, you're like, is this the new normal?
Or, you know, like you never know, like, which is the new normal?
Yeah, no, I agree with that.
The the cultural expectations and just the culture in general that like the places
I've worked at has changed dramatically.
Like, and I know it's the same at at Zendesk as well, even though I left.
I left there around the start of COVID.
I have my brother works there right now.
So absolutely.
That's awesome.
Second row.
Second row seat to what's going on.
I think that's I actually really liked your blog, but I think that's a part
that confused me and it wasn't that you were confusing me, but it was like.
I think big shipping at a big company and just shipping in different areas of a company
are very different, right?
Like, so if you're building a button or things for people to interact with, like in a
retail setting, that's very different than building a language, right?
The process is very different.
The kind of the cycle in which you release and what you're releasing and what you're
interacting with, like it's crazy.
Like sometimes you can be doing straight, like adding a feature to a code base or you
can be doing like releasing or, you know what I mean?
Like the just, you can have two jobs at the same company and it'd be like night and
day, skill wise, and then you can be releasing something at a cadence, something huge,
like an operating system or language, and then that's very different and they're very
different from each other.
So it's like already in the same company, it can be different in two different
companies.
It's completely different.
And then when you think about the fact that there's been so much change, if keeping
essentially in your blog posts, you said shipping is keeping, you know, the people
that pay you basically and your leadership happy, but how do we even know what that
is now?
Like, you know, like.
Yeah, um, very, very good points there.
Like I, I want to respond to the, to the first thing you said first, which is that,
um, different like teams and different programs of work at large companies operate
very differently in, in, in almost every single way, like working on an operating
system is very different than, than like releasing kind of front-end changes for,
for a SAS.
Um, I know before we started recording, we were talking about how much riverside
changes, like the cadence is so, is so fast on that and releasing, releasing new
versions of windows is sort of the, the, the exact opposite.
So just, just to put my cards on the table there, I've, I've worked in, uh, kind of
SAS feature stuff, uh, my whole career and, and some, um, kind of internal
infrastructure is stuff, probably the most like, uh, fundamental kind of thing was
like the, the markdown rendering engine on GitHub.
I, I, um, as part of the team that owned that for a little while.
Uh, so it wasn't, it wasn't exactly like building a button, but it still wasn't
kind of, you know, working on like the TypeScript language or, or something like
that.
Um, but yeah, in terms of, um, how do you, how do you know what the people, uh,
above you want?
I think this is, this is a really interesting question in some ways.
This is like the big question, but, um, certainly the more you're working on
the more you're working on things that are like central to the company mission,
the more you just get told.
So when I was working on, on like at GitHub, for instance, uh, I, I, I started
out on kind of gists and these kind of features that are really near and dear
to my heart, but maybe aren't so like central to the, to the company mission.
Um, and it was, it was kind of hard to figure out what the, uh, what the goals
were that sort of leadership wanted with that stuff.
They sort of just wanted it to like be better and people to like it.
It was that level of generality.
Um, and then like, like many people at GitHub, uh, I, I moved over to the, uh,
co-pilot team where let me tell you, uh, there was a much clearer mission and
there was a lot more, a lot more urgency.
It was a, it was a very different ball game.
Um, and in that environment, figuring out what leadership wants is, is I think
actually pretty easy because they tell you, they, they are telling you over and
over, they're like every meeting and every email and stuff.
They're kind of telling you what they want and what projects they care about
and what they want to see ship.
Are you allowed to speak about that experience?
Like, you don't have to go into detail, but I guess like, was it fun?
Was it, you know, like, I mean, like, what was it like, I guess.
Yeah, I can, I can speak, uh, at a pretty high level.
Um, yeah, it was fun.
I think it was a really big change.
It was, it was almost like for me emblematic of, of the general vibe shift
and in tech around, around 2022, 2021, um, just this kind of shift from like peace
time to wartime almost, like from working on these systems.
That kind of these like sleepy systems that, that, that see a lot of use
and, and the kind of support, this functionality that people love to
working on this like brand new things with, with this new technology that
like is making a lot of money and, and, and people are like using a lot and
liking a lot and kind of learning as they, as they go.
Like it was just, yeah, I don't know.
It was, it was fun.
It was like, it was exhilarating.
Um, it was a steep, a steep learning curve.
I think a steep learning curve, like technically, but, but mostly
like politically and organizationally kind of the level of coordination
that has to happen when you're building something like that.
And the, uh, as you might expect, the, the, the amount of people who have
strong opinions is, is, is very, very high.
Like when, when you're working on the Markdown pipeline, you're really
just dealing with five or six kind of long-tenured, very senior engineers
with like strong opinions about this stuff.
And it's more like a, like a council of elders kind of situation where
you're trying to figure stuff out.
Whereas, whereas making changes on, on a product like co-pilot is, is, you
know, there's people with, um, chief in the, in the job title kind of contributing
to the conversation and, and people like both at GitHub and, and, and at Microsoft.
It's just a whole different kind of way that like decisions get made.
I love one too.
Like very experienced senior engineers have like, I won't say an argument, but
a technical discussion, you know, and it's like, it just makes you picture
like the Lord of the Rings and like two people and like, like full wizard
stuff and like beards and like the whole time you're just sitting there with
popcorn because you have like, you're like, I have thoughts, but I'm not
saying them, right?
Exactly.
And you just sit there and listen to both.
Like sometimes those are better than like college classes.
You know, like you learn so much.
You're just, I used to love, uh, Amazon had the, the Wednesday ops meeting.
Uh, did you ever go to this autumn?
They were, that's the scariest meeting I've ever been in in my entire life.
I would not like, I would watch those meetings because they're so fabulous.
But if, if people are familiar with it, they had these, the ops reviews
that are every Wednesday and you would, they, it's been a wheel.
Let me tell you, your team's on that wheel.
Yeah.
And it was, you know, you, you would have to, you would review all the outages
from the week before.
Tell them about the fact that you hold your breath, the whole wheel turn.
Like everybody is sitting there holding their breath because what you're holding.
Not us, not us, not us.
What you're doing is that wheel, because it's usually like builder's tools
or like a bunch of orgs, right?
But it's a weekly ops of like all the like important AWS services.
So they're spinning this wheel to figure out who is going to present their COEs
cause you don't have enough time to do everybody's.
So everybody brings their most important COEs and then every, it's like, but I,
I love what it's supposed to be about.
It's not always that, but it's supposed to be about everybody bringing like your,
what is the, what is the acronym for COE?
It's something of excellence or no, it's not excellence.
Something outed, no, something outage anyways, but it's supposed to be everybody
bringing your correction of error.
Yes, correction of error.
And in theory, it's actually a good model.
And like, you know, like I give Amazon their stuff when they deserve it.
But you bring your, everybody, you write a paper.
So after the outage, you write a paper and you're like, what could we have done better?
And it's supposed to be no blame and the kind of way of like, yes,
this dude to press the button, but if there was a button that can bring down
a tier one system, we fucked up because it was a bunch of eggs, right?
So like, I love that part.
When you see like the most just genius people sitting there talking about just
building something, which goes back to what your blog was about, shipping something,
right, building something at a certain scale is so different than adding a
feature, which you can be adding that feature at scale.
That's another thing too, right?
Like, but they're, that is scary.
Like, what if you put a button somewhere and they hate your button or what if it
breaks stuff?
You know what I mean?
So, I mean, there's a slight tangent from this.
I do think that that meeting specifically is like a key to Amazon's operational
excellence.
It, no, they do a lot of things wrong, but they do a lot that they do that.
Process specifically, because everyone can see it, there are VP level people on
that call talking about operation stuff.
And you just learned so much stuff passively by watching.
Hey, we're designing this new thing.
Here's how this is going to look.
And someone's like, have you thought about this side of authentication?
Have you thought about this?
It is a master class at learning at scale.
Yeah.
And it was a huge time sink every Wednesday for three hours or something like that.
And it was like an hour and a half.
Yeah.
It was, did they ever go hour and a half?
It felt no, because the two principles start arguing.
And look, there's a lot of meetings that you drop after 10 minutes over.
You don't drop that meeting.
You're sitting there with popcorn.
You're like, I would just put that one on in the background.
I'm going to do some work and I'm going to pay attention to what you're doing.
Like that's the one meeting I want to show up for.
Because like you learn so much.
You see some really smart people that nobody else would ever argue with,
argue with each other, which is great.
Like it's like reality, just the open argument of like, but not a bad way.
We're not seeing who's right.
Who's wrong.
Yeah, we're coming to the best conclusion.
But Jude, you learn so much because they're, they both have,
nobody doesn't have a valid argument in this.
You know what I mean?
Like both of them have amazing.
Yes.
But it was great.
The thing I was actually trying to get to with that was.
Sidequests.
Yeah, it was a sidequest.
But the thing that I've told a lot of people over my career of like,
Hey, I want to get into tech.
I want to do something new.
I want to go somewhere else.
I always told them, go to the thing that either is the closest to making money
or has the most attention because both of those things are where people
will just know that you're doing work because a lot of the infrastructure,
I love infrastructure.
It is not the best career path for growing.
If you want to be, you know, like a top level VP or something like that,
because most companies just don't have an infrastructure engineer at that level.
It's not something that's visible.
It's not part of the shipping culture or the thing that even makes it into
like a shareholder meeting like, Hey, we deployed another Kubernetes cluster.
Nobody cares, right?
DevOps, DevOps, infrastructure, SREs, they are called when something's wrong.
When you've messed up and it's all out, they call you, but nobody notices
when you did a good job.
I mean, I mean, some companies really praise the firefighter, right?
Like, but that's not a, we're not like promoting to have more of it.
But also, like that's tricky too, because like in a way, like there
shouldn't be fires, right?
Like, I mean, they are always going to be fires to an extent, but then
that gets out of hand because it's like them, you're constantly chasing
fires and there's not enough time to make, you know, to fix those corrections
before they become fires, but a lot of that becomes like a whole
another conversation.
Every, every group that I've worked for had the one person that would
just swoop in and fix something, right?
You're just like, Hey, we do not know what's going on.
Everybody has a Batman.
Yeah.
They would debug it further than anyone else and they would find the actual
root cause like, Oh, here's the one line change that fixes that whole problem.
Right.
It's just like, Oh, that was amazing.
How'd you do that?
There's always one senior and for some reason they're a senior, right?
Because like the principles, they know everything in their depth area.
Usually there's one senior who like, they've touched everything and they can
fix anything and everybody on the team can take it so far.
And when you're absolutely up Schitt's Creek, you call that person.
I think like one of the reasons that that kind of archetype is, is, is
more commonly found in like senior than principle.
Um, and of course these levels are kind of different between companies at
GitHub.
There are a lot of staff engineers that would fit that as well.
Um, is that like, you have to be really familiar with the specifics of the
code to figure this stuff out.
And the more senior you get, sometimes the more you kind of get into this
realm of like generalities where you like, maybe you don't quite remember
exactly like line by line, how this thing works anymore.
Cause you're dealing with other stuff as well.
I also think that like the principle levels, the first one that stops solving
problems with tech, with technology, right?
We were like, really like, this is a process problem.
I'm not going to write a line of code to solve this.
Not know if that's always true, but it's a higher level.
You know what I mean?
It's a higher like view of the technological problems usually, but it
also depends cause like if you're deep in Java land, right?
Like each principle is part of like a project as a maintainer for a project,
right?
Like, so I think it depends, you know, but it also what you mentioned.
So like it's interesting because do they usually have staff and senior in the
same like, I guess tree or like pyramid, I guess, because what is the
difference between staff and senior usually?
I mean, the Amazon tree was senior principle and then senior principle, right?
Cause the L seven, six, seven, eight.
So principle at Amazon is kind of similar to staff then in my mind.
Cause it's weird because it's an architect at Microsoft above a principle.
Or is that the same?
Microsoft has like 150 levels.
Yeah.
Microsoft is terrifying to me.
But then like what is like GitHub is GitHub different because GitHub was
technically a company beforehand.
Yeah.
I mean, GitHub goes, uh, well, I think it's maybe changing now, but like from
my memory, like most of the time I've been here, it's like mid-level senior
staff principle.
That's it.
And then at, um, at Zendesk, it was like senior staff, senior staff,
distinguished senior staff.
And then see, cause it seems like a lot of companies just trade staff in senior,
you know, like, so if they don't have a senior, they have a staff, but some
of them will actually tear it.
And I'm like, well, which one comes first?
I guess not that it really matters.
But staff is always above senior, um, in the places I've seen, but like, I
wouldn't be surprised if some people do it differently.
Like back to, back to the shipping topic.
Uh, we mentioned like autumn, you were shipping Java at Amazon.
I was shipping with Kubernetes, like very different things, but a lot of the
process still kind of felt the same to me.
Everyone, everyone was trying to ship for reinvent at Amazon.
When you work for dev rail, did they let you actually ship things to production?
I, I only wrote one line of code that ever, or one section of code that ever
ended up in any production system.
Um, it took me a week to learn the internal tooling to make that happen.
It is a whole, it is a thing, but a whole bunch of like external, like public
facing stuff that was used by customers in various situations, but not internal
Amazon says I wanted to stay away far away from that as possible.
Um, but the, but a lot of the stuff I felt like even across the different
orgs of Amazon's different products, a lot of the shipping still felt kind of
the same where we're pushing software.
Once a customer gets it, they, we like an interact with them.
Amazon shipping bar was always pretty low.
We got things out that were pretty terrible to get them in the customer's
hands as early as possible and then we iterated on them over years.
My experience at Disney was, was the exact opposite, especially at Disney
animation where we shipped what I call box software, like shipping movies is a,
is just such a, it's a box software sort of experience where literally I
would see my software on a shelf in a target, right?
It's, it's, it's part of a Java interpreter that's on the DVD or something
like that, but it's not the actual like software that I maintained.
And then it wasn't until I was maintaining software, I think that
everything you say in what is shipping became a lot less clear once we had a
SaaS, once we had to maintain something after it was shipped, right?
You, you ship something and now maintenance starts with Disney shipping
movies, once I shipped something, I was done with it and it was fantastic
because everyone knew, Hey, we're all done with this thing now.
We move on to the next thing.
And I felt like that was a big difference in my career.
And I, and just knowing box software from the past, like people were like,
ah, I'm done with office 97.
So I don't have to touch that one anymore.
Um, but everything I was like, it was very clear when the thing had shipped.
And now, as you point out, it's very unclear when a ship, when something has
shipped.
Yeah, well, that's like a, yeah, that's, that's, as you say, that's
true of like SaaS software in general.
I mean, when is, when is copilot shipped?
When is like, when is like GitHub shipped?
Like GitHub is a, is a, is a product, but each, each feature within
GitHub has the same thing.
Like when a, when a poor request shipped, when a poor request reviews shipped,
like all of these things are constantly being worked on.
All of these things are, are constantly, constantly changing.
Um, and I've, I've seen lots, lots of engineers take their feature and kind
of get, kind of get trapped by that almost of, of, of this, this idea that like,
well, it isn't done yet.
There's, there's more things we could do.
There's always more things we could do and, and working on it and working on it,
like long past the point where I'm long past the point where there's any
enthusiasm from leadership, uh, for them to continue.
How do you think attaching versions to things you ship affects this?
Cause I feel like there's a difference there with horrible.
It makes it just, oh my God, Java eight will live to like the universe is
nuked forever.
Yeah.
I mean, like, like versions of like libraries and, and, and extensions and,
and things where someone could be running the old version years and years after
you, after you ship, is that what you mean?
Just in general, like we in a SAS, people shouldn't care about the version, right?
It's just like, I go to riverside.fm and I use the interface.
I have no idea what internal version this is called, but for products that I'm
supposed to build on, I need these defining lines of like, oh, that's version eight.
That's version nine.
I can't move to version nine until I change these things, right?
Like you can have breaking changes.
You can do things to be able to do that.
But I also feel like internally at companies, they use version numbers as
a way to say they ship something.
They're like, we ship version job eight one.
It's like, what, what does that mean?
They're like, I don't know.
I just arbitrarily made it up.
So I could say I ship something.
But there don't, but a lot of people do not arbitrarily make that up though.
Like, and I don't mean just Java.
Like, I mean, like there are huge debates on like epochs and just all
kind of things in different languages.
Plus like the lower level you get, like dependencies are such a big deal.
Like I think that like when you get to do like a certain level of programming,
it's like you just get to like a huge respect for how many dependencies you
can pull in to have like a stable release because like you are going to
pay a great deal for each new one, you know?
Yeah, yeah, for sure.
But like it's funny, like a sort of one end of the spectrum, you have like
versioning is like technically really hard, but philosophically really easy.
Cause you're just doing semantic versioning and there's, there's pretty clear,
like, I don't know how to count principles for you.
Yeah.
Like, is this a breaking change?
Does this change the interface?
You can, you can determine that like almost purely, purely program programmatically.
And then the further you get up the other end of the spectrum, versioning becomes
like technically pretty easy, you know, like you can call something whatever
version you want and it's not your dependency problem isn't as bad between like,
I don't know, like, yeah, I don't know.
I don't actually have a good, a good example.
But the, the philosophical problem of, of like, is this something new?
Is this a new version?
You know, like to what extent is calling this a new version, a marketing decision?
That, that stuff gets really, gets really murky because I'm like, what is, what is
a product, right?
A product is a thing that is marketed.
It's a thing that is sold, you know, it's not primarily a technical thing.
So to like a lot of engineers kind of come into this problem and they say, well,
oh, it's technically the same.
So like it's stupid to give this a new version.
And it's like, well, no, like you're, the technical thing is sort of incidental.
Like what you're working on is a product in the market.
It also depends on if your versioning or you're having to update is dependent on
other people and like on the dependencies or if you get a CVE or if you have to
patch something.
But I also think something that you said was really interesting is that I think
there are some people who are very good at solving technical problems, but they
don't have a mind for the business side and they don't see how business affects
engineering.
And then there are some people who are good technically, but they have that
other skill of being able to see where techno technology fits into business and
being a product.
And I think that we should almost at least in certain realms give that a little
bit more credit because being able to understand the business needs and how
that marries technically is really important.
Like that's a product manager, right?
Like that's the, that's the role of the product manager, that bridge in between.
See, I, I disagree.
I disagree.
I think that's the, I think, I think that's the role of, of, of an engineer.
And this, this is the thing I say that I think makes, makes people angry the most.
But it, but it's a, it's a thing I believe, which is that if you are working in
a tech company, if you're not working on your own project, engineering is in
service of business needs.
Engineering is a tool in service of the needs of the business always.
That is just what it is.
That's what, that's what you're being paid to do.
You're an engineer, you're a good engineer when you understand the business
needs, cause you can't make the right decisions if you don't understand the
business needs.
If you don't understand, like there's got to be more effort, especially now
that co-pilot or just any AI is going to do more for us.
Like understanding how someone's going to use this, understanding the
restraints that that person may have using your product.
Like I think that's the good, like that's what makes you special versus somebody
who's just going to like write a bunch of code to me.
Now, I guess the one thing I would push back on is most of the time that I've
seen at companies, engineers don't have the information they, they need to make
good business decisions, right?
Like at Disney, I was never told how much money, you know, something costs.
And it's just like, oh yeah, you just, here's your, here's your task list.
Like it gets filtered down under eight layers of management or something.
It's like, okay, here's the five tasks I need to do.
I can't infect how the business is going to change for that.
And if I did, or the times I tried, I was in trouble because I stepped out
of my lane and I was doing something I shouldn't have been doing.
Amazon was a little bit different where at least on the product.
Weekly business reviews.
Yeah.
The weekly business reviews was exactly the thing that I never got at Disney
where my very first meeting, I showed up and they was like, here's how much money
EKS made last week.
And I was like, I think I'm in the wrong meeting.
I'm like, no, no, this is just a, this is just weekly business room.
Like, what are you talking about?
Like, you don't tell everyone all of the money numbers.
Well, then how else are you going to make a decision?
I think that's one of the, again, one of the things that makes Amazon
successful is the fact that they make everybody show up to those meetings
from essays to product to, like, because everybody needs that understanding
to be able to be good at your job.
And it also holds you accountable because when you keep saying something's
green and then it goes yellow and it goes red and you're all in that
meeting, you've got to be able to explain that.
I think I want to press on something a little bit, which is that
when I say that like engineering is in service of business needs, I'm not
necessarily saying that engineers should be out there making business
decisions and out there making business bets.
I think sometimes that's appropriate in some companies, but let me, let me
give you a hypothetical and by hypothetical, I mean something that I've
seen about a hundred thousand times, which is like, there's this project
happening, your manager comes in and says, like, hey, like, we really need
this, this endpoint, this feature, this button to do these, like, three more
things and the engineer comes back and says, like, no, no, we can't actually
do that. We have to, we have to put that in a background job.
It's going to have to, the interface is going to have to be different.
Customers are going to have to poll this API instead of just getting it back
immediately because otherwise it's going to push the, push the endpoint
over 200 milliseconds and an endpoint over 200 milliseconds is, is, is
unacceptably slow.
Is it like, is that engineer right or wrong?
Right?
Like, is it, and my, my perspective and the, the thing that I think is
kind of controversial is that I think the engineer is 100% in the wrong
there, that it's, it's just, it's just incorrect to say, actually, you
know, it's more important to ship like a fast, efficient API than it is to
like, deliver this kind of business, business need.
And of course there's like room to push back.
And of course the situations where like a 200 millisecond endpoint is
going to have knock on effects on the rest of the infrastructure and, and,
and cause problems that are hard to anticipate and so on.
But I've, I've seen over and over again, just in the simple case
engineers saying like on moral grounds, like I refuse to ship this.
And when I say moral grounds, I mean like aesthetic grounds, like this is,
this is going to be too slow.
This is going to be too janky.
Like I'm not going to ship this and, and just leaving like leaving so much
value on the table and like just not shipping things that customers want.
Like, um, and I think that, that, that, that dynamic can happen.
Even when like almost no matter how much business context you have, because
it's, it's just a matter of like the engineer not listening to what they're
being told.
And not only agree with you, but I'll take it one step further.
This is why we get contention as someone who's been a solutions architect
and engineer, a product manager, and then an engineer again, we don't all
respect each other's jobs because we think that we all don't do with anything.
Right.
And I think a lot of time and times engineers can be like, but I do all
this work and product managers don't do anything.
But like you all need each other to break the right ecosystem.
Right.
Like, like you said, I don't think that they need to make crazy business
decisions, maybe if you work in a startup or, you know, certain areas, maybe,
but there's certain technical decisions that you can't make and you can't make
well and you can't prioritize and do things effectively without knowing why
you're making that feature.
And like sometimes our product manager could, if they're not very technical,
they could be like, Hey, you're that they're, they could be promising
something that's impossible.
Right.
But an engineer could be some, okay, I'm going to be real.
Sometimes engineers, we get a little like, you do too many of the hard things
and then all of a sudden you feel a little goddess and like they'll be out
there just digging in for things that you don't need to dig in for.
Like sometimes it's art for art's sake of, I just want to build this really
cool thing because it's hard, but your customers don't want that shit.
Like nobody wants it.
Nobody asked you for that.
Like, you know, and if you don't have a good balance between like, this is
the right technical decision because it's going to make our customers lives
better, you're just building for stuff.
But like this is a business.
Also, you know, like it has to make money and people need to like it to a certain
extent, which I think like there's, it's just like an ecosystem.
It all has to balance a certain amount.
And we all need to understand where we're all going.
It's like planning a trip, but you don't know where you're supposed to end up.
Like.
I agree, Odom, but people get really upset when you say that.
I know.
People really talk like that.
We're going to be French on like, we're right here.
The one thing that I would push back on is sometimes the, the person asking
for the request or the customer asking for it, don't know the constraints.
And, and necessarily how much work that's going to take, what risks that's
going to have to something else that's happening on the back end or the person
they're asking is, isn't given the ability to do that, right?
Like, I need you to change this button.
It's like, but that's someone else's service.
And I, I can't change their code, right?
Depending on the dynamics, the politics, whatever the reason, I can't
change how they set up their service.
So I'm constrained on their two nines of availability and their 40 millisecond ping.
So, you know, I could tell you, I could do it this way, but I just, I can't
because I don't have the ability to do that.
And then at some point you do have to just push back and say, this isn't possible.
You, if you want this, if the customer wants this better, then you need to take
that off the chain and go figure out how that works because I don't think
anybody's ever said that engineers need to be like beholden to somebody asking
for stuff.
They just need to understand why they're asking for it.
Because 100%, especially when you're dealing with managed services, people
think that you just do some kind of crazy magic in a hat somewhere and you're
like, bro, no, like there's real things under it with a real constraints, you
know, and like sometimes you're building things that had ever been built before.
So like, you don't even, like you end up finding out these weird edge cases of
how somebody used something completely wrong.
Like for instance, when they took down, was it Kong, the search engine, but they
took it down with like the number of connections to that like database, you
know what I mean?
Like sometimes you don't even know what the constraints of that is until you
learn them the hard way, right?
Because it's a new thing that you've never done before and it's at scale.
But what I think we mess up with, like I think 100%, you should be able to
push back because like they don't even, but sometimes after being an essay and
especially like a specialist essay, it's like a lot of pressure because they use
your product more than you do.
And you need, you are now the person that's being called in after they've
hit customer service everywhere else.
After a team's looked at it, they've called the senior engineer, you know,
like the whole team is mad at you.
Okay.
They want to know why this doesn't work.
And I'm going to be real.
Sometimes like when you do, when you start off as a generalist essay and you
have to ask a lot of questions and then you get to be a specialist, right?
And you learn that customers don't always know what they want.
You have to, this, this very like, this dance of a relationship of where you
have to ask them questions to get the information because they'll be like,
I use this thing and I love it.
And I'm like, do you love it?
Like tell me about it.
Like, you know, like they'll be like, I, I use Cassandra and we're just,
we're really good at it.
So we don't need to manage database and I'm just like lies.
Why are you here then?
You know what I mean?
Like how many times are you being paged at 3am?
How many times have you like lost a node?
Like sometimes customers do not know what they need.
And you have to be able to ask the right questions.
And I think that's almost the skill in itself of being able to figure out,
does this really actually work for you?
Can I help you find something that's better for you?
Maybe you don't need this button.
Maybe you need a retry.
You know, it's just, it's a whole dance of how that goes about.
I feel like I want to chime on the podcast.
Anytime someone says that someone's forking around or finding out.
Dude, I want, I want, I want like a sticker, a chime.
I want, I want like, I want you to sit.
Like I want you to do like one of those like sound bites so I can just play at people.
Like, I won't know.
I want a beanbag that I can throw it at people when they do stuff that's dumb.
Cause like, have you seen the world lately?
I'm just like, what are you doing?
Stop it.
Going back into your, your posts, Sean, about one of the sections you call out
here is communication.
And I love that this is part of shipping.
Because it's something that I don't think a lot of people outside the industry
have had the privilege of being a part of.
And a lot of people don't understand like what it's all about.
And you say the maintaining trust is the top priority, which I absolutely agree with.
And I think that's a good way of summarizing it, because the main thing
that I remember shipping that was like a big, high pressure launch was Disney Plus.
And we were, we were like, Disney Plus was going live.
We know it was going live.
We were rolling it out across the world.
I was only in like a few regions or whatever at first, but there was just
like the people running that whole thing was just like, here's, here's where we're at.
Here's what we're doing.
Here's why this is going to be delayed.
And then day of it's like, here's the Slack channel.
Join the Slack channel.
Everybody watch.
We're just going to announce everything we're doing one by one.
And it was fantastic.
Just to see everything you basically call out in this blog was like, Hey,
if something goes wrong and you, you haven't thought about it, then that's on
you for not being trustworthy, right?
Like all of these contingencies need to be kind of thought of.
And it was also the first time that I realized how much better the internal
systems at Google were than the apples.
Just because, just because you find any opportunity to.
I was blown away by this because we submitted like, like the app had already
been submitted.
It was already approved and we're like, Hey, we are going live.
And the both systems have like this.
And again, this is back in 2018.
So I'm sure there's lots of change, but like there's a button to like, okay,
make this live now.
And like, they're like, we push Google's go live, but they literally
sentence like, we push Google's go live button.
We push Apple's go live button.
Google's live.
And I'm like, wait a minute, like how, how did it, it's just like worldwide.
It's the apps available.
How do they do that?
I was like, okay.
They're like, it showed up on Chromecasts first for some reason.
It's like, Oh yeah, it's on Chromecast.
It's here, it's here, it's here.
And like, okay, when's Apple going live?
Like it usually takes about four hours.
They're like, it's like this R sync process that's like texting, they're
sending text files around the world.
Like what is going on here with Apple?
It was just fantastic.
It was just like, okay, this is a little different.
I would love to know why though.
Yeah.
It was so, it was fascinating just because it's like, you know, Google
built these global systems that had all of these.
Benefits of like, this is how this is supposed to work.
And everyone else kind of caught up to it at some point, but, but
the whole communication also puts things in review though.
Like Apple will leave you on this was like post review.
Like like Disney plus apps were, were there.
They were approved.
We're just like, cause you can hold them.
You could say like, Hey, I wanted approved, but I don't want it to be
available yet.
And so you could, cause you could do like test flight and all that stuff too.
Okay. Sorry, Apple.
I can't have your back on that one.
I tried to help you out.
I don't know what happened.
These, the apps were definitely in already done, reviewed and ready to go
for like weeks beforehand, but just the communication.
Yeah.
About communication, I, I want to kind of like emphasize that.
Cause I think people here, communication is like top priority and communication
is priority number one.
And they sort of nod and go, yeah, yeah, it's really important.
I don't mean that it's really important.
I mean that it's top priority.
It is more important to communicate about the project than it is to
ship the project on time.
It is more important to communicate about the project than it is to
ship the project without bugs.
Like communication is the most important thing when you're shipping a project.
Like, and, but none.
The other side of that was being part of the Kubernetes release team, right?
Cause Kubernetes is this big project.
That's a bunch of volunteers that are all like running around trying to get
stuff in at the last minute sort of thing.
And all of it is communication.
Everything about shipping Kubernetes is like, okay.
Kubernetes is great at communication and structure though.
That is one of the most well-structured open source projects.
Because it's clearly defined.
Like everyone's role is clearly, yeah, and, and there's teams and there's
projects and, and there's shadows and there's everyone else to train them
up into that, all that stuff, but also the way that.
So like Java has one big, just umbrella of open source, right?
And then Linux has got it, all these little things everywhere.
Kubernetes does really well at having like multiple maintainers and projects
that all work and do their own thing, but have this great umbrella that keeps
it all together, you know?
So they're, they're both independent, but it's kind of got one thing to house it all.
But also like, can you go more into the communication aspect and tell us like,
like, cause, you know, people might not have read your blog.
Like, can you tell us what you really mean about that communication?
Because this is something that I think, like, first of all, earning trust
and keeping that trust is super important.
And I think that people don't, this is like, people talk about how to be technical,
but there's so many parts of the process and just the other parts of engineering
that nobody talks about and tells you.
And I think we can really lack those skills that make you a whole engineer.
So can you talk more about that and like tell people kind of what you've met
in the blog and like what you said, like elaborate?
Yeah, for sure.
So, so the, the, the core of it, like the reason why communication is so central
and so much more central than even like the actual thing that you are shipping
is, is that like at a large company, like shipping something is almost
defined by communication.
Like it's something is shipped when people know about it.
It's shipped when your management chain, like is happy with it.
It's like whether something is shipped.
It's, it's, that's, that's defined by, by the flow, the flow of information
inside the org more than it's defined by what is like literally available.
Get push doesn't count.
Yeah.
Yeah.
Get push doesn't, doesn't ship like announcements ship, telling people
about it, ship puts putting something up where people can like go and find it.
And then they actually find it like that.
That's also that's so much pressure.
What do you have to have the good announcement?
Like you can be great at writing code, but having to say something
that millions of people are going to read and make sure you don't say
something stupid is so much pressure.
Well, fortunately, at least in my experience, the, the announcement
side of things has been handled by like a full marketing arm and a whole
team of people kind of, you have to worry about that.
So I don't, which is, which is really nice.
But the other thing about, about communication, like the path
that's sort of more internal is, is that when you're like leading a project,
you sort of live and die on trust.
And when I say trust, I, there's all kinds of trust, but I, I, I specifically
mean the extent to which your manager and your manager's manager trust you to
do like sensible things with the project, which is partially to like get it
out on time, but also like not to go rogue and like do something really weird,
not to do something really like completely unaccountable.
Like, um, that's, that's a, a worry that I think a lot of kind of
engine, like a lot of engineering managers have that like engineers kind of
not to put too far, like almost like just can't be trusted is what I, is what
I want to say, which is an awkward way of putting it, but I mean, I think
can't be trusted with their, what they need, right?
With the manager needs, with the business needs engineer wants to do
engineering things and not necessarily satisfy customers.
And I, I can totally see.
I love how everybody talks about engineers, like feral chaos goblins that
just sit in a room somewhere and like write code and like, they're not completely
all like, you want to argue, but you're like, no, I mean, I, I, I, I do think
like, yeah, I do, I do talk like that, but sort of to, to the extent that I do
it, think about the meme, the memes of like, they're just dark, they're like,
they sit in dark rooms and you just throw pizzas in and nobody shot.
Like that's been the attitude.
Like people act just, that's the people's idea of what an engineer is.
But I mean, I'm an engineer, right?
Like I've, I've, I've been an engineer in my whole, my whole career.
Like I, I love engineers.
I am one.
Um, and I think like the extent to which I kind of give engineers a hard time
is because like engineers already know that it's important to, to do things
technically well, they already know that it's important to like, you know,
write code properly and, and, and, and factor their app appropriately and blah,
blah, blah, like this, this, this stuff that I talk about, this is the part
that I think a lot of engineers don't know.
So if you just listen to that in isolation, it probably sounds like I have
a very negative opinion about how engineers function, but it's not true.
It's not true.
I love them.
I mean, I don't think that's a bad thing.
We are kind of chaos goblins.
We own that like, but I think that I hope there are more people like you that
become more senior and that like our staff or leads, because I think again,
like you just said, we know the technical things are important, but there's
so much more to being an engineer than writing code.
And I hope that we continue to make better, more well rounded engineers and
not just people that are deeply technical, but have no people skills or
process skills or these kinds of skills that are deeply important to the process.
For sure.
As long as it's like, as long as the technical part is also there, like you
actually, you actually do have to be technical.
Like that, that is actually a hard requirement.
But we've never let anybody forget that part.
Yeah, true.
Like, you know what I mean?
Like, yeah, exactly, exactly.
I think people are always like overly compensating in that area, you know,
while being like horrible at all the other things.
I mean, I don't know.
I think the vibe has changed on people thinking they can do more than they
actually can because of things like AI and look at all the stuff that I can do
without actually having the knowledge of how it works or experience.
I mean, and this isn't maybe big enterprises, this isn't like large things,
but just in general, I feel like a lot of the shift of, and I don't want to
gatekeep engineering, like I think they are doing engineering, but like they
think they're God a lot sooner than when they actually like might be praised
at a larger company of saying like, oh, you actually are doing like a really
good thing here.
Dude, I'm a woman in tech.
They've all thought they were God forever.
Like they just, they're like, it's amazing.
Like some people have deep embossed or syndrome and some people
you're like, bro, you could use.
Yeah, I bet.
I mean, like when I give people advice about how to lead projects, I do try
to suggest that if they can find some way to foster an unreasonable
confidence within themselves, they should do it because it really does help
to like have this almost unjustified self-belief that you will figure
out a way to make it work.
Like, it can be tough to interact with, I know.
Being an optimist is helpful, right?
I actually think that's important in some people because I feel like
you meet these people and they're so smart and they're so good at it, but
they're never the people that think that they have like, you know what I mean?
Like they're the people where you're like, dude, if you have imposter syndrome,
I'm screwed.
Like, you know what I mean?
Like, but then there's always that like those people who have like the God
complex and you're like, you could use like it.
Something, something you didn't call out in your communication that has at
least been my experience in gaining trust with leadership is literally just
sitting next to them in person, in common, like, like there's no faster
way to gain someone's trust than just like going to lunch with them a few
times and like, at least if you're confident, if you, if you portray
some confidence, right?
If you're, if you're saying, I don't know how this is going and you're
always worried about it, maybe not so, but I've seen people succeed just
because they went into the office and that's where leadership was, right?
They were just in the same, even location, right?
Like if everyone was in a, in an office, but the person shipping a product was
in a different building, they didn't gain the trust because they weren't
seen by leadership constantly.
And they're like, I don't know what they're doing because I haven't
talked to them for four days versus you pass them in the hallway.
Hey, how's this going?
Oh, it's going great.
We're going to ship it next week, right?
Like that sort of confidence building and trust.
I don't like it, but I know that humans in general are, are that way.
And it's just having that constant sort of like interaction with people,
like the small casual things gains a lot of trust really fast.
I think it's possible to do remotely too, though.
I, I think it's possible to do remotely, but to, to, to some extent,
that could just be code because I've been remote for like eight years
and my whole time at GitHub has been, has been remote.
And I like to think I've built some trust.
I think being a personable person and having people's skills
can assist in gaining that, but you have to be good at like, like finding
a way to like have water cooler talk, not at the water cooler.
I think if everyone's remote, it's possible and everyone can be on the same
footing. I think if you're hybrid or your leadership is in an office
and you're remote, it's, you're not going to gain the same amount of trust.
You're not going to get that.
You can build trust over time.
It's going to be harder than if you were showing up into an office.
Look, that's, that's true.
There are, there are all these like social human ways of building trust,
but I do think like the fundamental way of building trust is to like just
straightforwardly do the thing and, and, and demonstrate that you are worthy
of trust and that you can do things.
Like it's, it's a flywheel, right?
Like you have a little trust, you get put on a little project, you do a good job.
You get put on bigger projects.
And then at some point it's like, well, you know, this person did these last
things really well.
Like, yeah, we trust them to do a good job of this thing.
It's just this kind of like, so I think delivering results is how you build trust.
Yeah.
Where results is to be understood as your manager and their manager are happy
without the project one.
Yeah.
Yeah.
Making, making, making them aware of something that you did and how it went.
How do you, oh, that's another thing.
I think communication is not always sought as like, you have to be good at
giving people the information to know why things are happening and to show your
success, because you can be doing the best job ever.
But if you don't learn how to market yourself and to show up and to like
communicate that, that's very detrimental to your career.
Do you have any advice for managers though?
Because I do think that generally we all want to please our boss and have them
happy with us.
That's pretty much like overall, that's not rocket science.
But like, how do we help managers to give us that information of what is
important to leadership and to these projects and to the value that they need?
Yeah, that's a, that's a good question.
My main piece of advice is, is really simple.
It's just ask.
It's like, if you're an engineer, like in your one on one, be like, hey, what's
important to management right now?
And if your manager doesn't know, ask them to go and ask.
And I think I've, I'm sure these exist, but I have never worked in a place
where a manager couldn't go to their manager and say, hey, what are the top
priorities right now?
What are you most worried about?
That's always been a question that's like appropriate to ask.
And you can just kind of do that up the chain.
And then, you know, in your next one on one or just async later, just, just,
just here, oh yeah, I talked to the VP and, and, and they said, like, they're
worried about these, these three things.
So like, yeah, the main thing is just like, like it's, the stuff is not
covert at, at, at large organizations in my experience.
People don't like hide what they want.
Like they're trying to tell people what they want because they want it to happen.
You know, VP's are constantly sending emails and stuff.
It's just because these different levels communicate in different ways.
Like, uh, it can be hard for the information to get, to get through.
You know, you can read an email written by a VP and it just sounds
like corporate speak, just sounds like noise.
Um, but if you actually read it and pay, and pay attention to it, uh, there,
they will usually be telling you like what three things they care about and by
a mission, what things they don't care about.
I only have had two managers that ever told me something and then went behind
my back and, and told other people something else, uh, where it was like,
actually they were literally lying to my face to have me do something in that
it was not what they wanted.
Oh, look, there, there are so many dysfunctional situations out there.
I, I have nothing but sympathy and I have no advice for people in those
situations.
I feel for you.
I might, my advice is to, to get, get away from that manager as fast as possible.
Yeah.
I had so many snarky things in my head that I'm just not going to say.
It's fine.
It's a safe space.
It's just us three.
No one else is going to hear this.
Nice.
But Sean's, Sean's face was so good.
Like I was just like Sean has stories.
Yeah, I'm, uh, I'm limited in what I can say, but I can make, I can make
general statements pretty freely.
The last thing in your blog post that I want to talk about was, uh, this notion
of can we ship right now?
And I like that sort of like boiling it down of, of like, Hey, is, is this.
Good enough.
Is this something that we could just put out there?
Is this something that's cause, cause the longer you say no, the longer
you hold on to something, the, the harder it's going to be to get out the door later.
Uh, yeah.
And that's, that's certainly true from like a product perspective, but I even,
I even made that technically, like, can we, can we literally ship right now?
Are we, are we technically ready to ship right now is enough of the code in place
that we could push it, deploy or turn the feature flag on and ship?
Like what's, what's preventing us from doing that?
I think people, uh, when they run projects a lot, they sort of assumed that, um,
writing the code is the hard part and like getting it out is easy, but in fact,
writing the code is pretty easy and integrating everything and making sure it
works end to end and, and fixing the, the kind of communication layer,
edge cases and, and all of that stuff, that stuff in my experience is what's
really hard about projects.
So if you can front load that work as much as possible by like, you know,
like if you have to ship a new page with a bunch of stuff on it, if you can
like ship to staff only a version of the page that has no styling and is just
like a page, then like the more of that stuff you can do, the more you kind of
defray these, these are potential potential risks about not being able to ship
eventually.
And I've seen, I've seen projects fail where people were just like, they
assumed that they could, you know, push this certain thing to production.
So they had this big, long development branch that looked really good and worked
really good locally.
Then when they went to deploy it, it was like, oh, it actually works slightly
differently than this core assumption that you had about how things would work is
false. So you have to go and back to the drawing board on launch day and figure
out how to make this work.
Like.
And the thing that I, I really like about this is how it ties into the first
part that we talked about where shipping is when your leadership thinks it's
shipped, right?
And, and if you get pushed, that's not shipping.
And even if the code is ready, even if you say the code is complete today, I
have all the tests, I verify that this thing will work.
If your marketing team's not ready, if you don't have the blog post that
announces it, if you don't have training material or documentation or whatever
post launch activities ready to go, you're not ready to ship even if the code
is complete.
And so making sure that that stuff is done ahead of time so that it's not a,
hey, we pushed the button to get, you know, we get pushed.
Now it's on you to finish shipping.
It's like, no, no, no, you have to do that together.
That is something that has to be done together because leadership isn't seeing
the get push and they're not, they're seeing the post activities and you need
to make sure that those can happen.
Not necessarily at the same time, but in some cadence that's together.
So you can say, hey, this is done on, on this Friday because everyone always
should ship on a Friday.
And, and, and whenever that case may be, you say, now the leadership knows it's
out there because the blog post went live because when Disney Plus went live, it
was live for like six hours before the actual announcement went live.
And it's like, guess what?
It wasn't live for those six hours.
People found it's people were literally already watching shows on it.
We're like, no, no, no, it's not shipped yet.
This is not done because we haven't made the announcement.
Yeah, yeah, for sure, for sure.
And as an engineer, you're not always in control over that stuff.
Like you're not always the one pushing the button.
But yeah, you, you definitely have to be aware that like it's not going to be
over until that stuff is done.
And to the extent that like you're blocking that stuff for reasons that
might seem unimportant to you, they will become very important on launch day.
Yeah.
Oh, did you ever have, did you ever think that Amazon that didn't ship
because documentation wasn't ready?
I can't tell you how many.
I was definitely the junior engineer that was like, the code's done.
It's out there.
And they're like, go write the release for announcement.
I was like, damn it.
I don't want to do this.
I had lots of things that did not ship.
I have blogs that are still in like, that were still draft.
No, they were drafted.
I have blogs that had gone, been in review for like two years.
They'll never see the light of day.
They're dead now.
I mean, if you got out, but most of them just.
Sean, was there anything you learned from this blog post and other people's feedback?
I mean, this was, you wrote this last year, right, November 2024, right?
So it's, it's now July 2025.
There was a bunch of conversation about it.
People talked about it.
People probably said, oh, I disagree with this, or I think this is more important.
What, what did you learn?
Oh man, this is going to sound really egotistical.
But I think I just believe more strongly that I was right now than I did when I wrote it.
I've written a lot of blog posts where I got feedback and I, and I, and I felt, yeah,
you're right, I missed that.
It happens a lot.
I write, I write a lot of stuff that I like go back on.
But certainly about like my own experience, I'm really confident on this stuff.
One thing I did learn, I guess was, and I sort of knew this in the abstract,
but it really brought home reading the feedback of like how different,
different situations are in tech and different jobs are in tech.
And so many people who wrote in the hack and use comments or emailed me being like,
hey, this part really speaks to me, but these other parts could not be less
relevant to me for these reasons.
And I'm like, yeah, fair enough.
Yeah, I think that's the jarring part about being an engineer.
It doesn't matter how long you've been an engineer from job to job.
It can be so drastically different.
Like, you know, just what the process is and everything.
Do you think that.
Do you, okay, so when you wrote this, it was what a year ago, like,
do you think that in the times that we're in right now, it's harder to figure
out what is the definition of ship because it's harder to figure out what
people are expecting of engineers right now and where engineering is going.
Like we've always said that you need to be really technical.
And now AI is writing a ton of the code, right?
So like, do you think we need to ask more often?
Like, do you think that there is like,
is it going to change what means shipped and do you think those priorities
are changing right now or?
Yeah, so let me, let me answer without reference to AI first.
Do I think it's gotten harder in the times we're in to like, figure out what's
shipped? No, actually, I think it's gotten easier.
I think in, in some circumstances, I think it's gotten a lot easier.
I think in the, in the mid 2010s, in the, in the height of like zero
interest rate madness, there were some projects where it was much easier to
there were some projects where it was like nobody knew what the point was.
It was, it was like purely like to be doing something or it was like
somebody had this idea and then left and then somebody else picked it up and
then left and then the third person was trying to carry it through without any
real sense. There were a lot of situations like that.
Or I think it was really genuinely hard for anybody to figure out what it
meant for something to be successful and what it meant for something to ship.
And for all that, it's like worse to be a dev now than it was then.
One thing that I do think is kind of nice is at least where I've worked.
It is pretty clear what companies care about because now it is like
more specifically tied to making money.
Whereas previously they had all these other motives that were because money
was money was free. So they were doing all these, all these, these are other
kind of things. Now it's like, well, you know, like if I make a change to
co-pilot and it increases ARR, that's a good thing.
You know, if I make a change to co-pilot and ARR creators, that's probably
a bad thing. Like it's, it's, it's much more like tightly connected in that way.
So we went from Vive projects and Vive teams and Vive services to Vive
coding, basically. Yeah, maybe.
You have to laugh or you cry.
Full stack vibes.
I don't think people are, people are Vive coding in big tech companies in, in
production yet. I think they're like, they're doing agentic coding and they're
doing all kinds of things, but the, the pure no code vibes, like just interact
with the, with the LLM. I don't think that's that widespread yet.
I think people think it is and they are basing whole models on it.
I guess we're going to see what happens.
Oh, the hype is there for sure.
Yeah. And I can, I can see, I mean, it's hard to distinguish those things, right?
When we say that AI is writing a lot of the code versus Vive coding, like people
oftentimes think it's the same thing.
They, they often like, oh, well you AI just wrote the code then, right?
It was like, well, like, no, like it's, it, it started writing the code just like
my tab complete used to start writing my code.
Or my, my Ruby on Rails generated an entire project structure when I had no idea
what it was doing and I just filled in some values, right?
Like those sorts of things have always been around.
And it's like, yeah, we are still hopefully in the loop of those.
It's like when we first start programming and people tell you, you have to only use
VIM and you can't use IDEs.
And now instead of IDEs, it's like, you have to learn how to program without AI
first and then you can use AI.
It's just another abstraction.
Are you saying I can stop using VIM?
No, I love VIM.
After you write, like, I feel like people just use it because like it's like
hazing, like you've already gone through like the, the hurt and pain of learning
it and then you can't unlearn it because, you know, you can go do something really
quick.
Muscle memory.
It's just, it's a sunk sunk cost fallacy.
I've invested so much time in these, uh, these key bindings that, uh, it's just
wondering if that's what it is with bash, right?
Like, is it because bash is really good for things because it's simple or it's
because we've all just been beaten to death and use it for it's because it's
good, it's, it's because it's good.
That's it.
I mean, one reason it's good now is that every LLM knows bash really, really
well.
So if you need, can we talk about that's, that's my favorite part of AI.
Like, because I hate writing bash so much.
Like, not that it can do all the things because it still gets it wrong sometimes,
but it'll get you like some of the way there and hope you diagnose some of it.
Like AI is taking away all the, all the artistic jobs, including writing bash
strips.
That's it.
But I just wanted to write bash scripts and regex.
If you need like a one-off script to be like this API is behaving weirdly, like,
can you hit all these endpoints with all this different stuff and like aggregate
the data, you can one-shot that with an LLM and that, that actually does save a
lot of time.
Yeah, I do like that.
Sean, where should people find you online?
Yeah.
So, um, Sean, get a key.com.
That's a G O E D E C K E.
It's my last name.
Um, or yes, fantastic.
Or you can find me on LinkedIn or just email me if you want to chat to me.
Are you on blue sky at all?
Uh, I am on blue sky, but I don't post anything.
Okay.
I, we have a, a, a running people, the guests of the show, uh, lists that we add
people to, so, but if you're not posting, then that's okay.
Sweet.
Well, thank you so much for coming on the show and talking to us all about how to
ship things.
This is, uh, this is fantastic.
Yeah, it's my pleasure.
Thanks for having me on.
Uh, everyone, thank you for listening to this episode.
Um, I, what is this episode coming out?
It's coming out in August.
Uh, I'm going to be at KCD San Francisco in September, early September.
So if you're listening to this before September, KCD San Francisco, I'll be
there and I'm also going to be at edge case in Amsterdam in September.
So, uh, if any listeners are around and, and want to meet up in person, please
hit me up on blue sky.
I'll, I'll be at those events.
Uh, autumn, are you going anywhere in the near future?
Um, it doesn't look like it.
Not right now.
That's fine.
It's, it's summer.
It's, it's time to not travel some places, but, uh,
I don't really want to travel right now.
I'm good.
I'm going to sit at home and garden and write code.
Yeah.
I, the less I need to get on a plane, the better, uh, but sometimes we're doing it.
So, yeah.
All right.
Well, thank you everyone for listening and we will talk to you again soon.
Thank you for listening to this episode of fork around and find out if you like this
show, please consider sharing it with a friend, a coworker, a family member, or
even an enemy.
However, we get the word out about this show, helps it to become sustainable for
the longterm.
If you want to sponsor this show, please go to FAFO.fm slash sponsor and reach
out to us there about what you're interested in sponsoring and how we can help.
We hope your system stay available and your pagers stay quiet.
We'll see you again next time.