0:03

Nobody expects your iPhone to last 20 years, right? That's

0:05

Bob Charette. He's

0:07

a consultant and a contributing

0:11

editor at i3e Spectrum. He's one of the many people

0:13

we spoke to when we started doing work on Legacies.

0:17

In one of our conversations, he started talking about the systems

0:19

on submarines. A

0:22

submarine is different from a cell phone, as you

0:24

can imagine. The technology is a closed

0:26

system. It's

0:29

self-contained, and that's by design. And

0:32

different systems on a submarine do different

0:34

things, and they're

0:36

not integrated with each other. That's

0:38

also by design. And since these are large machines

0:41

that often are in remote areas,

0:45

they can go a while without an update. Think

0:48

decades. These things were designed, you

0:50

know, people thought

0:51

was going to be

0:53

a big deal. These things were designed, you know, people thought,

0:55

well, they're going to be there for 10 or maybe 12 years,

0:59

but they're there 30 years. They're there 40 years.

1:04

How do you modernize something like that? And

1:06

how do you maintain it? Those

1:08

are some heavy questions for people tasked with

1:10

doing the work. Meanwhile,

1:12

their friends over in the enterprise

1:15

are working on the latest and greatest, new

1:18

platforms and technologies, exciting stuff.

1:22

These systems can make an IT

1:24

professional feel isolated,

1:26

kind of like being in a submarine deep

1:29

in the ocean, away from everything, standing

1:32

still while the world moves

1:34

on without them.

1:36

How can we fix that?

1:42

This is Compiler, an original

1:44

podcast from Red Hat. I'm Brent

1:47

Simino. And I'm Angela Andrews.

1:50

We go beyond the buzzwords and jargon and

1:52

simplify tech topics. Today,

1:55

we're wrapping up our series on legacy

1:57

technology.

1:59

beginning, start from the episode in

2:02

defense of legacy. Let's

2:08

kick things off today with producer Kim

2:10

Wong. Brent, Angelo,

2:12

we've established over the course

2:15

of the previous episodes that legacy

2:17

infrastructure is sometimes

2:20

left in place because of human

2:22

factors. But

2:24

those factors aren't

2:25

always tech related. Bring

2:29

back Jim Hall. We heard from him in

2:31

the first episode of our series. Jim

2:34

worked as a CIO and as a

2:36

consultant in the US, sometimes at

2:38

the state government level. And

2:40

he says when it comes to keeping

2:42

modernization top of mind,

2:45

things can get a bit complicated.

2:48

In government, the funding model

2:51

is based on your tax levy,

2:53

right? So it's how many residents do you have?

2:56

How many businesses do you have, right? And what

2:58

taxes are they paying? This

3:00

tax money really should be going as much

3:03

as possible to benefit the public good, right? I mean,

3:05

there's no point in gathering these taxes if

3:07

they're not going to go back in some way to benefit

3:10

the resident, you know, building roads, repairing roads,

3:12

bridges, infrastructure, things like that. So

3:14

many of these IT departments are really responding

3:17

to the here and now. And then it becomes

3:19

really hard to think down the line.

3:22

And that has a trickle down

3:24

effect on the systems, the

3:27

networks and the applications keeping

3:30

everything running. That infrastructure

3:33

is important. It's just

3:35

not a priority, not compared

3:37

to everything else. And that's sad.

3:40

Yeah, I know, right? Like

3:42

it's easy for us to see this, right? We work

3:45

in the tech space and we know

3:47

the cost of modernization.

3:50

We know the cost of the cost

3:52

of things like technical debt, right? But

3:55

people that are not focused on that, they're focused

3:57

on keeping roads open. and

4:00

making sure that, you know, schools

4:03

have enough resources

4:05

and parks can be open for people to enjoy.

4:09

It's easy to see how tech can kind

4:11

of take a backseat to all of that.

4:13

Yeah, I mean, I can kind of understand

4:15

that side, which is like, if it still works,

4:18

what's the problem?

4:20

But then it's,

4:23

it works until it doesn't.

4:25

Oh, yeah, there it is.

