Episode 03 Transcript

Episode 3

Welcome back to the main thread.
Today's episode is a tasty one. At work
I attend a leadership circle organized by some of the more senior managers and engineers in my org where they coach us aspiring Staff+ engineers on cultivating the behaviors needed to reach that level.
In one of our first sessions,
today's guest introduced me to an analogy that illustrates beautifully the progressively growing scope and responsibilities of an engineer from junior to senior to staff and beyond.
I love this analogy so much that he and I decided to explore how it could be expanded to apply to the tech community at large beyond the specifics of our company,
and I'm really excited by the results.
So get out your aprons,
prep your mixers, and welcome our guest,
Andrew Preece as we whip up "The Cake Analogy."
Welcome back to The Main Thread,
everybody!
I'm your host,
Brian Ogilvie along with my co-host Alex Gaiser.
And we are joined today by Andrew Preece: production engineering manager at Meta. Andrew,
do you want to take a minute to tell us who you are, a little bit about your background,
and what brought you to where you are today?
Sure,
thanks,
Brian.
Um So,
yeah,
my name is Andrew Preece.
I'm a production engineering manager at Meta.
I've been at the company for like nine years and this is kind of the only real tech job I've ever had.
Um Before this,
I worked on a lot of telcom stuff,
a lot of like backend unix,
um optical transport for people who like,
like the,
the backbone of the internet.
Um And so I used to work on support for those tools.
I liked automation a lot more than my coworkers did.
And so I learned how to program and how to hack on things.
And that eventually is the thing that made me a production engineer is a,
a heavy focus on automation and being really,
really close to the,
to the metal,
like dealing with the kernel operating systems,
how you ship that stuff.
Um at meta when it used to be called Facebook,
I worked on a,
I've worked on a ton of teams.
I'm not gonna go into them all,
but I started as an IC and I made it to a reasonably senior IC before I had to decide,
do I want to be a manager or do I want to be a more senior IC personally?
For me?
Um At the time,
I felt like I was an average engineer at Meta even though I could,
you know,
make it at a lot of places.
Um But I was maybe an above average people person.
And so when I was looking at my career in the future,
I'm like,
well,
like,
yes,
I'm a solid engineer,
but I might be able to have more impact um as a people manager because they were like a little bit more rare and finding people managers who are really technical um is something I feel,
I feel like my managers should be like that,
especially at tech companies.
I don't know if I would say that anywhere else.
I don't know.
Um But uh it's something that I care a lot about and it's like this is my ability to like,
keep that at the company and take accountability and like be the change or the continuing in culture that I want to see and saying stuff like that is probably why I'm still a manager.
That's um one of the things that I,
you know,
not to plug our own company all that much.
But like I,
that's one of the things I really love about working here is that Meta does expect their people managers to be very technical,
which isn't the case everywhere.
And,
and I really appreciate that,
that they,
they do have an understanding of the work that the engineers are doing and why it's technically complex,
et cetera.
So Andrew,
I wanted you to be on the podcast because at Meta,
you're a participant in this leadership circle that,
that I attend uh helping ICs grow to the staff levels that we talk about on the show.
And you shared with me uh with the group not that long ago,
an analogy that I thought was really illustrative and helpful in terms of understanding how the scope of the work and the expectations change as you move up the ladder in engineering levels.
And I uh wanted to have you on the show because I thought our listeners would really benefit from hearing that as well.
So uh I'm gonna kick it over you and have you introduce "The Cake Analogy."
Yeah.
So this is an analogy that's designed to kind of scale as engineering levels scale.
This is I think somewhat like large tech company centric in terms of the way it's mapped out.
But I think that it's portable enough to other people's careers because the things that you need to do,
even if like the level doesn't match up the skills and the behaviors are like really there.
And when I think about the superstar engineers that like,
I look up to and that I can be really successful over time,
even not at Meta,
it's the same set of behaviors and ways of solving problems that I think have like really contributed to them to being successful.
This,
these aren't like the only ways,
but I think it's a really great way to break it down.
So rolling into it:
It's your first day on the job and you're a junior engineer,
except you're not an engineer,
you're a baker.
And so your boss comes up to you.
He says,
bake me a cake,
he gives you the recipe.
He's like,
like here's the frosting,
here's the tool,
here's the oven.
This is the mixer.
It's not like the British Bakeoff technical challenge where there's like three lines on the recipe.
It's like a real recipe that you get out of a book,
um or maybe the back of a box.
And so everything is really well defined.
It's really,
really easy for you.
And so you don't have to have a lot of advanced skills to do this.
Like you probably have to be like slightly familiar with
Like how do I turn on an oven?
But you,
you get a lot of things given to you. From there,
you kind of move into a slightly more independent person and you've got a new boss and she comes up to you and she's like,
hey,
um I need you to bake me a vanilla cake and she like goes on her way,
maybe she's like,
you know what this is...
here's a,
here's a piece of paper that says what vanilla is,
but it's like it's still flour and still sugar.
You're gonna bake it for like the same amount of time.
And so like things have changed because you're expected to know some things,
but not everything is like really handed to you.
And again,
at some companies like at Meta,
this is like a different engineering level. At other companies,
This is just your career progression and this is just how you learn to do a job.
So don't necessarily think that any of these steps have to be a promotion,
sometimes they're just like your growth in your career.
So now you're at your next uh now you're,
now you're at your next job and you,
you did good enough baking that cake uh that vanilla cake that you're getting a little bit more stuff to do.
And so now uh your new boss comes up to you and he's like,
oh this,
this guy is really good at baking cake.
Uh Andrew.
I need you to bake me a cake but uh no flour. And this is where it's like,
oh OK.
Um This is chemically different,
very chemically different than what I'm used to.
I mean,
and for anyone who's a baker chemistry is like really important,
right?
And so this is when you're kind of like an adult in the engineering career is you now have to figure a bunch of stuff out for yourself.
This is where it also becomes really important.
Like what questions you ask?
Like you could be like,
where is the gluten free flour?
And that's like probably a good question to ask if you or what does it mean to make cake without flour?
Can it have the word flour in it?
Right?
But again,
your questions and your putting of the requirements becomes super duper important.
Is this because of allergies?
Is this a preference?
Are there other allergies we should know about?
Um,
and like this is kind of the first time when what you knew before is probably really useful,
but it's not exactly what you need to fulfill the job that you're trying to do.
And so you're kind of always learning new things and you're probably always doing things for the first time.
Someone once told me,
is that a career looks like,
uh,
a bunch of people who could do something are doing something else,
that's something they've been doing for the first time.
And that gives you the opportunity to do something that you're doing for the first time.
Right?
And that's,
uh,
this is where you really start to see that kind of moving on.
Um,
you've done really,
really well and you've shown that you're really,
really great at baking cakes that have various dietary requirements and you're an expert with the oven and now you're,
you've got a new boss and,
and she comes up to you and she's like,
make me a dessert,
and you know,
walks off.
Right.
And well,
now you have a completely different set of options available to you,
right?
Like maybe it doesn't have to be a cake,
right?
Maybe,
maybe it can be like the really basic cake.
How big does the cake need to be?
You know,
maybe it's it's a,
a éclaire,
right?
Maybe it's not even baked and so maybe it's a combination of things.
Right.
Maybe it's like a cake that's cake on the bottom and ice cream on the top.
Who knows?
Right.
And that's,
this is where you have like a lot of rope.
Right?
And that rope is what makes the job really interesting is,
uh hopefully for bakers as well.
But where now you really get to frame your relationship with the problem and the solution.
I mean,
a lot of times we like to say there's like no right or wrong answers,
but there's a reasonably narrow set of correct answers and,
and this is one of the times where it's like the set of correct answers is actually very broad.
Um,
and sure there are some really wrong answers,
right?
Like I made a roast.
Um,
probably not what the people were looking for,
but,
um,
uses your oven skills.
So props for that.
But again,
like your relationship with the problem is,
is,
is more important than the solution to the problem and how you solve it and,
and how you figure that out.
Right?
And,
and maybe it's a time when it's safe to experiment.
And so you're like,
you know what I'm gonna try and make a meringue, and I've never done that before or maybe you're like,
this is really high stakes.
And so I'm gonna go back to the basics and I know this is a bakery that has an oven and a a lot of flour and so chocolate cake
it is!
right?
And then like,
you've now become very,
very successful at making arbitrary desserts that may or may not include roast beef,
depending on how your sales skills are.
And you kind of like get to the last point which is now uh your,
your boss comes up to you and,
and she's like we need a dessert for an entire convention,
right?
And so the problem is,
I mean,
the problem has been getting like somewhat fundamentally different as things have gone up.
But like this is now ridiculous because the types of questions you have to ask are like,
well,
how many people are at the convention?
Do they have dietary requirements?
How many different desserts do we need?
Um And you probably come up with like an a litany of other questions and it's important to ask those questions.
But at this point,
it's also important not to be asking questions like,
where's the chocolate?
Right?
Uh Or like,
how do I turn the oven on?
Um But,
you know,
and again,
like maybe this kind of comes down to it is like,
you're also expected to make sure that like you have requested the equipment that you know how to use and you've,
you've got an oven that either you read the manual before you showed up and you feel pretty good about it,
but it's not like the first time you've seen it.
Right.
Like your first time switching to induction cooking is pro... this is probably not a good time.
Right?
Unless it's a really small scope, you want,
you want to save that for your home baking project,
So you have that really nicely figured out.
Also,
I don't know if an induction oven exists that uh,
hopefully we don't get any corrections.
Right.
But yeah,
so you can see that like as you move through it,
the type of dessert that you come out with is it sort of matters,
but it matters very much less because it wasn't necessarily an obvious requirement.
Um And you had to like dig into it and figure it out,
right?
And that's like as you step through these layers,
things become really ambiguous and you have to kind of grow and shift with them.
And I think the other thing that's like really interesting about this is the skills are like different,
like we turned this into like a baker one.
There have been other ones,
there's like uh the,
the uh fire one at Meta.
But again,
like the patterns are everywhere from like chefs to plumbers.
If you think about people like going through the trades,
like the first time you go and you start doing plumbing,
um you don't do a gas line,
right?
And you probably also,
you know,
you,
you start like safer and you start easier and maybe you start with like PVC instead of like steel,
right?
Maybe you don't get to work on the water main until you've been doing it for a little bit.
Although,
I don't know,
maybe there are some plumbers there who are gonna be like,
"You are wrong! My first day.
Um,
water mains all the way."
Yeah.
And so that's the,
that's the analogy.
Yeah.
II,
I feel,
uh,
I feel not super comfortable making analogies to industries that I don't understand.
But uh but I think the the truth of that really holds, right?
Like the idea is you do have to develop very basic skills,
especially early on in your career.
There are requirements that you simply can't move ahead without, right?
You've got to, as an engineer,
be able to ship code,
you've got to be able to make sure that it's of high quality that it's well tested.
Those are kind of like those skills that you learn in your first couple of years on the job that are just essential.
You can't become a senior engineer without that stuff, without that background.
But what I love about this analogy is that as the chef moves from chef's apprentice to a baker is how gradually they start to own the problem rather than owning the assignment.
And I think this is something that that is really key to understanding the difference between a junior engineer and a staff engineer is that when you're a junior,
you own your task,
you own the deliverable.
Right.
That is what you own.
Someone has asked you to give them a thing and you do that thing and if you're good at your job,
then you deliver it, and it's great.
But as you get along right,
as the chef,
as the chef grows in their skills and,
and as their bosses trust them with more and more uh authority or more and more responsibility, they have to own,
not just delivering something,
but actually there is a problem that needs solving.
We have 200 people who need dessert, and the solution you come up with needs to address that problem.
And you really can't look around and say,
well,
I did what I was told to do.
So if it's not the right thing,
that's not my problem.
It is your problem.
Now you,
you are the one deciding what is to be done.
What's the solution?
I own the problem,
And if I come up with one solution, and it turns out that maybe it's not the right thing,
you need to be able to pivot and find a different solution and get that through,
right?
Because the the deal is you still have to solve the problem.
It's on you.
And that's like you totally hit on one of the really common pitfalls.
Um And I see this a lot,
especially as people are like,
working towards that,
I own a problem versus owning an assignment is having to get to the point where you're focused on the goal,
not necessarily the solution or the implementation.
And so it's very well and good to be like I wrote 600,000 unit tests when your goal was to make sure that your app wasn't insta-crashing in Prod.
And it turns out that your app is still insta-crashing in Prod because maybe you're testing the wrong stuff,
right?
And there's like a,
a poster I really like,
that's like,
"Don't mistake motion for progress."
And I think that becomes really,
really,
really important is to make sure your motion is progress.
And sometimes you gotta take a little bit of a leap of faith and I get that,
but you want to like double check your work and like get signal on that like reasonably quickly.
Another a good example of that is there's a talk on youtube called unit testing where it all went wrong.
Um It's pretty,
it's pretty interesting.
It's not anti unit testing.
It's about by a guy who's very pro unit testing,
but he talks a lot about how unit testing,
if you just follow again for the sake of motion,
getting 100% coverage,
getting coverage in all these different ways it becomes for its own sake rather than like having the goal of how is our co code maintainable,
how is our code alive,
you know,
in production and how do we catch problems before they reach production?
Then it becomes the code becomes extremely fragile because even small changes,
break the unit tests,
which means that you have to maintain 2 to 3 sources of truth rather than one or two.
Not to say that there's not a role unit testing.
But that if you are unit testing in such a way that you are losing sight of the goal of making your code maintainable and making your code less brittle if you do things like testing,
I mean,
the example that you use a lot of is testing implementation details rather than testing API services for the tests,
right?
So then when you would change the implementation detail inside of them,
rather than a like a private method inside the class or something like that,
that would result in a lot of unit test breaking when ultimately,
you don't actually care about what that internal method does. That dovetails was something I wanted to ask you as you were talking.
And I think it's the core problem with going from the senior to the staff level is just like we were talking about with the cake analogy like junior mid senior level.
All of those seem like it's a fairly linear progression.
You know,
you learn how to,
you learn how to read a recipe,
you learn how to work without the recipe,
you learn how to find the recipe,
you know,
or and so forth.
But then once you go onto the catering example,
it feels in a lot of ways like a clean break in terms of the skill set that you need and that may or may not be true.
And that's certainly the way it can feel as somebody like myself who's on that journey.
And my question to you is how do you take the skills that I need to learn in order to be an effective senior engineer and then translate them into something that will maybe be an effective staff engineer without doing double work.
Yeah,
absolutely.
I think this is like a really common thing that people run into and I,
I've been trying to think of a different way to say this,
but I've never really gotten there,
but it's becomes,
as you become more senior,
it becomes important to work smarter.
And I don't want to imply that... The problem is with this is that it implies that like people are working stupid and that's not what what the implication is meant to be,
but that you have to understand like how to scale yourself and you have like kind of a different set of concerns.
And I think one of the big differences that I see people overcoming to stop being in the duplicate work thing is focusing on like the really meaningful work.
And so no,
you don't necessarily write tons of boilerplate code,
but you like take and you write the code for like the hardest part of the problem,
right?
Where it's like you are the key individual and if you don't do that,
it won't get done and it's understanding how to,
like,
use the team around you.
And then I think you also have to get like,
really,
really creative,
right?
Which is again,
like if you're trying to do all of the implementation and the business work and the et cetera,
et cetera,
et cetera,
like maybe you're one person that has a startup and that's like,
cool.
Um,
because you have like all the equity but you're gonna like,
you're gonna burn yourself out.
And that's like you see one of the common pitfalls I,
again,
I see with people moving towards a more senior engineer is they'll get like a piece of advice from a really senior person that's like you need to work on something that has like a company-wide visibility and how they interpret that is like,
I am going to take a second job at the company,
I'm going to start working on that thing.
I'm gonna find out like what the CEO's pet project is and I'm gonna,
I'm gonna do that in my spare time.
Right?
And that's like,
that is a way.
Absolutely.
Is that the way I would do?
Hopefully not,
maybe,
but the one of the other ways to do that right is make sure that the thing you're working on has that type of business value and has that type of leverage,
right?
And so as you become a more senior engineer,
there's a bunch of like extra stuff that you have to care about,
that's like interpersonal stuff you're caring about like business value,
you're caring about like funding and leadership culture,
right?
And it's like if you want to have free time to work on planning like the the the whole dessert bar and everything,
if you want to have the time to work on these like really,
really high level problems,
you need to be with other people who can work on the other problems.
Right?
Then maybe some of them are high level,
maybe some of them are low level,
but it's up to you to,
to chop that work up and spread it around and then that ends up being like other things.
It's like really great senior engineers that I know um who are like getting,
who aren't like coding machines and aren't just like,
I can code an amazing amount,
which is like a totally valid way to go.
Um But I think we're talking more about like the soft skills.
So that's what I'm focusing on,
right?
Is they have this ability to like,
inspire other people.
Um,
an engineer that I super duper look up to,
he would go into a space where like nobody existed or there was like a team that was like doing ok or pretty well.
So he'd go into places where there were teams that were doing terribly too,
but even like an ok team when he went in there,
really skilled engineers,
started just appearing around him and whether that was from him
teaching other people or him helping hire and all those kinds of things,
he was like getting the things he,
he needed to like,
make the solution that he wanted and like,
buy himself the bandwidth to like,
focus on like those really hard things.
And,
and I think you also have to be a little bit of a chameleon,
which is like today,
I'm going to work on like business powerpoint presentations and that's really great.
Or I'm gonna talk my manager into doing it for me because he's a cool guy or,
you know,
it's like now I am,
you know,
elbow deep in the Linux kernel trying to figure out like why my neck,
why my NIC is resetting all the time.
Yeah,
I think you're right,
like you do have to really be a,
a jack of many skills or at least be reasonably comfortable in a lot of different types of things because not only, you're not necessarily always going to be doing the most difficult work on every aspect of the problem you're trying to solve,
but you probably do need to be able to speak intelligently with the person who is doing it.
And there's another thing that I think one of the reasons I love the the cake analogy is that in that final stage where you're catering now,
your job as the person being tasked to solve that problem is not just to get it done,
but it's also to win the resources necessary to get it done.
And I think that is a hugely important part of being a staff engineer is,
is saying,
you know,
here is the problem we're looking to solve.
And I think this is a strategy that will work.
But in order to accomplish that,
I'm gonna need commitments from this team and that team and I might need one or two other junior engineers,
that kind of thing that you have to be able to reasonably go to say your director maybe and say this is what I feel it's gonna take.
And do we have that sort of commitment from the Org and,
and sometimes the answer might be no,
we don't,
we don't have that kind of resources to throw around on this and then you,
then it's your job to come back and say,
ok,
then I think we can accomplish this other thing and it's going to address maybe 80 to 90% of the problem,
but not that last 10%.
Are we ok with that?
Two extra things:
One,
sometimes you have done the work to prove that it's not important to the company.
And that's like,
ok,
you can,
you can take that to the bank. And the for sure the trick is you gotta figure out the thing that is important to the company and that's I,
that's where,
like,
the rubber kind of hits the road,
right?
Is if you're like,
this wasn't important,
I'm gonna do something else.
If you never find something important,
that's probably like a bad sign for your career.
Um But the second thing is we talk about a lot of the ways we've been talking about this are like,
what you do and how you do it and how you influence.
But again,
the interpersonal stuff becomes so much more important because like,
maybe you're not really great at oral presentations.
And so you need to like play to your strength of like writing.
And when there's a presentation that needs to be done,
you find like a good way to like maybe your colleague does it or you know,
you do it under the guise of like letting someone else uh get some of the glory,
right?
But like folks on your strength,
but again,
you're not doing it on your own,
right?
You need to,
you need to leverage the people around you and that's like all the way up and all the way down.
And I think you talked about like,
like leveraging those people and stuff like that.
But sometimes it's also about like convincing someone else to convince those people to do things,
right?
Like you end up like throwing a rock to hit another rock to actually miss the window,
right?
And again,
like,
I think people do it alone sometimes and you gotta understand that you are accountable for getting it done.
But that doesn't mean you have to do yourself.
I know a housewife she gave me this wonderful piece of life advice a really long time ago,
which is you are responsible for your s--t getting handled.
That doesn't mean you're responsible for handling it all yourself.
Right.
Right.
Yeah,
for sure.
You know,
one of the things you brought up earlier and I just wanna highlight it again is when you are really good at something from having worked up through it.
A lot of times there's a problem or a part of the problem that's gonna be super easy for you.
There's some other engineer who is growing in their career who would actually love the chance to bite that challenge off.
Right.
And,
and,
and part of your job as a senior engineer is to create that scope for the others around you.
Right.
It's not just to like share the glory.
I don't even really think it's a guise,
it's that these complex problems are going to take more than one person's work.
So it is part of the job,
I think at that level to say I have an engineer who is really dying to work on,
I don't know, the front end.
They don't have much experience with that.
I could mentor them rather than do that work myself while I focus on some more complex part of the problem.
And my job becomes to just make sure they have the support they need,
make sure that their bit of the project is on target,
that kind of thing.
Then you have another engineer who can do it.
Right?
Is like,
there's,
there's a reason that a lot of big companies have like an org and mentorship dimension to the expectations that they have is because there's a couple of different ways to get more work out of people.
Right.
And one of those ways is to like,
like,
like more net brain available,
right?
And one of those ways is to like,
hire people.
One of those ways I guess now is like have ChatGPT do it,
right.
And one of those other ways is to like grow people's capabilities because now where you had one front end,
front end engineer,
maybe you have two or maybe you went from 0 to 1,
right?
And,
and you're,
you're kind of if you're the only front end engineer,
you want to be getting yourself out of that critical path so you can work on the things that you can't put someone else in the critical path for.
Right?
Like "go where you're rare" is another really great um,
tidbit that I heard once,
which is like,
do the thing that isn't gonna get done unless you do it and that's the best use of your time.
So that reminds me of.
So I asked this question a lot because I think it's probably maybe the most important question,
not the most important question,
but it is often on everybody's mind,
which is that you mentioned earlier,
picking the project that's gonna have company wide impact.
But as we all know the chances of that just falling in your lap in an obvious case of like,
you know,
you have to go back to the cake analogy.
You have catering for the CEOs of all the Fortune 500 companies in on the planet and catering for,
you know,
a little league team.
Well,
one of those is obviously gonna have more company wide impact,
right?
But often it's more like,
you know,
catering for,
you know,
two different,
like relatively unknown (to you) events and you don't know which of those is gonna ultimately be important to the people who are responsible for giving you,
you know,
who,
who you want to,
to see your impact.
So how do you identify that?
Um because that's always something that I come back to it.
Like,
you always have a lot of choices for what you work on,
at least I tend to,
but it's always hard to know which of those things deserves your time and attention.
It feels like the very core of the question,
right?
Is like managing that.
I think that you have to talk to people,
right.
In the end,
the sometimes the easiest way to get information is just to ask.
And I think a lot of people sometimes assume that they're like working in the backwater and what they do doesn't make a difference.
And I mean,
at a very like macro level,
yes,
the one piece of code you write,
wrote may not make a really big difference,
but it's when you put that together with everything else that,
that becomes like a product.
And that's,
you know,
I being a production engineer feel really strongly about,
you know,
hey,
the backend system are really,
really important in automation and being able to scale our infrastructure is sometimes yes,
that is the difference from people being able to access the product and not being able to access the product.
But a bunch of people will be like,
well,
if you're not adding a feature to the product,
what value are you adding?
And I think this is where it becomes important to like do two things and one is talk to people,
maybe you don't have any scalability problems.
And so features are the right things to work on and you should,
you should take that and you should run with it,
right?
And sometimes the second thing is like,
maybe you need to make a better sale,
which is like,
I have perceived this problem that when more than 16 people use this website,
it will go down.
That matters,
right?
So I uh we we've got just a few minutes left here in our time.
So I want to move us over and give all of us a chance to pick something: resources that we want to share with our listeners or plugs for,
for things that would make us all lots of money if only people knew about them,
uh whatever we're into.
Um uh Andrew.
Do you want to start?
Yeah,
sure.
So um I have like four resources,
two of them are softer resources and two of them are more technical resources.
I'm gonna start with the soft ones.
Um "Radical Candor" by Kim Scott: super duper,
Awesome book.
It really helps you figure out how you can be honest with people when you have really hard things to say to them.
And in engineering,
this happens a lot where it's like that is,
that is wrong and I don't think you should do that.
And sometimes you have to navigate those conversations and it's really,
really challenging and being able to be like honest or when you're giving feedback or you mentoring people that's really,
really handy.
Um The second one,
similar lines um is called "Crucial Conversations."
It was written by like a bunch of people that I'm not gonna name all here.
But again,
it teaches,
they say like how something,
something,
something when the stakes are high.
And it's like,
how do you navigate like interpersonal conflict and how do you navigate challenges and things like that?
The engineering resources are the "Linux and UNIX Philosophy" by Matt Gancarz.
I read this book a long time ago.
I actually honestly reread it like,
every three or four years.
It's really great because it just teaches you different ways of designing things.
And,
um,
I even,
especially like,
Linux is like,
really,
really big right now and there's a lot of the design principles that are under the hood that it's like worth learning and like picking up on and,
uh some,
some amount of,
some stuff that has not aged well and,
you know,
do you,
it's up to you to take what you take and leave
what you leave.
Um And then the last one which is like really modern and is frequently updated is there's a dude on sub stack named Gergely, and he writes a piece called "The Pragmatic Engineer."
Um I pay for this thing out of my own pocket.
It's really,
really great.
It's got everything from like,
how do I find a new job to like breakdowns of like how engineering cultures work or how people have solved engineering problems?
They had,
he had like a really big four part series on like how a big in-place migration went.
And that was a super awesome read.
And for me,
it like wasn't super, like, novel,
but there's a lot of people who've never seen that before and it can really help you when we talked about like asking the right questions and like pushing on the requirements,
reading stuff like that and seeing where things went wrong can give you a lot of ideas of like,
oh,
this is maybe what I should watch out for.
Those are great.
Thank you for those awesome! Alex:
You wanna jump in next?
Sure.
Um I have a couple of books just to,
they're a little bit lighter than I usually recommend.
I've got "Grokking Algorithms."
It's pretty light but it's a good way to refresh yourself on.
I know it's like not high level of some of the other stuff,
but I've been having fun reading it on the train or just uh going through whenever I have a spare a few minutes and it basically just goes all through the classic algorithms and data structures like link lists and all that sort of stuff.
And it's,
it's pretty fun.
It's pretty,
it's again,
it's pretty simple.
And what's nice about that is like,
I don't need a computer with me to like go through it because the examples are pretty good.
And because the the data structures of the covers are not so complex that I want to like immediately write out a test for it or a test,
solution for it.
And then I'm also reading um "The Design of Everyday Things,"
which is a book by Don Norman.
And he's a designer for Apple and a few other places basically writes about just to generally design.
But from the approach of like everyday things.
And one of the a classic example of this is he talks about like how if there's, if you ever run into a door that you accidentally push instead of pull when it is supposed to be pulled,
that's a failure of design.
And he goes through all the reasons why that door failed you,
the user, rather than the door rather than you being dumb.
Which is nice because,
you know,
I feel so much better now!
Right?!
It's very nice because it,
because it reminds me of like,
maybe I'm not dumb,
maybe the person who designed this door is,
is dumb and that's a better feeling than the alternative.
But he goes through a lot of really good examples of like everyday things and how they have interfaces and how we interact with them.
And then it applies really well to software engineering because it's the same sort of thing you want to provide either from your end users or if you're writing something that other engineers are going to consume.
It gives you a lot of tools for how to design an interface or to design,
you know,
a system that other people are going to use in a way that is delightful and is simple and deep and it really connects well to um two of the other my other favorite books,
which I've probably recommended 100 times in various places,
"Philosophy of Software Design" and "The Pragmatic Programmer."
And it really connects well with what the,
the advice of them and "Clean Code."
But mostly those two,
it really actually connects very well with them that gives you kind of a different perspective.
So those are my two picks.
"Pragmatic programmer" was on my short list to,
to put in the resources.
So I love that.
I think Brian's already recommended it.
We actually,
yeah,
I plugged it a couple of times.
So yeah,
I think that's obviously on the very short list of books that,
that every engineer needs to read.
So yeah,
it,
it comes up often and it's interesting you talked about,
you know how the first book that you mentioned has aged and there's a few things in pragmatic programmer even now that I think it's still the definitive book on,
on these things.
But as you read it,
you go,
some of those things like are just sort of given now.
I, it's interesting that like that they spent an entire chapter to write about using version control.
And I'm like,
OK,
but I kind of feel like that's just everywhere now.
Like I,
I don't think there's ever a discussion about should we or should we not use version control?
But I don't know,
maybe I haven't worked at the right companies.
"Clean Code" is
that way.
"Clean Code: has like multiple chapters dedicated to comments and naming conventions which are all pretty well standard at this point.
I don't know.
I think naming conventions is still a topic that warrants discussion in companies because you see when it's done wrong,
it is a real problem,
I suppose.
But,
you know,
if I,
like,
you know,
make it descriptive but not too long,
which is like,
ok,
cool.
Yeah,
I guess if you need to save character strokes,
which is like,
you know,
not so long,
well,
not so long,
it's like,
takes longer to read than it takes to understand if that makes sense.
Yeah.
Yeah.
Makes sense.
So I'll jump in here.
Um,
so because this was an episode about metaphor and especially because it was a food metaphor, that really reminded me of one of my favorite blog posts I've ever read.
The blog post was written by someone else but explaining a concept that was introduced by a guy named Hunter Walk who is a partner over at
Homebrew.
And the idea is the first rule of prioritization,
which is an absolutely essential skill as a staff engineer, is prioritization.
The first rule is "no snacking" and what he means by snacking is working on low effort,
low impact work. Stuff that you can easily knock off a todo list,
feel like you're working and it ties into what Andrew was talking about earlier,
which is don't mistake motion for progress,
right?
It,
it's working on stuff that you can knock off.
But at the end of the day,
it actually doesn't matter that much,
right?
It's not that it doesn't matter at all.
It's not that it's not on a feature list or a priority list somewhere,
but it isn't the most important thing that you as a staff engineer could be spending your time working on.
In this article,
he shows a matrix that has effort along the X axis and impact along the Y axis.
And of course,
like where you'd love to spend all your time working is in that quadrant that has like low effort,
high impact,
of course,
like easy stuff that is tremendously important.
But at a company of any sufficient level of maturity that work's been done already,
right?
Like that's that the people who started it got that stuff done and that's not why you're here now.
And when you're stuck and when you're dealing with something complex,
it's really tempting to just go have a little snack.
I'm gonna spend today just like cleaning up a little test suite or like fixing a typo trying to reach 100% coverage again,
like these kind of things,
like they might be important,
but they might not be important and,
and just because you're like doing stuff and shipping code,
it doesn't mean that you're doing the important stuff and where staff engineers really need to be spending their time is in that upper right quadrant which is high effort,
high impact.
Do the hard stuff that really matters because if it was easy,
it would have been done already.
And one of the first things that a staff engineer's expected to do is go solve the problems that others have not been able to solve.
And that requires just forcing yourself to work in that upper right quadrant where it's difficult but high impact.
Anyway,
I'll link that blog in the show notes because I thought it was terrific.
And,
uh,
and it's a food metaphor.
Do you know the name of that system that you're referring to?
I've heard it before with the four quadrants.
I've seen that like,
a lot of times for,
like prioritization,
it's like a prioritization, priority matrix.
That's what that's called.
Ah Oh yeah,
that's right.
Priority matrix.
I love it.
I guess technically that counts as a matrix,
but I'm not super happy to call that a matrix.
You want to call it a graph,
right?
It is a graph.
I I feel like that maybe just has a better ring to it than Priority Cartesian Grid or something like that.
But,
but then you could call it the PCG you could.
But then,
but then you have what you and we all need more acronyms in our life,
many acronyms and then you unpack that when you're like,
oh no,
I understand it less than I did before.
Um Well,
I think that brings us up to time.
So Andrew,
I want to thank you so much for coming on.
It was a real pleasure to,
to talk with you and also to get a chance to sort of reexamine this analogy together and,
and rework it.
I,
I think this was, this has been really great,
but I can't
thank you enough for your time.
Thanks for being here.
Thanks as well.
I had a great time,
uh,
meeting you both.
Well,
one of you for the first time,
but I'm happy to happy to come back if you ever want me.
All right,
thanks.
The,
the invitation will certainly come around again in. Open invitation.
All right,
everyone.
Thanks for listening.
We'll catch you in the next episode.
Cheers guys.
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 @themainthread on all major social media platforms including Facebook,
Twitter,
Instagram,
and of course Threads. If you prefer,
you can send us an email at mainthreadpodcast@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.