Episode 10 Transcript

Episode 10 Transcript

Hey everybody and welcome back to the main thread.
I am Brian Ogilvie and I am here with Alex Geyser.
This is going to be our final episode of season one.
And so Alex and I thought that we ought to just spend the time revisiting some of the things that we learned from all our guests over the course of the season,
talking about growth areas that we want to be sure we focus on in our career going forward and we want to talk a little bit about what you can expect from next season when we come back after a break.
So let's let's jump right into it.
Alex.
Tell us a little bit about some of the themes that you remember that came up from our guests and let's just recap them,
but I will.
But first,
I want to say I never knew that we were going to make it to double digits,
Brian,
this is a red letter day.
This is double digits,
double digits.
I read someplace in a statistic that was clearly made up on the spot that 90% of podcasts do not make it past the third episode and 95 percent of podcasts don't make it past the 10th episode and we've made it to double digits.
We luckily buffered in our notes,
um two digits.
If once we get to 99 we're going to be in trouble.
But,
you know,
for now it's going to take a real feat of engineering to figure out how to accommodate that extra.
It's gonna,
it's gonna,
it's gonna throw our whole system out of whack,
But hopefully,
uh but we'll be able to handle it.
Um Yeah,
so I just wanted to talk about some of the things that we learned,
like some of the themes that we had over the um over the past 10 episodes,
10 episodes.
Sorry,
I'm just so excited about it.
The main thing is that we learned a lot.
Um It was kind of amazing.
We had a lot of different people with a lot of different backgrounds and a lot of different topics that they were discussing,
but they kind of came back to the same subjects in a number of cases,
you know,
a number of things that a lot of people hit on and to me that's independent confirmation that tells me that that's the sort of thing that's probably pretty important.
Something to pay attention to probably worth focusing,
probably worth focusing a little bit on.
So what I would have,
I think I want to point out a few of the things that like the main thing that everybody said that we talked to.
Um basically in every episode was that empathy and communication were some of the most important things as a staff engineer.
Um the higher up you go in the engineering ladder,
if you will the career ladder,
the more important those skills of empathy and communication become.
And that includes things like getting buy in from other teams being understanding,
being somebody,
somebody that other people want to work with.
That was something that was really a common,
a common theme from everybody that I talked to.
It's pretty shocking.
It's pretty shocking how often that came up.
Given the number of different topics we covered in different guests we had on,
we talked about security,
we talked about introducing new technologies,
we talked about vision strategy and every single person at some point brought up how important it is to approach the people you work with,
with empathy,
how important it is to listen and understand the space.
Pretty cool.
Pretty cool.
Yeah.
And uh Lee even included that as like the main subject of his uh I mean,
so you don't really get much more important than that.
And,
but even outside of that episode,
it was just a common theme.
If you listen back to all the episodes,
that's something that just about everybody says at one point or another.
So I thought that was really cool and it's not something that I necessarily expected to hear as often as I did.
So,
and I'm glad to hear it because I think empathy isn't very important.
It's empathy man.
It's,
it's,
it's great,
you know.
So then the next thing I say,
I would say that people mention the most is mentorship,
getting mentorship and also giving mentorship.
That was something that like 80% of the people that we talked to would um mention at one point or another that like a huge part of their career was finding a good mentor.
I remember in one of our first episodes we had Andrew pre on and he told a story about an engineer.
He once knew who wherever that engineer went in the company,
suddenly,
a lot of really skilled engineers cropped up around them.
And I thought that is,
that's a mentor,
that's someone who really knows how to build up the people around them.
And that's the kind of person that we all want to be as a staff engineer.
We want to be the person that makes everyone around us better not to spoil the next section.
But that's something that I certainly stuck with me.
And something that I've been thinking about a lot is,
is that certainly something to aspire to?
I almost maybe I should message Andrew Priest and asked him if he'll be my mentor.
I don't know.
Do you think he'd say?
Yes,
probably not.
He's a busy man.
He's awfully busy.
But the point is I thought that was also really cool.
Um but it wasn't just being so,
I mean,
obviously it makes sense if you are somebody who wants to do well,
learning from other people who are already doing well,
makes sense.
But one thing that also came up was being a mentor was really important that being somebody who,
like you said,
is leveling up everybody around them.
That's also something that was consistently brought up.
And I love mentorship.
I mean,
part of why I like doing this podcast so much as I just like talking about this stuff and I like talking about it to other people.
Hopefully,
whoever listens to this podcast has learned something and that's why we're doing it,
you know,
otherwise we'd just be doing it,
you know,
you know,
just the two of us or something,
we wouldn't record it.
The point is to like,
we want to provide at least in some measure mentorship through this podcast.
So I'm glad to hear that.
And then communication that dovetails with the other two,
like being able to communicate across teams becomes more and more important.
I think that one kind of speaks for itself,
right?
Like when you're trying to coordinate a lot of different teams,
your ability to communicate,
your ability to express empathy is uh more and more important.
I remember back to our episode with Brian Jones.
He had so many gold nuggets about really how to approach communication.
A couple of the things I remember he talked about one is just that you always want to tailor your communication to the audience that you're communicating with,
be really clear with yourself about what you need them to hear.
And that's how you tailor that message.
One of my favorite nuggets from that episode was he talked about if you're going to have a big meeting with a whole bunch of people that you need to buy in on something big that you're proposing.
A big vision,
a big strategy.
It's really helpful to spend one on one time with all of the people who are going to be in that meeting ahead of it to talk them through what you're working on them into the process of creating it so that their concerns have already been heard and folded into the proposal before you get in that big room.
And that way everyone feels like they're a part of what you are proposing.
And it also limits the chance that you get surprised by some concern that you never saw coming.
Yeah,
there is a number of times through the different people that we talked to where they made me feel very smart.
And uh and I realized that is an extremely important skill that was,
and I,
I was reflecting on that later and I was like,
that's a person I want to work with,
you know,
that and that's the sort of person who I think is very effective in that,
in that role is you,
they make other people feel like they're contributing,
that they're doing that they're doing good.
That's leadership in a lot of places.
So that's something that came up as well.
And then I think the thing that I,
that was kind of the most enlightening for me that maybe the most surprising was how important it is to pick your projects and how to pick projects and how to pick projects that have the most impact.
Because when you're working as a senior and a staff engineer,
um you will have projects to pick from and how you scope the projects is something that you'll have control over.
And so on one hand,
that can,
that can be something that like,
you know,
that opens a lot of doors for you and a lot of opportunities for you to for what you work on.
But on the other hand,
it can mean that you can pick the wrong problems and we've all probably had the experience of spending a lot of time working on a problem that nobody but us wanted solved and being able to notice that and having the um the humility to say,
you know,
what the thing that I thought was the most important was not the most important thing.
And I'm going to work on this thing that either the metrics or the people or whoever or whatever criteria um will hopefully nail that down in a future area episode exactly what the criteria is for that because it's pretty complicated.
Whatever that criteria was is how I choose my project,
not my own ego or what I want to do.
Yeah.
You know,
the companies that we all work for,
they're not paying us to work on stuff that we find.
Cool or interesting.
They're paying us to find ways to do the thing that is what the company exists for.
Right.
And the thing that bugs me a lot of,
I mean,
I'm,
I'm certainly guilty of this again.
Uh,
we can,
we'll talk about this a bit later but sometimes the thing that bugs me,
the thing that costs me a lot of time is not something that costs a lot of other people.
A lot of time.
Sometimes it's just something that bugs me.
I don't like it.
It is,
is something that,
you know,
I think will be a massive improvement to everybody's life if they,
if it gets solved.
But then,
you know,
I've done this a number of times I'll just conduct a meeting basically where we all talk about the things that are the most,
our biggest things about slowing us down.
The most things that are like,
just like ruining our days the most often.
And I've had to eat some humble pie from time to time because the thing that I,
that bugs me the most,
the thing that I think is gonna make my life so much better when,
if it gets solved bottom of the list and then we don't do it.
And then I say,
ok,
great.
I didn't spend all that time solving a problem.
Only for me.
Now we're spending all this time solving a problem for everybody else on the team.
And then when that problem gets solved,
suddenly it's 10 people who are happy instead of just one person,
you know.
Yeah,
for sure.
You know,
one thing that we didn't spend much time talking about it that I can recall in any of our episodes.
But I,
I find that it's been really great because we've been implementing it throughout my organization recently.
Over the last like 12 to 18 months,
we've started using the or format which stands for objectives,
key results.
So the company itself has their objectives.
They are big overarching things that they want to accomplish as a company and they will name a number of key results that roll into those objectives,
right?
They're like ways that you can actually measure whether you are achieving your objectives or not.
And as you traverse down the company structure,
people will glom onto those key results and they become their objectives lower down,
right?
So my objective is to move this key result and I have my own key results that will measure whether or not I'm doing that and that goes down and down.
And the great thing about it is it helps you stay aligned with the company's priorities,
but it's not so prescriptive that you are living in a waterfall world,
right?
It doesn't say necessarily what to build or how to go about accomplishing the key results that ends up being up to the individual teams to decide how they want to approach these priorities and how they want to try to provide value for the company.
So I really have enjoyed that framework because it straddles so well,
the need to align your priorities with the company's priorities while also teams needing the autonomy to focus on what they are good at,
to provide value,
right?
Having a guiding star,
you know,
it doesn't matter what route you take.
But you know,
that that's the goal,
right?
I think that's we use,
we use that format as well.
Uh And then I think the last thing and it's something that I have emphasized a number of times,
I think it's extremely important.
Um But most,
if not all of our guests put quite a heavy emphasis on it was trust.
Um And how none of this works,
if you don't trust your colleagues either,
trust them to do what they say they're going to do,
trust them to be acting in good faith.
Um And then they have to trust you on those same fronts and then trust in terms of just we're all working towards the same goals when I defend a project.
It's because I think it's the best outcome for everybody.
Not because I have some other selfish motive,
you know,
trusting people,
trust is extremely important.
It's kind of like the,
the lubrication that makes all of this other stuff work.
There's another thing that rolls up very importantly into building and maintaining trust and that is that you own your mistakes.
This came up pretty specifically in our episode with Lee mckeeman that was focused on empathy,
but it came up a number of times in other episodes too,
that the more senior you get,
the more important it is that you face your mistakes,
head on,
talk about them in the open,
learn from them,
apologize if necessary,
but most importantly,
don't pretend they didn't happen.
You,
you need to say this is what happened.
These are the mistakes that were made.
These are the processes that were not in place or things that need to be in place.
This is what we're going to learn to prevent this type of thing from happening in the future.
And I think that maturity to be able to own,
not just your successes,
but also your mistakes and build them into the career and the trust that you're building within your company and your organization,
within the community at large,
hugely important as you grow.
That's right.
And then also as part of that the organization needs to have built the trust with you that you will not be punished for owning your mistakes because it can be hard to put yourself out there.
And say this outage was my fault and here's how we will fix it.
If the company is going to say,
oh,
it's your fault.
Goodbye.
You know,
um you know,
that doesn't help you build a culture of ownership.
No,
it doesn't.
Like I said,
at some level,
trust is involved.
You know,
so you build trust by owning your mistakes by,
you know,
taking responsibility for things being delivered on time or communicating if they're going to be late and why?
And then if there's a big problem owning it,
like you said,
and then the organization obviously needs to,
well,
all the,
all the outside actors,
it's not just the organizations,
all of the other outside actors need to be doing their own part to build trust if that makes sense.
Hopefully it does said trust about 100 times.
No.
But I think that was a really nice re exploration of the things that tended to come up again and again,
as we talked to people who are very high up and far along in their careers in software engineering.
So given all of that,
that we've learned and discussed over the course of the season,
I'd like to share with our listeners a little bit about what we feel our own,
most needed areas of growth are as we progress in our own careers.
Do you want to start?
Oh,
you start,
Brian.
I just talked to,
I just talked for the past 16 minutes.
Straight.
So I'll let you have the floor.
All right.
One of the things that,
again,
it came up again and again that as a staff engineer,
what you own is the problem.
Not any particular solution to that problem.
Right.
You're responsible for getting the problem solved.
And one of the things I've noticed about myself recently,
especially as we've been in all these conversations is that I tend to jump to solution very quickly.
Just given the fact that I love technology,
I kind of like I immediately go to,
oh,
that's the problem.
Great.
Well,
I could solve it with this or I wonder what my data model would look like or I wonder what kind of api si could build.
I wonder how we would structure that my mind goes there right away.
And I think going forward,
it would really be beneficial for me to have a little bit more slow deliberate approach to understanding the problem and not just the problem itself,
but how that problem relates to other potential problems that we could be solving,
right.
So why is this a problem?
What's the actual impact?
Is it a big enough problem for us to focus on?
Is it a big enough problem for us to focus on right now?
Versus all of the other things that we could be doing and taking that analysis of the problem space and then communicating effectively my thought process and the shared collective thought process of the people I've talked to and scoping out this problem.
I think,
analyzing and owning the problem using data and also then communicating our understanding of the problem upwards and outwards through the company.
I think that is what I want to focus on primarily in my next several months.
Or,
I don't know,
even years of my career.
I think that's something that I could be a lot better at now.
Ok.
Well,
I wish that I had gone first now because that's my first thing was solving the right problem.
That's what I have written down here in my notes is solving the right problem.
It's one of the things like I said earlier is like,
that's something that really was impressed upon me that like at least half,
maybe more is like picking the right problem to solve and framing it in a way that is like,
actually going to solve the problem that's helpful for everybody picking problems that solve that.
Like,
again,
are force multipliers that are actual impact.
A lot of people because there's always more problems to solve than anybody will ever be able to get to.
So then it becomes a question of which problems do you solve?
And how do you scope them and all of that?
And,
you know,
that's something that I feel like I haven't done a good job of,
you know,
like I mentioned earlier,
sometimes I want to solve a problem that just because it bugs me and as we've been doing these talks,
as I've gotten more senior,
I've just,
I've done a lot more introspection about,
am I solving problems that are going to be having the most impact and how do I find those problems?
Right.
I think that's the other thing that I need to get a lot better at is finding the problems that are bugging everybody else.
You know,
we had one person I forget who it was.
So I apologize if you're listening to this episode because I'm gonna steal your quote.
He said,
find another staff engineer or find another person who you work with and ask them what the biggest,
most annoying thing that they have to deal with.
The thing that's bugging them,
but they don't have time to fix and go fix it,
that sort of thing.
But for the whole organization at that level,
that is something that I would like to spend more time doing,
you know,
getting better at that.
Absolutely.
Absolutely.
Do you have any more?
Because I got more,
I got lots of stuff to work on.
No,
go,
go for,
go for number BBB.
Number A.
Well,
first we've got number A and then we've got letter one and then we've got alpha numeric character dash.
And then,
um,
anyway,
that was a funny joke.
Come on,
Brian.
Give me a little bit of a,
I was,
I was,
I literally get distracted weighing whether I was going to cut this whole interaction out or not.
Leave it on the cutting room floor.
Yeah.
So let's,
let's hear the second one on your list.
The second one on my list is leveling up the people around me.
That's something that I really want to focus on.
I'm so glad you brought that up because I,
you mentioned it a bit about being a force multiplier.
And I want to know like,
how do you want to approach that?
That's what I need to learn,
Brian.
I need to re listens to our episodes and which everybody should do.
By the way,
if you're listening to this,
you should go back and listen to all of our episodes again and um subscribe and uh and like,
and give us a four star rating,
five star rating,
uh whatever your conscience dictates four or five,
nothing lower anyway.
So what do I,
what does that mean to me that means,
you know,
making sure that,
you know,
like I said,
when solving the right problem going out and finding the problems that are bugging a lot of the different engineers around me and implementing processes that will help,
you know,
make their work more efficient.
Um And then making sure that I understand the systems that we're all working in as um as thoroughly as possible.
So then I can go in and teach other people um how they work and so they can solve,
you know,
help solve,
you know,
problems,
not for them,
but teach them how to solve these sorts of common,
common problems,
right?
Writing documentation and then setting a standard for if there is a problem that has been asked more than a certain number of times we write a document for it and then we start sending people to that document.
Um If there is something that we anticipate is going to be a problem in the future,
we don't just wait for it to become a problem.
We go,
we proactively put it on the sprint board.
These are all things that I've been trying to put into practice,
you know,
rec more and more recently,
one thing that I've done is um we have some noisy alerts.
So I put together a process for how we can tackle,
making sure that these alerts are accurate because uh an alert that's too noisy becomes a boy who cried wolf situation.
People start ignoring it and then suddenly you've got a real problem on your hands because people have become accustomed to just muting or ignoring that alert because it's too sensitive.
And the last 20 times,
the last 1000 times it went off,
it was for something completely inconsequential and it resolved itself,
right?
So putting a process in place so that,
you know,
creating a culture where people take responsibility for these things once they see them,
then also talking to management and seeing like,
hey,
this is important,
we need a budget time for this.
So hopefully,
our listeners can give me some advice about how to level people up,
but taking those sorts of actions like trying to put in place processes that help my colleagues work more efficiently.
But then also,
you know,
setting a high standard for how we do things,
you know,
in terms of like code reviews and in terms of like,
you know,
taking responsibility,
like we talked about taking ownership,
not just passing the buck on a problem that we find.
And then I think what becomes really important is being a domain expert,
you know,
being somebody who,
who can answer questions for a,
a large group of people and then can create a system so that anybody else who comes into this,
I was able to quickly learn from,
from that knowledge that's been gained.
Does that make sense?
Yeah.
No,
it was good.
And I think like for me on that front,
I love being a mentor.
I have taken part in our internal mentoring program and the company for the last couple of years and I love that.
But beyond mentoring like that,
I think also what it means to me to be a force multiplier is to create scope for the people around me.
So if I am taking on the right projects,
it's not just the projects where I'm gonna go do a great job.
It's also the projects where I might be working on some particularly hard thing and there's maybe other parts of the project that I would be quite good at if I had that to focus on.
But there's someone else on my team that really wants to focus on that because they haven't had a chance to work in that technology yet,
or they just want to learn a space better.
And if I cut that scope out for them,
like,
let's say this is a new grad who's an IC three who,
who hasn't had the chance to take on a whole feature and own it,
end to end to build it out.
That's important that I give them that scope and provide them the support and help them do that for their own career growth while I'm focusing on some other part of the problem rather than just saying,
oh,
I'm such a great engineer.
I'm going to do all this,
right.
It's about,
it's about creating the scope and the ability for others around me to grow their own careers.
So that all brings us around now that we know what our own personal focuses are going forward.
What do we want to do with the next season of the show?
What can listeners expect when we come back after our break?
I think obviously the,
the first answer to that is you can certainly expect us to be exploring the topics we just discussed around the things that we really want to focus on in our own growth.
We're going to find ways to discuss that.
Another thing that has come up as I have spoken to people who listen to the show,
we want to continue to expand the breadth of perspectives we get on the show.
We'd like to continue to find some more diverse voices.
For instance,
I ran into somebody at work the other day who listens to the show and,
and told me,
you know,
I'd love to come on and talk sometime and I said,
that'd be terrific.
I'd love to have you.
What sort of thing would you like to talk about?
And they said I'd love to talk about what it's like coming to work as a staff engineer from another country.
In this case,
they actually said from,
from several different continents that they've worked over the course of their career.
And I think that's amazing.
I think the whole perspective of conducting business at a very high technical level in a language that isn't your first and maybe not even be your second I think is a really amazing thing to explore.
I routinely think I'm the dumbest person in any room that I'm in at work because of the fact that everyone around me is conducting business in their second or third language.
And I don't know if I could do it at that level.
But I think that those kind of conversations I want to have,
I would love to get some very senior women on the show I'd love to get some very senior people where they've come to tech from very diverse backgrounds,
where they've come to this country from very different places.
So that's going to be a priority for us and choosing our guests going forward as well.
Just to increase the number of perspectives we have,
we want to cast as wide a net as possible for who we have on the show because nobody wants to listen to a show and we wouldn't want to be part of a show that just is pulling from the same groups of people.
Uh You know,
we want as many different perspectives as possible because again,
the whole point of the show is to have a growth mindset for putting on a show to like,
you know,
learn.
And if you limit the number of people you're going to talk to,
you're not really learning much.
Are you?
So the next things that we want to do in addition to like diversifying,
like our guest pool,
we also kind of want to diversify the types of topics that we tackle.
We want to talk about not just like high level topics,
but we want to really get into the,
the,
the nitty gritty,
like how some of these process things work.
We've heard a lot about like what is good and what is important.
But we haven't seen,
we haven't really had as much time devoted to how to do it.
Right.
So one thing that I think is really important is like,
how to conduct a good retrospective that builds trust,
how to do a postmortem that,
that,
that builds trust,
how to determine scope all of those things.
And,
and hopefully many more subjects would be things that would be nice to take a deep dive into.
Uh We're also,
hopefully we haven't picked a name yet.
Brian put a few out on linkedin,
but we don't have any anything concrete yet.
But we'd like to start a new sort of sub series of episodes dedicated to like how I did it right.
Like if there was a specific problem that you solved or a specific,
like,
you know,
it started out as kind of like when things all went wrong and how you,
you know,
fixed it.
But,
but we basically want to do some real case studies,
right?
Some deep dives into actual staff engineer projects.
What have people worked on?
How did they approach the problem?
What challenges did they meet along the way?
How did they get over them,
all of that kind of stuff?
We want to get some real deep stories about that.
And I think there is an absolute gold mine of those stories out there among the people that we all get to talk to.
So anybody who has been in this industry for more than a couple of months probably has some,
some story of some crazy thing that they've had to deal with.
Or some amazing problem that they're solved that they're really proud of.
And I just think that's the sort of thing that,
I mean,
I personally would,
I can listen to those stories all day and you learn a lot.
Sometimes the,
the speaker doesn't even really know what some of the learnings from that are until you really talk through.
Like,
why did you make that decision?
Why did,
what were the pros and cons for why you chose that technology to solve this problem?
What was the thought process?
Who did you need to talk to?
What went wrong?
What when you,
when you finally implemented it,
what were the,
what were the outcomes?
That's all stuff that we'd love to diversify our episode types to include.
So that's,
those are the,
those are the main changes we have up,
we'll be back soon,
stay tuned,
stay tuned.
And by the way,
listeners at the end of our episode,
you'll always hear all the ways in which you can get in touch with us.
We would love to hear from you if there are topics that we are missing or people that you think we should have on people who would make great guests.
We really want to hear from you about that.
So that this is useful to you as well as to us because we could,
we could just go on forever talking to people that we think are really cool that we want to learn from,
but we're sharing it for a reason.
Yeah.
Volunteer your friends,
neighbors,
family,
pets,
anybody,
we'll talk to them.
You've got a give out home phone numbers and,
and we'll call them up email addresses,
home phone numbers,
social security numbers,
any of that stuff.
We're,
we're happy to take it on.
Um,
you have,
you have an,
especially a dog who,
who's a staff,
who's been working as a staff engineer at a,
at a,
you know,
Fortune 500 company.
That's a story we'd love to hear.
You know,
if the dog can talk,
even if they're not even a staff engineer.
Well,
we'd love to have him on.
So,
really,
the sky is the limit.
Well,
guess what?
It is?
Time for our final picks and plugs of season one of the year,
final one of the year.
So we're going to make it count or maybe it'll just be all right.
Either way we'll be back with more of them next year.
But Alex,
I'm sure,
let's,
let's,
let's have you,
uh,
let's have you start it off.
Well,
it's not that amazing.
Um,
well,
it's a good talk.
It's by Dylan Beatty.
He's the same guy who did the art of code,
which I picked earlier.
Um,
I watched it this week.
It's a,
it's a pretty interesting deep dive into email,
the history of email.
It's called,
uh,
Email versus Capitalism or why we can't have nice things.
Uh,
it's another one of these NBC conferences that,
you know,
I've been kind of on a kick for NBC conferences that if you're not familiar,
just type in N DC conferences into youtube and you will get a wealth of interesting subjects and it basically just goes through the history of email,
why it is the way it is and then how I won't spoil it for you.
But how that's kind of changed as,
as the internet has evolved and how different actors have influenced how,
how email works.
So yeah,
that's a good pick.
At least I really enjoyed it.
I think that's the only one I have.
Honestly,
that's a good one.
I'm actually,
I have to work my way back through some of the previous episodes to make my way through all the videos that Alex has recommended because I think there's,
there's some really good ones in there.
The ones that I've gotten to,
I've liked a lot.
So I'm excited to explore that.
Treasure trove.
So mine today is an article on Brave New Geek called Everything,
you know about Latency is wrong.
Now,
this article is actually kind of just a recap of a talk that was given at strange loop by Gil Teen,
but the talk itself is 45 minutes long.
So if you don't have the time to make it through the talk,
it's great.
But this article does a really nice job of boiling it down.
The idea is we tend to measure latency based on like,
oh,
well,
p 95 is this or P 90 is this.
And so we don't really need to worry about P 99.
But in reality,
the way that most applications are structured because of the number of requests and all of the complexity that goes into it.
A huge amount of your users are actually going to experience that 99th percentile of that weird outlier event that makes things run slowly.
They're actually going to experience it.
They did some research about this and for a ton of sites,
it's like more than 50% of your users experience P 99.
So we shouldn't treat it like.
It's rare even though it's,
even though it's the 99th percentile,
actually,
most people are going to experience it.
So that is not the noise,
it is the signal,
it is what you actually should be focused on and you should be optimizing for that.
How does your program,
how does your platform respond to those types of events?
Extremely long network latency or node outage or that kind of thing?
Really?
Great read.
And the talk is great too.
I recommend them both.
All right.
That sounds like that's,
that sounds like a great pick.
I'm going to read that.
I love that title.
I don't know if that's a reference to Fire Science Theater,
but Fire Sign Theater.
If anybody,
this is maybe the deepest cut that I have ever made.
Uh period.
But firesign theater,
if anybody knows about it is an old comedy troupe and they had an album that came out called Everything,
you know,
is Wrong.
And I hope in my heart of hearts that,
that's a reference to that.
So we're gonna have to reach out to the author and ask.
Yeah,
it's,
it's,
it's pretty funny stuff if you,
depending on how old,
I guess,
uh,
the author is,
I don't know if they're,
they were alive in the seventies.
They're probably familiar with Fire Science Theater.
So I just hope that that's what it is because that would be beautiful.
Anyway.
Well,
I'm gonna ask that guitar to play us out.
But listeners,
thanks so much for tuning in for our episodes.
Thanks so much for reaching out with,
with your ideas and we're looking forward to coming back for season two after a short break.
We'll,
we'll see you in 2024.
See you in 2024.
And what a wonderful 1st 10 episodes.
It's been Brian.
You need to put the air horns in as we close out the guitar and the air horns.
Ok.
All right.
Catch you next season.
Thanks for listening to the main thread.
As always the views expressed by the hosts and guests of the main thread are our own and do not reflect those of our respective places of employment.
Are you enjoying the podcast?
Do you have a topic you'd like to hear discussed in a future episode.
Well,
please reach out to us with any suggestions or feedback.
We are at the main thread on all major social media platforms including Facebook,
Twitter,
Instagram,
and of course threads.
If you prefer,
you can send us an email at main thread podcast at gmail.com.
For links to resources mentioned in today's episode or to download a transcript of the podcast.
Please refer to our show notes that's all for today's episode.
Thanks again for listening and we'll catch you next time on the main thread.