4:27

If you're responsible for your constituents'

4:30

personal information or

4:32

the services that they need

4:34

to do to go about their lives on

4:36

a daily basis, and they're running

4:39

on ancient legacy

4:41

hardware software, and there's

4:43

a breach, what do you think

4:46

that does to your constituents?

4:49

So, kicking the can down the road

4:52

in this scenario, it's

4:54

never a good idea. I know we think of it

4:57

as an afterthought, but if

4:59

we just keep security and compliance

5:01

and data security in mind,

5:05

I think people would think about it a little differently

5:07

and give it as much weight as it deserves. That's

5:10

a really good point. I agree with that completely,

5:12

Angela. And Jim, for

5:15

his part, he says it's really hard to

5:17

get people to think like that. It's not

5:19

until something is a problem that people see the

5:21

problem. But, you know, I think

5:23

that these small and often

5:26

understaffed IT departments

5:28

at the state level, they

5:31

see the need maybe for new technology,

5:34

but it's hard to get them on board.

5:37

And it's even harder to get a government

5:39

official who's not touching that

5:41

technology at all and who is

5:43

often making decisions on budgets

5:46

and spending.

5:47

So, as a result, people didn't feel the

5:50

impetus to try something new

5:52

all the time. And so when that happens, technology

5:55

starts to sort of stagnate a little bit.

5:57

And that was my experience.

6:00

I'd like to ask these government officials,

6:03

do you have the latest iPhone? What

6:05

kind of technology do you have in the house? Do you have

6:07

a smart house? Do you have a smart refrigerator? I've

6:10

met you, these folks are using

6:12

new technology left and right, but

6:15

not even considering that

6:18

their towns and their town's

6:19

systems infrastructure

6:21

deserves the same type of weight.

6:25

I bet you. They're all walking around with

6:28

iPhone 14s. But what operating

6:30

system are you still running? The

6:32

city's website on? They

6:35

can't answer that question.

6:36

Windows XP. Oh man. We

6:38

went there.

6:39

We went there. Shots fired.

6:41

But

6:42

now,

6:45

now hold on,

6:46

because over these past few

6:49

episodes, we've been talking

6:51

about the value of legacy

6:53

technology

6:53

and legacy systems.

6:55

But now we're talking about modernization.

6:58

That's the deal. Okay.

7:00

There are some systems that are just rock

7:02

solid and by themselves,

7:05

that's not a reason to get rid of that just because

7:07

it's old, because it's still performing. But

7:10

there is an issue about who's going to maintain

7:13

it, right? There's the knowledge problem, the knowledge

7:15

gap problem. And

7:17

so some systems need to be replaced

7:19

because there's just simply nobody around

7:22

who's, or very soon there's going

7:24

to be nobody around who knows how to maintain

7:26

it.

7:28

And that is the real issue.

7:30

That's the rub. Yeah. One

7:32

that our listeners probably already know.

7:35

The technology isn't always the problem.

7:38

The people who have the skills to

7:40

maintain these systems, the humans,

7:43

are aging out of the workforce. And

7:45

the constantly changing tech landscape

7:48

means the amount of people who have

7:50

those skills is dwindling. So

7:53

organizations are being presented with

7:56

a tough choice. Balloon their budgets

7:58

with low priority modernization. work

8:01

or maintain what's in place until

8:03

there's no one left to do so.

8:06

Lose, lose. Oh, I would

8:08

not want to be in

8:10

that situation because like you were

8:13

just saying, it's a lose, lose. Like

8:15

you can't, it feels like you can't win here.

8:17

Time may make the decision

8:19

for you in this case. Yeah. And

8:22

it's not just general knowledge that's on the line. Here's

8:24

Bob Charette from the top of the episode.

8:27

It's a limitation of the

8:29

technology itself, a limitation of the hardware,

8:31

a limitation of the software. But

8:33

some of it is because that

8:36

was experience that was gained

8:38

in how to actually make this stuff work. People

8:40

have shortcuts or they'd find, there

8:43

were a lot of times that the people

8:45

