Join us as we gather around the hedge,
where we dig into technology,
business, and culture with the finest minds in
computer networking.
Well, happy New Year, Yvonne.
Are we gonna say Happy New Year. Are
we gonna do it again?
We can. Well, just so you know, we
had to restart. But, yes, are we really
allowed to say happy New Year this time
of year? It's the January.
It is the first time we've talked. It
is. It is. So I'll give you a
pass. So happy New Year to you and
to Tom and to the plant. And to
the plant and to the frog lamp.
The frog lamp. The the the the the
frog lamp. I don't I don't I was
gonna say this less sentient, but I don't
know if that's actually accurate. Because if if
Tom's plant is sentient, we've got a problem.
Yeah. We do. Maybe that's how it gets
so much done. I don't know.
Yes. You know, there is a key there
the plant is on a desk,
and there's a keyboard somewhere over there. And
I think that I think the plant types
in the background, and we just don't see
it.
That's
sort of cool and terrifying at the same
time. Is this is this is it Little
Shop of Horrors? Am I got have I
got my
movies right? Yeah. That's
so happy New Year, Tom. Happy New Year,
Tom's Plant.
So Happy New Year.
So time for a roundtable. First of the
year,
beginning of the year, not first of the
year. We're fifteen days in. I can't believe
we're fifteen days into 2026.
Make it stop.
Anyway
okay. Well, maybe not.
Maybe not. May maybe making it stop wouldn't
that be a good idea? I was gonna
say, I'd like it to keep going, please.
But
okay.
So we're gonna talk about today bringing back
specialization.
It's the new year. I can't talk anymore.
And this is from a blog called Thinking
Sideways,
and we're just there's a thing here on
the blog talking about
how looking at software
developer job postings,
modern developers are supposed to be jacks of
all trade.
Now my theory is always jack of all
trades, master of one.
But there is always some amount
of what is that called? The t shaped
knowledge theory?
Yeah. Is that is that what it is?
Yeah. T shaped skills
that,
you know, some amount of depth in one
area
is really good even though it consumes
the depth from the other areas. And, you
know, you need a point
in your knowledge,
but you also need the flat part of
the t. It's an upside down t.
Why do they call it a t, Yvonne?
It's upside down.
I've always seen it drawn
with the flat line at the top. But
the,
the the point is, like,
deep depth in one subject,
breadth across
several,
tangential
or,
yeah, connected subjects.
Adjacent. There we go. Thank you. Tom,
jumping in with the right adjective.
So
but it is true that we have gotten
to the point, particularly in software development and
even in network engineering,
that we are now kind of expected to
know I mean, how many times we hear
it. Oh, you can't be a network engineer
unless you know how to code.
Well, there's a level of coding you can
know as a network engineer. Got it.
But there's a level you can't.
There's there's a limit to how much of
a good coder you can be and be
a network engineer.
The same same way, by the way, the
other way around.
There's a level of being a good network
engineer you can be while still being a
really good coder.
Like, you're you're gonna have to choose one
of those two skills.
And the example that this particular blog post
makes is about, like, DevOps.
Well, we can do the same thing.
Right? NetSecOps or DevOps or whatever we wanna
call it,
that
there's a point where
we are
doing
trying to do too much.
And
how do you find that balance, or how
do you know where that is?
So I don't know. Yvonne, Tom, the way
Well, the
the how do you know, I think, is
a really difficult
question to ask. And the and the problem
is it changes over time. Right? The,
because as technology
evolves,
certain things that required
very deep levels of expertise
ten, fifteen years ago,
have either been systematized or standardized such that
the vast majority of people don't need a
ton of deep level knowledge in that thing.
So,
you know, there's also a time component to
this as well.
But I think
if you want to remain
a technical person and do technical work,
you have to be known
for a thing.
But
that depth of knowledge,
the more
narrow it is and the less interconnected it
is with other domains of knowledge, the less
valuable it is.
Yeah. I have I have other thoughts, but
I'll pause for a moment. I I think
there's two, two different ways to look at
it. One is from the perspective of someone
who assembles and maintains a team such as,
a leader or a manager, and then the
other, which I think is a very different
perspective than, being an individual contributor.
Being an individual contributor,
you can, you know, you basically, you can
take it on yourself to figure out what
are my what are my adjacent areas of
knowledge that I'm gonna participate in,
and and obtain. And some people would say
they shouldn't be adjacent. Like, one one,
pretty common piece of advice for this is
that they should be they should be actually
pretty disparate. Like, if you're good at, if
you're good at spreadsheets, you should, you know,
you should go learn how to be a
DJ or something.
Like and it's, you know, stretches out your
your ability to think and and applying cross
domain thinking is, I think, really important. But
then if you're a if someone assembling a
team, then you have this group this group
of people
who you can't fully control who comes to
the team. It's, you know, there's a whole
bunch of factors. You know, I'd love to
hear your thoughts on this, Yvonne. But, like,
whenever somebody comes, they're gonna bring something new
that maybe nobody brought before. And whenever someone
leaves, your team is gonna be without something
that it took for granted before.
And I think that's also a really important
perspective.
So there's actually a piece in here where
he says,
he begins by saying,
a developer's job has become a lot broader
over the last fifteen years, and I think
this is a problem.
Agreed. I mean, this is true for network
engineering as well. It's become a lot broader
over the last fifteen years,
even more sharply over the next five last
five to seven years, and this probably does
have a problem,
cause a problem. He says, while this generalist
approach can take us very far, it clearly
has limits. In some situations, we require deeper
knowledge
because,
things that we would have at hand but
never really bothered to learn. Specialization
has value. For example, when we need a
heart surgery, we want to go as to
a specialist instead of just any surgeon. So
why don't we apply the same logic to
software development
and get a let a back end engineer
get really good at building back ends?
The only explanation I have for this trend
is that generalist software developers
are very convenient for management.
That's So, honestly, I was thinking some of
that as well.
Not as much the convenience for management.
But, frankly, I think we find ourselves in
a lot of situations
where organizational leadership just can't tell the difference.
Like, they cannot tell the difference between
deep,
high quality expertise
and,
you know,
something broad, and they and then and then
they don't know how to connect the work
to that expertise.
I I think that absolutely happens.
The other thing that I've I've seen is
that
there's an assumption
that if somebody is deep and really strong
in one technical area,
that you can just pick them up and
drop them in another technical area. And in,
in a very moderate amount of time,
they can obtain the same level of expertise
in a new area.
Some people can do that.
They are the absolute exception,
deep expert in a topic area. I think
that's that's the other challenge. Because it's not
just,
I read the book and I can regurgitate
it
to you. It's, you know, Russ spending years
on the phone with customers intact solving really
weird
problems that that
delivers an area of expertise that you just
can't get anywhere else. So I I see
those things happen as well.
And I think there's actually an expertise in
what you're talking about, Yvonne, which is the
ability to pick up and learn a new
thing.
And that takes even longer to develop,
and yet we seem to expect it out
of college grads
for some crazy reason.
Like, we think, oh, the big difference between
an architect level network engineer
and a and a college level network engineer
is just that the architect,
you know, has deeper no. The architect should
actually be able to pick up new technologies
and solve new problems more quickly
because they've developed the skill. It's like learning
to read.
Some people just read faster because they've practiced
reading for twenty years,
and they maintain that information or retain it.
And, therefore, they can pick up different kinds
of books and read them and get all
the value they can out of different topics.
It's just a different
way of looking at or seeing
the world and a different kind of experience.
So I think we underestimate
the value of that as well.
Now
another thing I was thinking when you were
talking about that, Yvonne,
is that,
what was I thinking?
I've lost my train of thought.
I'll, I'll jump in. So one of the
things about what you mentioned though, Russ, is
like these, you know, younger folks, 20
just out of college.
I think one of the things that comes
along with that also
is a little bit of hubris
and not really understanding how much there is
to know. So if a leader comes to
them and says, hey, can you do this?
That that that you know, they'll jump at
it without not without knowing what they're getting
into. Now there are some advantages in that
because
a lot of times we learn by doing,
and so they just jump in and they
figure it out.
But I think what it till you make
it. Yes. And and and look, that can
be a a very valid strategy. I don't
mean to I don't mean to because I
think sometimes those of us who've been around
a while can get can can get stuck
in analysis paralysis sometimes,
or be like, I don't know that I
wanna dive into another thing deeply because I
know how much it took to get deep
here,
right, in another area. But I but I
think that's that's also a component too.
Yeah. So it's it's an interesting conversation for
sure.
The,
the leap without looking that you're talking about,
Yvonne, I just I just remember early times
in my own career when I did that
several times.
And it's as a result of that, that's
what drove some of my some of my
own deep expertise was deleting without looking. But
then, like you said, when you when you
get more experience, you're like,
Yeah. I did that. No. I don't think
I should right now.
I've worked too late. You're like, you know,
that makes your knees hurt. You know? Yeah.
Oh, yeah. Yeah. Yeah. Yeah.
Yeah. Yeah. Oh, when I was a kid
in the air force, I would climb 90
foot towers without safety gear. I mean, the
safety gear was there. It was hanging off
my belt. Right? But, like, I'm in a
hurry. I've gotta get to the top. I've
gotta get done what I gotta get done.
Let's go.
Nowadays, I wouldn't even climb a 90 foot
tower.
Safety gear, no. No. Ain't happening.
You know? It's just
the ground looks a lot farther away
the older you get.
I think the
I think the I think the meta topic
there is that we need we need both,
perspectives and,
propensities.
We need people who are leaping without looking,
and we also need people who are not
gonna do that anymore.
Any either of them. I think sometimes it's
easier to value the leap without looking because
you're like especially for management, like, okay. Well,
they'll struggle. They'll figure it out. I don't
have to do anything. I just know they'll
do it. And that that I could that
could be convenient, you know, to quote the
article. But then
I you know, but but having someone there
to to guide the the useful,
the useful energy
is more likely that you'll end up with
something that produces revenue, I think,
could produce great experiences, but how much is
it gonna move the business forward
without some guidance? You know?
And he and Go ahead, Yvonne. I was
just saying this article, he he brings up,
the challenges of cloud as well. Right? Because
in on premises infrastructure,
yes, there are absolutely nuances between different vendors.
But not but but you have a you're
generally running protocols with standards.
And so there's
some degree of alignment and and ability of
to interact with those products. And and, of
course, when you think about cloud, there are
also some of those protocols that you can
use to interconnect. But when you talk about
things like troubleshooting,
performance tuning,
observability,
deployment
patterns, and things like that,
there's so much variability
between public clouds
that,
expertise
in a particular cloud becomes its own thing.
So you're not just a cloud engineer,
you're a Google Cloud engineer, or you're an
AWS engineer, or you're an Azure engineer.
And then those will be divided up into
different
technology
specifics, like
containers,
or infrastructure,
or networking,
or data, or analytics,
or AI.
So there are many, many, many
areas for specialization.
But I think it's also important to realize
that
these things are not like
a red LEGO block and a green LEGO
block. Like, they're they're
an order of magnitude more different than that.
And and I think we lose something when
we forget that. Yeah. It's like instead of
trying to build a castle out
of Lego blocks,
you actually the the square and the round
you know, the square and rectangle and you
actually just have little people heads,
Lego blocks, and you're trying to build a
castle or something. It's like, these are very
specialized pieces, and you have to have somebody
who specializes in knowing that piece to do
it really well.
And to me, that actually drives another problem,
which is that tunes or pushes against
success for smaller businesses and smaller shops.
Because if you need five different specialists
or 10 different specialists to interact with AWS
or with Google Cloud, or if you wanna
interact with both, now you're looking at 20
specialists.
How many businesses are big enough
to hire 20 different specialists
to interact with two services?
I think it also though is why our
career trajectories are off at least for me
personally, my career trajectory has been
smaller organizations to larger larger organizations because I
cut my teeth at a small mom and
pop ISP.
I mean, I did everything from
web development, wrote some really bad PHP code
that is still running a website somewhere,
you know, and this is twenty five years
ago,
to networking, to dial up phone support, to
all of those things. Now was I an
expert in any of those? But no. I
was good enough
to meet the needs of the business. We
hired specialist contractors for those things, and it
gave me a great,
great, great, great foundation to go
many any number of things. And I think
that's why you see a lot of people
in their career trajectory start at small orgs,
get this broad
skill,
and then they move into more specialized roles
at bigger organizations.
But I think that's part of why we
have,
you know, partners and, you know, third parties
and consultants who can come in and help
because, yeah, no. You can't
you know, a small business can't staff
a 100,
you know, 6 figure engineers
to to run a small environment.
Yeah.
And career wise, that's another interesting question.
This idea of specialization,
should companies
intentionally go about
trying to create spaces
for generalist
even just from a career perspective.
Right? Like, if we all think because I
do. I think that starting a career as
a generalist
and getting the broadest space you can is
extraordinarily
important.
I have no idea if I would be
a quarter of the engineer today that I
that I am now
if I didn't learn electronic engineering before I
went into computer networking.
And if I didn't do Banyan Vines and
I didn't do
Novo NetWare
and
LAN,
token bus and token ring and all that
other nonsense
because I had to actually learn how this
stuff worked, right, and why you use it
certain ways.
So
are we
does specialization
hurt
career growth when it becomes too much,
or should companies can companies find ways to
make space for both?
Is that a possibility?
I I think there's,
I think it's possible that there could be
in terms of one person's career, there could
be like a skinny waste type model
that you start with what you talked about,
Russ. And and that was similar for me
and sounds like Yvonne maybe similar there too.
Like, you you when you first start, you
do other you do different things and you
don't get too deep in any of them.
And then something draws your attention, whatever you
start to to specialize.
But then I think
I think the need the the need for
generalists is such that, you know, you so
you start broad, you go up to the
skinny waste of a,
of a specialization. And because specializing in itself,
regardless of the area, trains your mind in
a certain way that you're not gonna get
by generalized generalized,
application of knowledge. And then and then after
that, what if you spread out again?
I did a a bit of a career.
It was a pretty big period change about
five years ago, doing very different things than
I was doing before that as a specialist.
And I found, as I did that, that
my previous knowledge was instrumental. It didn't put
me behind. It put me ahead.
And and the biggest thing I was concerned
about was, am I behind all these people
because I'm doing something different and broader now?
No way. Specializing helped me to be a
better generalist. And I don't know I don't
know if that's a if that's a a
a model for career development, but I feel
like, with your people, that probably should be
about the same thing. There should be you
should have some generalist and some specialists,
and they should be moving somewhere along if
that's a model. You know, they should be
moving somewhere along it.
I don't know. It it just the your
ability to think and to think differently,
to think as a specialist in a generalist
environment is very has been very valuable to
me.
So
what do you think, Yvonne? You're the closest
to a man you mean, you're the closest
to management of all of us. Don't remind
me. It's it's been the kinda week where
I'm like, what have I done? No.
I yeah. I think
I think you do have to have a
a place for both. I think talent development
and thinking about that and aligning it with
your organization is a really it's really the
reason that companies don't do it well is
because it's really hard.
It's really hard to do that,
especially depending on what the nature of your
business is. But I do think it's very
important. I also think if you're going to
deeply specialize,
you have to have some sense
of what's valuable and what
kind of deep specialization
people are willing to pay for.
Because if, you know and and and, Russ,
I've heard you say this, that you had
a colleague that said he wanted to be
a deep subject matter expert on a protocol
that no one uses.
Don Slauson. Yep. Which is which is fine
as long as the company that you work
for
still acknowledges that they need that protocol.
Yep. But once
people realize, oh, hey. We really don't need
this protocol anymore,
then then you've got a problem. Right? So
I think that is the other big question
that
we have to constantly be thinking about.
Yeah. Is is there a market for what
I know how to do?
And
how is
how's the world changing to make that
that to to to change
where I need to be focusing? And and
if you pay attention typically, you can stay
ahead of that curve.
But there are many people who
don't or haven't or think their skills of
ten years ago
are gonna be enough to carry them through
the end of their career.
And depending that that may not be the
case. I the thing that's top of mind
for me now are the all those people
who spent all those years specializing in VMware.
Deep subject matter experts
really knew that domain,
really thought that would be where they would
be to spend the rest of their career.
And there's still absolutely a need for that.
But there's been a change in the market,
and there's been a change in that company,
and there's gonna be a change in demand
for that deep expertise.
And,
that's why your tea is important.
Yeah. And so that's that's another thing to
think about as somebody who's thinking about this
from a career perspective
is that
companies don't always expose where they actually hurt.
They're at they actually managers will tend to
upper level up level management and down will
actually normally tend to expose
what most impacts
their next move or their perception
of performance,
not where the company is actually hurting.
So sometimes you have to look at the
go a step further and say they may
not know. They may not know. They really
don't know because the higher up you get
in an organization, the more noise there is,
And the harder it gets
to pick out the signal from the noise.
And so,
I am we know that there are lots
of squeaky people out there who squeak about
a lot of nothing. And then you've got
the hardworking folks that are, you know, showing
up every day, doing their job,
doing some glue work to try and keep
things going that nobody knows is getting done.
I think I think that's the other thing
is that people often believe that folks
know and are just ignoring.
A lot of times they really don't know
because it's so noisy. They can't they can't
suss out that signal.
And and that's a whole different set of
skills that we could talk about, but probably
Yeah. Right. Podcast. But but as far as
specialization goes, if you're thinking about what you're
gonna build your t shaped knowledge
on,
something to think about is
don't look for what your manager is necessarily
telling you
is the problem
that needs to be fixed.
That's a good that may be a good
starting point.
But the reality is
it probably is tangential or even orthogonal to
something
that really is important.
And and it's just because they don't know.
I I I really like, your example about
VMware, Yvonne, because,
there there's a way to there's a specialist
generalist way to look at this too. So
if if you specialized in that product and
just spent all of your time and there
is so much knowledge that it's easy, I
could see I could easily
get get,
you could spend ten years learning in that
product.
But another strategy would be to say, alright.
I'm working on VMware. I think this is
kinda cool.
Probably another way to look at it as
a set of let me learn this product.
It would be learn let me learn this
technology group. Let me learn how virtualization works.
And the thing that's cool about that is
that you can once you have a little
bit of that, you can start to challenge
the vendor of the product
and you can say, okay, well how does
this work? What is like for virtualization?
Does such and such support s r s
r I o v? Do I really get
all of those PCI channels that I'm supposed
to get? Like and and what about this
and what about that hardware? And like you
can in the process of challenging product vendors,
I think you learn a lot about multiple
domains simultaneously. I feel like early in my
career, I spent a lot of time challenging
product vendors
and,
it it gave me it gave me social
skills, but it also, like, helped me to
ask technical questions in a in a correct
way. But none of that would have happened
if I would've if I would just said,
oh, I just wanna buy Cisco stuff. And
I don't want like, if the brand and
the product
were the focus, you know. But if it's
the technology area, then if you wanna learn
how how things like this work, I feel
like it's like that's a lot more safe
and it also I think it drives more
expertise. At least I I feel like it
has for me.
And and that's an important distinction there, Tom,
that you're making is vendor specialization
and technology specialization.
And always, always, always,
you can work for and with a vendor,
and and we all do and have.
And and it's fine to even
have some significant loyalty, but it's also important
to distinguish in your mind
what's the technology that I'm specializing in and
what's the product that I'm specializing in. Because
the technology
often
even if it goes away, it's gonna reinvent
itself in another iteration.
And you can use those skills still,
like virtualization.
Right? Like, how many different forms of virtualization
do we have now? We've we've we've not
got we've not only got all the public
clouds,
containers
and Kubernetes.
That's another form of virtualization and orchestration. We've
got all kinds of
app virtualization
that goes on, and those concepts of abstraction,
all that carry across.
So it's also important for specialists to think
in terms of the technology,
not the brand
of what they're working in. Yeah. Just like
if you think about networking. Right?
Do you specialize in protocols, or do you
specialize in
how does the network work? Like, this to
me is the difference between the OSI model
and the RHNA model.
Is that the RHNA model says, I've got
to solve these four problems.
Well, what are the four way what are
the ways I solve those problems? Well, guess
what?
Every protocol in the world
solves this problem in one of four ways,
six ways, three ways. If I know those
ways,
I know all protocols.
And therefore, you know, I'm able to pick
up new protocols.
The same thing is gonna be true, by
the way, in software development.
Oh, there is a loop structure.
Every
every
language
solves loops, and there are basically three kinds
of loops. There are basically three or four
kinds of data structures.
You just gotta go figure out how they
do those things.
And if you think in terms of the
data structures
or in terms of the loops, the the
the code structure,
you stop thinking about whether this is in
C or Rust
or
Python.
You start thinking about how is this software
structured. I need to outline it.
I'll bet you I've never looked into it.
I'll bet you there is the same thing
for virtualization
technologies.
That there's only three or four ways
to solve any particular issue in virtualization,
and
that's what you got. Concept of primitives. Right?
You're only gonna have so many primitives.
I think where specialization, you think about software
development comes in. Like, if you're
if you're performance tuning, you've got really
tight ties between hardware and software, and you
really are trying to performance
tune
or you're working in a low resource environment,
this very
specifics of a particular language then become very,
very important. Yep. Right?
You know, you're gonna use c, you're gonna
use c c plus plus, you're not gonna
use Python if you want something that's heavily
optimized. Right? But if you want something that's
very language based, very easy to read and
understand and write, all that, like, it might
be the right option. So those those kinds
of nuances do become really important.
Sometimes you just have to pivot because of
where the market's going. But as Tom pointed
out, if you have specialization in one, you
can it will be easier to get it
in another area.
Yep.
There. That's why that's why, Tom, when you
talk about generalization,
the wasp waste and in generalization,
you come to the narrow point and you
go back out. I think that's the reason
you get to that wasp waste
is because
once you've learned a technology, you've you've taken
this broad base,
poured it into a specialization. But if you
do it the correct way,
you now have built effectively a foundation
that allows you to go out and say,
oh, sure. That's VMware and that's Docker.
Okay. But they both have to solve this
set of problems, which I learned by studying
VMware.
But now I know what the problems are.
I know how VMware solve those problems, not
just how to configure it and, you know,
what they call it and blah blah blah.
I understand how it solved the problem. How
does Docker solve that problem?
Now I'm actually asking the correct questions
to broaden back out.
So, I mean, I guess in terms of
the article,
specialization
is a problem, but it's only a problem
in a specific way to me
In that, if we all become hyper specialized
or I'm sorry. Generalization is a problem, but
it's only a problem in a certain way
to me in that if we never become
specialist.
If there's never that
that point where we become the specialist
that helps us to go back out
and be better later on.
So maybe that's a way of looking at
it. I don't know. Think the the my
feeling from the article is if you're if
if the industry seems like in the job
market seems like it will seek out generalists
first. Yeah. And if you it's not really
gonna it's not optimized for specialists the market
itself.
So if you if, like, if you want
to specialize,
someone else is not gonna do that for
you. There's gonna be no external pressure to
say, hey, you should specialize. Yep. It'll be
your own curiosity. It'll be in your own
realization that I want or need to do
this.
And that's a big differentiator for because some
people, they they just wanna respond to the
market and what other people want them to
do, and that's their path in life. That's
okay. But then there's other people who are
who are a little more type a about
it, I think. And
and I think it's it's not it's probably
not reasonable to think that the market is
going to, push you towards
specializing,
in the current climate.
Yeah. And I think there's a there's one
more component to that too, and it's industries
go through
phases
where
they're in the act of being disrupted
or in the act of stabilizing,
and that requires a different set of skills
as well. Right? Yep. And right now we're
in the middle of an industry that's in
the act of being disrupted,
especially when you're talking about software development. So
people may be looking for broader skills right
now because they don't know where things are
gonna land.
Right? And so and then,
like, it's it's like, you know, do I
hire a VHS technician or do I hire
a Betamax technician or do I hire somebody
who can do both? Well, at one point
in time, you needed both.
And eventually
I'm sorry if I'm dating myself. If you
don't know what BHS
is,
I know you were born after the turn
of the century, the most recent one. But
anyway,
it it you know, like,
the market
figures itself out, and then it gets confused
again.
And so that's also gonna determine
both
when what specializations
are
desired
and how much specialization is desired. And I
think that could be part of what we're
we're reading about too. It's like there's just
so much disruption going on. People don't know
what they need. And they don't know because
they really don't know, and they can't know
yet. Yeah.
And I would also say don't be afraid
to self specialize to some degree just by
yourself, as Tom says, even though the market
doesn't drive you.
Because you know on the other side of
that,
you're actually gonna become a better generalist
via that process.
So, you know, don't don't be scared of,
I'm gonna go learn one protocol or I'm
gonna go learn one
virtualization
system in-depth and in detail.
But as long as you're approaching it the
right way,
it leads to
better
overall thinking
and generalization
in the future.
Yeah. I think there's I think there's a
fair amount of anxiety.
Well, what if I specialize and it's the
wrong thing? Am I screwed now? Like, have
I And I don't know. I maybe this
is just because I've
been around long enough, but I I I
think that's
not a concern really. Like, specialize in something,
you're good at something, and you'll be able
to figure it out. Like, you'll be able
you're smart enough. Like, everybody listening to this
is smart enough to figure out. You learn
one technology, you'll be able to figure out
another one. And Yeah. You're not gonna get
trapped. It's not gonna oh, what if I
specialize in Rust and then nobody wants to
use Rust? It doesn't matter. Like, you figured
out how to use that language. You you
got it. You can do another one. Yeah.
As long as you do it the right
way. Sure. As long as you But I
think what I think what Tom said is
so important. I I I I've kind of
graduated beyond. Like, I'm kinda tired of all
the talk about imposter syndrome
because, like, eventually like, you just gotta go
do the thing. Just go do the thing.
Stop fretting over whether you can do it
or not. If you're listening to this, you
care enough. You've got enough sense. Go go
do the thing. It's better to do something
than nothing, and it's better to do the
wrong thing than nothing because you can pivot
the wrong thing
pretty easily. Nothing is a lot harder to
pivot.
Yep.
As Radio Pearlman says,
do the wrong thing.
Just go do it. Do the wrong thing.
Is is there a
spanning tree joke in there somewhere? There should
be. There is.
Ex existentially, there is. I guarantee you.
Oh my goodness. I couldn't help myself.
Oh, boy.
Alright. So we should wrap this up,
and it's been a great conversation
about,
specialization.
I don't know. My brain's nowhere as well,
Yvonne. I don't know what my problem is
today. It's We're recording this on a Friday
afternoon in advance of a long weekend, so
it's fine with me. You get a pass,
Russ.
Oh, thanks. The plant also gives you a
pass, Russ, so you got two.
Alright. But Tom, no. No pass from Tom.
No. No. No mercy.
No mercy.
Alright.
Alright. So, Yvonne, where can people find you
if they want to?
Yeah. You can find me on LinkedIn at
Yvonne Sharp. I'm I'm on Twitter at Sharp
Network. I'm lurking more than I am posting
these days.
But, yeah, reach out.
Alright.
And, Tom, say your word.
LinkedIn.
The pause varies.
Yeah. Yeah.
But but that's he's got a random
time
limit. I wonder if we could measure it
and do some kind of correlation with his
behavior and figure out what kind of mood
that Tom is in based on how long
he pauses every day. Please don't study my
behavior.
I don't wanna know.
Alright.
I'm Russ White. You can find me here
at the hedge, rule11.tech
on LinkedIn
and x as routing geek whenever I decide
to log in there. Who knows when?
Thank you for listening to this episode of
the hedge. We know that your attention is
we live in a attention driven economy, so
we appreciate your attention. We appreciate that you
listen all the way to the bitter end
of this episode, and we will catch you
next time.