had used these undocumented instructions

8:49

and now you're trying to say, okay, well, how do I

8:51

make, how do I accomplish

8:53

that with that instruction? It's

8:57

not supposed to be there. And in some cases,

8:59

the hardware manufacturers actually allowed

9:02

them to stay and made them documented.

9:05

So you work on a system long

9:07

enough. In this case, Bob

9:09

was talking about the submarine systems

9:12

that he worked on back in

9:14

his career. You become

9:16

a living document of its many quirks

9:19

and un-fixed bugs and additions.

9:22

And some people like

9:24

that. Angela, we've talked about this before on

9:27

the show where you have someone who's worked

9:29

somewhere for so long that they're like a walking,

9:31

talking documentation all up here.

9:34

Some people like being like that. But

9:36

if you don't count yourself among

9:38

them and that's not your ideal

9:41

job, that's not what you want to be, it can

9:43

be

9:43

tough, especially considering

9:45

how many people break

9:48

into IT in the first place.

9:54

All

9:54

right, everybody wants to work on the new software, the

9:57

new thing. People who work in

10:00

maintenance or often looked down upon

10:02

by their peers while you're working on maintenance.

10:05

Yet without those operating systems

10:07

your business goes away and

10:10

at the same time lo and behold

10:12

almost every undergraduate who

10:15

comes out of a computer science or computer engineering

10:17

course of study ends up working in maintenance

10:20

because that's where the need

10:22

is and that's where the

10:24

systems are.

10:26

No matter what

10:27

it seems, I

10:29

think you do have to have an understanding

10:32

of how things

10:32

work and

10:35

the underpinnings before you

10:37

go on and want to do the new

10:40

the next the new the next the new. I

10:42

think about we talked about this on the frameworks

10:44

episode right where you really

10:46

don't want to jump into frameworks because you don't

10:49

know how the language works underneath

10:52

so if something breaks you really don't have an understanding

10:54

of it and I think there's a lot of weight

10:57

in taking that step

10:59

back and kind of understanding I hear

11:02

that how things

11:04

before you jump into

11:05

it. For me I feel

11:07

like there's two things happening

11:09

here there's like that person who's coming

11:12

in to their IT career who

11:15

is being tasked with maintaining

11:17

this older system

11:19

or maybe older hardware

11:21

in this case we talked about hardware

11:24

in the series too and they

11:26

want to work on the new and exciting thing

11:29

not just because it's new and exciting but

11:31

that's kind of where the majority

11:34

of their learning their education

11:37

was like they got taught the latest

11:39

and the greatest because as we've talked

11:41

about previous episodes

11:43

there are many places in academia

11:46

where they just don't teach about these older

11:48

programming languages older systems

11:51

it's just not taught anymore so your

11:53

expectations are kind of off

11:55

and that's what leads to that kind of feeling

11:58

of being left behind or I think You're

12:00

being stuck in a basement with a bunch of old

12:02

dusty servers while your friends

12:05

are out there

12:06

living the life working on the

12:08

latest development tools, frameworks,

12:10

all of that. That's what I feel like

12:13

is going on here.

12:15

I wonder,

12:17

how do you come to terms with that if

12:19

you're new in technology and you're

12:21

longing for the

12:23

opportunity that your colleagues are

12:26

having? But if we think about

12:28

it, we all have to start somewhere, especially

12:31

if you're trying to get into technology.

12:34

I think any foot in the door is a

12:36

good foot in the door and then you can kind of

12:38

make your way from there. So I wouldn't

12:41

discount those beginning

12:43

jobs and sometimes they seem

12:45

a little mundane

12:46

or you know, you're

12:47

not doing all the cool stuff. But it

12:50

matters. It matters in the company

12:52

that you're working in. It matters in the grand

12:54

scheme. So

12:56

if you think of it that way, your

12:58

work matters and it is an integral

13:01

part of what's going on there. And

13:03

you can use that experience to take it wherever you

13:05

decide to go.

13:06

At least that you're on to something, Angela. Maybe

13:09

it's just a matter of reframing the

13:11

situation. I wanted to hear

13:14

from a younger technologist who had

13:16

these experiences and we're

13:18

going to hear from her.

13:24

My name is

13:26

Olivia Fong.

13:27

I'm part of a

13:30

site reliability engineering team in

13:32

Red Hat called Appasari. And

13:34

we manage Red Hat

13:37

services that run on OpenShift

13:39

Dedicated.

13:41

So we were talking

13:43

about reframing the conversation

13:45

around legacy technology. And

13:47

I spoke to Olivia here about

13:50

her experience in academia versus

13:52

her first actual job. As a side

13:55

note, I just want to say we're not related.

13:57

Thanks for clarifying, Kim

13:59

Fong.

13:59

No problem.

14:01

That's

14:03

cool. You get exposed to mostly

14:06

cutting edge technology the newest possible

14:09

and you learn all those theory

14:11

about the process,

14:13

the software engineering process. You got

14:16

the impression that it's all figured out

14:18

and

14:19

kind of perfect in some way.

14:21

But after I joined the industry,

14:23

I

14:24

quickly found out that's not the case.

14:26

How surprising is this? Not at

14:29

all. Not

14:31

at all. This

14:31

is the real world. She

14:36

even uses Red Hat itself as an

14:38

example. Red Hat is special

14:41

in we use Kubernetes or

14:43

OpenShift extensively. Containerization

14:46

is a norm for us.

14:47

But when I just joined the industry,

14:50

I found out that really

14:52

many, many companies doesn't use Kubernetes.

14:55

Their code hasn't been containerized. Even

14:57

though they're thinking about it, they see this whole journey

15:00

as a very

15:01

difficult and lengthy one.

15:03

So I want to ask a question because

15:06

I feel like it's really important. Can

15:09

understanding the why behind

15:13

legacy software legacy

15:15

infrastructure, can it make technologists

15:18

better at their job? Can it make

15:20

them understand customer challenges

15:23

better? What do you think? The

15:25

answer is yes. Does

15:28

it help them understand their customers

15:31

better? Yes. Because

15:33

not every customer you come across is

15:36

going to be cutting edge. They're

15:38

still trying to work out.

15:39

I would say most, right? Yeah. They're

15:41

still trying to work out their app modernization

15:43

formula. It's hard to

15:46

go from the way that you've run your operations

15:49

for a really, really long time and

15:51

refactor and rejigger into something

15:54

totally different. There's this huge chasm

15:57

of education and information

15:59

that that needs to be bridged before

16:02

you can get to the

16:03

Kubernetes and the

16:05

containerized

16:05

applications. And we

16:08

at Red Hat, we get to see that

16:10

our customers sometimes struggle with that.

16:13

You have to understand meet your

16:16

customers where they are. There is

16:18

a pathway, you just have to show them.

16:20

This is how you do it. It's not easy,

16:22

it might not be glamorous, but the

16:24

end result

16:25

is what you're looking for.

16:27

I would also assume, Angela,

16:29

you can tell me if this was correct, but that it's not

16:31

like an on-off switch, you

16:33

know, where it's like,

16:37

you know, you flip a switch and it's like, oh, modern

16:39

architecture, you know, whatever

16:41

it is, it feels like there's probably

16:44

like a relatively slow

16:46

evolution towards more

16:48

modern.

16:51

It is piecemeal and you have

16:53

to inch along. You do

16:56

the low-hanging fruit, you test,

16:58

you see if it works and then you bring

17:00

more and more along. And there's a lot of learning,

17:03

there's a lot of training that has to happen. You

17:05

have to retrain yourself, you have to retrain

17:08

how people think, you have to retrain

17:10

how people do their work because

17:13

moving into, you know, this modern

17:16

application development world might be

17:18

a whole site different

17:19

from what you were used to. You know, if you

17:21

were doing waterfall and it

17:24

took forever for things to

17:26

get upgraded and you're trying to do things, you

17:28

know, with modernized

17:30

application architecture like containerization,

17:33

well, things move so fast, you know,

17:36

the whole pet versus cattle thing. You really

17:38

have to understand that you don't have

17:40

to be wedded to this. It's okay

17:42

to move forward.

17:44

And that is a whole mind shift

17:46

and your organization has to

17:49

be ready for that mind shift, ready for

17:51

that transformation. And it does

17:53

take time.

17:54

This is always something that I've

17:56

wondered about, Angela. Do

17:59

you ever actually...

17:59

get there? Is it the case

18:02

that like maybe the the goal

18:04

post just moves farther out every

18:06

time? It's still moving. Yeah.

18:09

It's still moving but that's okay

18:11

because that's what technology

18:13

does. It's constantly evolving.

18:16

Most of us aren't on the bleeding edge.

18:19

We're just trying to again maintain,

18:21

keep the lights on, do things

18:24

make do with what we have. But

18:27

you're right, the goalposts are constantly

18:29

moving. You just can't lose sight of them.

18:32

Yeah. That's the thing. So

18:34

Olivia understands the challenges

18:37

companies face when updating applications

18:39

to both of your points and

18:42

migrating to platforms as well. She's

18:44

learned this lesson in a very short amount of

18:46

time.

18:48

A lot of software and a lot of applications

18:50

need to be running at

18:51

real time meaning you can't really take

18:54

it offline say a day or two and

18:56

refactor or use a different

18:58

technology to replace it

19:00

which is not realistic. And when

19:02

you think about having to actually

19:05

do a migration instead of shutting it down

19:07

and getting it ready then turn on

19:10

the migration is way more complicated.

19:12

Every

19:13

industry is different, every company is

19:15

different in their journey.

19:17

So

19:20

just like you said it's not just an on and off switch

19:22

Brett. She said it, it's a

19:24

journey.

19:24

And the journey is different

19:26

for everyone. Of course.

19:27

Exactly. How

19:30

do younger IT professionals

19:33

ditch these feelings of being left out

19:35

or being left behind? Maybe

19:38

as what we were saying before it's just

19:40

a matter of reframing the conversation.

19:43

Even though there are new technology

19:46

there are fundamental pieces about

19:48

computer science and networking operating

19:51

system is so fundamental

19:53

it really hasn't been like fundamentally

19:56

changed for a long time. An

19:58

understanding why and

19:59

older solution is in place can

20:02

go a long way. I would say try

20:04

to keep an open mind and be empathetic.

20:07

Because there is always a reason

20:10

for a legacy technology

20:13

or code to exist in the first place.

20:16

Try a little bit to understand the why

20:18

and how it got there. That

20:21

way you learn more than just look at

20:23

it and say this is a way too old way

20:26

to not excited for me to

20:28

learn from.

20:29

Yeah, she nails right. Yeah,

20:31

she does. And I will have to say

20:34

that it's not just young IT

20:36

professionals. It's people who are pivoting

20:38

into our space. Who are

20:41

learning these new technologies and

20:43

maybe they're, you know, whatever sector

20:46

they came from, they're used to using technology

20:48

x. Yeah. And they're coming here and learning

20:50

this new technology y and it's, they

20:53

get their first job and it's like, hey, wait a

20:55

minute, this is

20:56

not what we learned in class.

20:58

So

20:59

we have to understand that sometimes

21:02

you do have to take that step

21:04

back and say not everybody, you

21:06

know, maybe where they worked before they

21:08

were used to using legacy technology. So

21:10

they kind of understood it to a certain

21:13

extent. And you have to bring that with

21:15

you. And there is a level of empathy that

21:17

we all have to have with these organizations that

21:20

they don't want to be here. You know, there

21:22

are a lot of factors. And if we can

21:24

kind of appreciate that this

21:26

is where we are now, we're trying to make

21:28

steps forward. Understanding

21:31

the

21:31

older technology is always

21:33

key. Because

21:34

that is always the foundation for

21:36

what's moving forward. You know, if you

21:39

don't know that you really don't have

21:41

a great grounding in the modern

21:42

stuff. I think it's

21:45

a good point. So I

21:47

wanted to bring this up too, because over

21:49

the course of the series, Johan

21:52

and I have really struggled trying to even

21:54

define what constitutes

21:58

legacy technology. What What

22:00

is it? What counts? What doesn't count? And

22:03

Olivia also has

22:05

this struggle.

22:06

We look at some of the so-called

22:09

legacy technology today. It was

22:11

merely

22:12

released maybe 10 years ago. That

22:15

really isn't long enough to call it legacy.

22:18

Things

22:18

are moving that fast. Yes, they

22:20

are. And it's going to continue

22:23

to multiply. If we

22:25

think about how

22:26

small hard drives were back in the

22:29

60s,

22:29

and we look at where we are in 2023,

22:32

and it's like, wait a minute. That's 4

22:35

terabytes on this little little thing that you can

22:37

stick in the front. So it

22:39

is moving at such an exponential pace

22:41

that just because it's 10 years

22:44

old doesn't necessarily

22:46

make it legacy. It is still functioning

22:49

in spaces. And there's innovation

22:51

happening on these types of platforms as well.

22:54

So age is not the determining

22:56

factor, I will say. And

22:59

no one can predict

23:01

when the new thing becomes

23:03

the old thing. It's

23:06

going to happen though. It will happen. It's

23:08

just a matter of time.

23:11

Even though you might introduce a new

23:13

technology to replace this one, you

23:15

might have to do it again in five years.

23:18

I'm laughing because

23:20

it's true. It

23:22

never stops. Once

23:25

you think you understand that

23:27

you got your hands wrapped around it, something

23:29

else is going to come along. You're just

23:31

going to have to learn the new stuff all over again.

23:34

Even in my spaces where I'm

23:36

working, I'm not specifically working in code, but

23:38

I'm working on these different platforms and tools.

23:41

I feel like every three years, it's like a new

23:43

word comes up and I'm like, huh? What's this?

23:47

I have to learn it. I have to at

23:49

least know about it because people are

23:51

asking about those skills and asking if

23:54

I have those skills. It's not

23:56

just people who are developers and programmers,

23:58

it's also people who use these platforms. for

24:00

other things, you have to at least know

24:02

about it and it could be very overwhelming.

24:09

I want to bring back Bob for some

24:11

parting words. In his

24:14

view, it's important to understand

24:17

that the right tools

24:18

don't last forever. Legacy

24:21

systems are an important part of

24:23

our IT ecosystem

24:26

and we need to think about how they

24:28

can create new opportunities and when the

24:31

time has come for them to be retired,

24:33

we need to retire them and we need to move

24:35

on. The idea would

24:38

be if we really could

24:40

build systems that were, in essence,

24:42

throwaway systems, that

24:45

we could build, they had a very finite

24:47

life, say seven years, ten years,

24:49

and we captured the data and we could

24:52

capture the functionality and AI

24:54

might be able to help us do that, then

24:56

we wouldn't have this issue because we could continually

24:58

refresh them at a economic

25:00

rate.

25:01

Know when to hold them, know when to

25:03

hold them.

25:06

If only you could know though. Yes,

25:09

if only you could know. It's

25:10

not that simple, but he

25:12

has a point.

25:15

It's also important though for

25:18

technologists to have empathy and to form an understanding

25:21

of these

25:23

legacy systems, these languages and

25:26

tools for Olivia. That understanding

25:28

is important to move forward in one's career. When you learn

25:30

to treat some of the process and some of

25:33

the code as a black

25:35

box, you'll find this industry not as mistress and as

25:37

a black box.

25:43

You get to learn a lot more and this

25:46

is really something

25:46

to serve you, to serve

25:49

you your creativity and

25:51

your day-to-day life productivities.

25:54

It doesn't have to be this like intimidating

25:57

thing. It can be for everyone.

25:59

And it is for everyone.

26:09

So

26:10

Kim, Angela, this is the last

26:13

episode of our series

26:16

on legacy technology. I'm

26:18

kind of curious how both

26:21

of you are thinking about legacy

26:23

technology now. Angela,

26:26

do you want to?

26:27

Well, having

26:29

worked with legacy

26:31

technology in the past, I

26:34

have a respect for it. I know

26:36

that you have to understand how it works,

26:39

especially when it's your responsibility

26:42

to make sure that the uptime stays where

26:44

it needs to be because people are utilizing

26:47

these systems. It's important to

26:49

the business. And that is your

26:50

job to understand

26:52

it, make yourself familiar, because

26:54

it is now your responsibility.

26:57

Of course, in that you have

26:59

to figure out, well, how do we modernize

27:02

this? Is there a way to modernize

27:04

it? And sometimes that

27:06

answer is no. Sometimes

27:09

it's maybe, sometimes it's flat

27:11

out, oh, of course we can move forward. But you,

27:14

if it's your responsibility, you have

27:16

to figure out, is it something that we have

27:18

to deal with? If so, how

27:20

do we make it resilient? How

27:22

do we document it so people know what

27:24

to do with it? There's a lot that

27:26

goes into supporting all types of

27:28

systems, but we're specifically talking about

27:31

legacy. You wanna make sure that

27:33

the system is not left behind, that no

27:35

one forgets about it, that it gets

27:37

its update, that it gets attention, that

27:40

people know how to access it and use

27:42

it. And documentation is key.

27:45

Keep it all up here in your head. Don't

27:48

be a living document. Right, don't like some

27:50

people are want to do because they consider that

27:52

to be job security. But

27:54

if that app goes out and you've decided

27:56

to, you know, be this silo of information,

28:00

And now they're not using it anymore than, you know,

28:02

you've probably just made yourself obsolete.

28:05

So automate the things, figure

28:07

out the things, document the things, and

28:09

do your best. I think you're getting familiar with

28:11

legacy

28:12

technology. If it's a

28:14

part of your job, take it seriously. How

28:16

about you, Kim? How are you thinking about this now?

28:18

Well, you know, I

28:20

feel when it comes to legacy

28:23

technology, sometimes it's

28:25

a matter of recognizing

28:27

it and navigating around it. Other

28:30

times it's understanding the past

28:32

while embracing something new, meaningful

28:35

change, just not change

28:37

for change's sake. What's

28:40

important to remember though is that human

28:42

element that all depends on people,

28:45

communicating with each other, sharing their knowledge

28:48

and experience, sometimes through documentation

28:50

with the generations to come and

28:53

embracing both the lessons of old

28:55

and the exciting potential

28:56

of what's next.

29:04

So what did you think about this episode?

29:07

We would love to hear your thoughts. If

29:09

you're catching this in the middle or somewhere,

29:11

go back to the first episode in our series,

29:14

In Defense of Legacy. What

29:16

do you think about the use of technology,

29:19

legacy technology? Just hit

29:21

us up on our socials at Red Hat. Use

29:23

the hashtag compilerpodcast. We'd

29:26

love to hear what you think about it.

29:32

And that does it for this

29:35

episode of Compiler. Today's

29:37

episode was produced by Kim Wong and

29:40

Caroline Preghid. A big

29:42

thank you to our guests, Jim Hall,

29:44

Bob Charette and Olivia Wong.

29:47

For Victoria Lawton's podcasting

29:49

is all about the public good, building

29:51

playlists, sharing memes, things

29:53

like that.

29:54

Our

29:56

audio engineer is Christian Prohomme.

30:00

Thanks to Sean Cole. Our

30:02

theme song was composed by Mary

30:04

Anchetta. Our audio

30:06

team includes Lee Day,

30:08

Stephanie Wonderling, Mike Esser,

30:11

Nick Burns, Aaron Williamson,

30:13

Karen King, Jared Oates, Rachel

30:16

Artell,

30:16

Devon Pope, Matias

30:18

Bández, Mike Compton, Ocean

30:20

Matthews, Paige Johnson, and

30:23

Alex Trebulsing. If you

30:25

liked

30:25

today's episode, please follow the show.

30:28

Like, rate the show, leave us a review, and

30:30

share it with someone you know. It really does

30:32

help us out. Until next time,

30:35

thank you. Bye.