The end of legacy code

Big systems with a lot of code are challenging environments to work in, but the real problems are never the code. It’s the whole constellation of processesses, communication, domain needs, resource constraints, and a host of other big challenges that surface themselves in code we don’t like to work with.

Imagining we’re an explorer, archaeologist, investor, and sherpa can help guide our thoughts to a more positive relationship with challenging systems. If we try to approach legacy code with a fresh perspective, we can find opportunities to smooth out the rough edges and make it easier for other devs, and our future selves to work with. If we don’t, we risk pushing ourselves and the team we’re on into a salty mindset, and towards burnout. By eternally onboarding to a legacy system, we can help take pressure off our code so it’s not responsible for things code is bad at doing.

Resources

• Working Effectively With Legacy Code by Michael Feathers
• Workflows of Refactoring by Martin Fowler
• Theraputic Refactoring by Katrina Owens
• Your Code as a Crime Scene by Adam Tornhill
• This is Day One by Drew Dudley
• Want a bit more of this conversation? Check out the Code and the Coding Coders who Code it episode with Daniel, or many of the other guests!

00:00

(bright music)

00:04

- Good morning. - Good morning.

00:07

- I'm really excited to be in Atlanta.

00:08

How about everybody else?

00:09

Yeah, I've never been before.

00:11

Food's been great, I really enjoyed it.

00:15

I was one of the people that put my hand up

00:16

for my first Rails Conference in person,

00:19

so that's awesome, really excited.

00:22

Thank you all for coming out to talk about

00:24

"The End of Legacy Code."

00:26

I'm Daniel, you can find me on GitHub

00:27

or LinkedIn, same thing.

00:29

My Mastodon is really tiny

00:31

'cause I don't go on there very often, but...

00:37

I'm really excited to talk about legacy code

00:40

and I know that's something that maybe not all of us feel.

00:44

We know it when we see it.

00:46

It feels kind of bad usually.

00:47

So, why do I like to talk about it so much?

00:51

During the day you'll find that I have the job title

00:54

of senior software consultant at Test Double.

00:57

On my LinkedIn you would probably see something

00:59

along the lines of

01:00

"Aspiring Technomancer and Refactoring Enjoyer,"

01:03

which are the things that I spend most of my time

01:05

appreciating in this job.

01:10

What I want you to care about today is that I'm on a mission

01:12

to end legacy code.

01:17

It's a bit of a bold statement.

01:18

What if we could have everything that we worked on

01:21

feel fresh and new and exciting

01:24

as the day that we started our Rails up for the first time,

01:26

brand new Rails up?

01:28

It's probably a little naive to think, right?

01:30

These giant applications

01:31

that are full of convoluted complexity.

01:34

It's really impossible to recapture that fresh tabula rasa,

01:39

blank slate experience, isn't it?

01:43

So, if we're talking about legacy code,

01:45

then I think I probably need to qualify it

01:46

with a definition,

01:47

but before I do, I want you take a look at this phonograph

01:49

for a second.

01:52

What does it make you think of? What does it look like?

01:55

Does anyone have any descriptor words

01:56

they want to shout out at me?

01:58

- Antique. - Antique, yes.

02:00

- Untested. - Untested, there we go.

02:04

- Scratchy. - Scratchy, yeah.

02:06

- Elegant. - Elegant, I like that one.

02:08

That's what it made me think of.

02:10

I hear you, though.

02:10

We see something old and we think scratchy

02:13

or perhaps untested, unvalidated.

02:16

But I like the way that this looks.

02:19

Shiny, fresh, maintained.

02:23

When we talk about legacy code,

02:24

often it's in terms of this code was written

02:27

some length of time ago.

02:30

Implies that we have some sort of older version

02:33

of a language or a framework that we're working with.

02:38

It's an outdated paradigm is kind of the implied idea.

02:43

Sometimes we mean that it's in a disused language.

02:45

These are kind of the descriptors that we assume

02:47

that we're talking about when all of us stand around

02:50

and kind of think about those icky feelings

02:52

about legacy code that we're working with.

02:57

I think there's an interesting problem with legacy code,

02:58

all of us in the Rails community

03:00

have this really exciting opportunity

03:02

where we're working in a framework that has such longevity,

03:07

coming up on its 20th year,

03:09

its second decade of existence.

03:11

There's a lot of legacy code out there.

03:14

There's a lot of things that are built into Rails

03:17

that have gone through those,

03:20

some of those descriptors that I've already used.

03:23

We're lucky to have that longevity and all of us together,

03:25

and there's really exciting and smart people

03:28

working on this application, on this framework,

03:31

building applications together that we get to benefit from.

03:35

So why then does so much of the legacy code that we see

03:39

feel more like this?

03:41

The bed's familiar but it's in a dusty old room,

03:43

there's a shadow underneath there,

03:44

what kind of monsters are lurking in that thing?

03:47

That's the stuff that makes us feel icky.

03:50

So hopefully, after we're done talking,

03:52

we can see that maybe what's under the bed

03:53

isn't necessarily something super scary,

03:55

but a little more friendly,

03:57

something that we can make friends with.

04:01

I think there's another type of legacy code

04:04

that sneaks its way in there when we're talking about it,

04:07

not some number of years ago,

04:09

but other pejorative language that gets wrapped up into it.

04:12

We start with things like, oh, it's tightly coupled

04:14

or it's convoluted, unclear.

04:16

We start using deeper descriptions,

04:18

things that aren't as good.

04:21

(audience laughs)

04:24

I'm just kidding, I really do like React.

04:27

It's not the tools that we're using that are bad.

04:31

There's a lot of Rails stuff

04:32

that is now considered old and broken

04:34

or things that we don't want to utilize anymore.

04:36

Gems get the same tone too.

04:38

The tools aren't bad,

04:39

it's the feelings that are evoked with this,

04:42

and I think what we're really talking about here is

04:46

code that I don't like.

04:50

We don't start there,

04:51

we don't set out to write code we don't like,

04:52

but we've all experienced that,

04:54

it comes out of our fingers and it's something that's not

04:57

up to our standard of what we like to have.

05:00

So what brings us to that point?

05:02

I think there's two emotions

05:05

that really drive this experience.

05:07

The first one's frustration and the second one is fear.

05:19

When we start stumbling into legacy code

05:22

is when we start finding the experiences of hitting our head

05:26

against unclear compositions or inconsistent patterns,

05:30

things that feel really bad,

05:31

violate our understanding of conventions,

05:34

there's convoluted dependencies,

05:37

things like that that as we're exploring code

05:41

we're walking into walls every time we turn a corner.

05:45

Maybe it's untested code,

05:47

maybe it's flaky when there are tests.

05:50

All of that stuff, the more it piles on,

05:52

the worse we feel about the code that we're digging into.

05:56

And then fear happens when that frustration crystallizes.

06:00

We've learned from our mistakes,

06:01

we've been burned a couple too many times,

06:03

it hurts to start looking at this code.

06:07

We start being afraid of change.

06:09

We don't want to be making changes to the application

06:11

'cause it frustrates us.

06:13

We're afraid of new requirements.

06:15

Users want new things or the product team says

06:17

there's some sort of vision that we can incorporate,

06:19

and that gets really scary.

06:22

We're afraid of breaking things in production

06:23

when we try to roll them out.

06:25

We're afraid of holding the hot potato

06:27

when we're on call and having to fix this stuff.

06:30

Maybe we're afraid of more serious things like compliance

06:33

or actual harm to people

06:35

that depend on this tool that we're building

06:39

in really critical parts of their lives.

06:43

The more we get burned, the more afraid we are.

06:47

I think there's a natural tendency

06:49

for us to flip through those pages really quickly.

06:52

We get into this salty mindset

06:54

about things that we're working on.

06:56

I think I've seen this happen in a few different ways

06:59

on some of the teams that I've been able to participate in.

07:02

We start out really high morale,

07:04

we're feeling really good,

07:05

and the first thing we see is like, oh wait, what is that?

07:09

Kind of violates our expectations a little bit.

07:12

The more we trip on that stuff, then we start thinking,

07:14

ooh, okay, it's lumpy over there,

07:17

like we're aware of some of the shape

07:19

of where things don't feel good in the code base.

07:21

Then we start sliding deeper into like,

07:23

what the heck is going on here?

07:26

There's a little bump and there's a real tendency for us

07:29

to want to avoid that stuff.

07:32

If we succumb to that or our team succumb to that pressure

07:36

to say like, hey, this thing is convoluted

07:38

and we don't understand how it works,

07:40

we get a little raise in our morale.

07:42

We can sidestep the problems for a little while,

07:45

feels fresh and new,

07:45

we're kind of capturing that blank slate feeling,

07:48

but really quickly then we start tumbling down

07:51

further and faster.

07:52

We've introduced new harder things to deal with

07:54

alongside the thing we already don't feel good

07:56

about working with.

07:58

We start using things like this code is garbage,

08:01

saying things like this code is garbage.

08:04

We slide further into blaming the people that came before us

08:06

who wrote this stuff.

08:08

Last we get to the disgust phase of

08:12

this code is, I hate this, I hate working on this,

08:15

I hate working here.

08:17

I don't want this job anymore.

08:21

At the end of all of this is this black hole of burnout,

08:24

it sucks us in.

08:27

You don't want to go back once you've hit that point.

08:30

And I think that this isn't just a unique experience.

08:32

All of us kind of go through this on our own,

08:34

but the part of this mindset that we're in

08:37

is going to impact the people that we work with as well a lot.

08:41

The teams that we are on

08:42

start falling down this cascade faster together.

08:47

So I have a little bit of tough news.

08:51

(audience laughs)

08:52

If you are pushing your team further along that decline,

08:57

we're not doing our jobs properly.

09:00

We're not conducting ourselves professionally.

09:03

I think the good news is that

09:07

anybody can help pick the people around them up

09:09

and you might be surprised at how little effort it takes

09:12

to spark something in the people around you

09:14

to overcome those pieces of fear

09:16

or overcome that frustration with the code.

09:22

Healthy teams are able to lift each other up

09:24

to stay at the front of that curve.

09:27

Now I'm from Canada

09:28

so I had to put something Canadian in here.

09:30

Everybody's seen the the Canadian geese

09:33

flying in a triangle.

09:36

They do that to help draft the wind.

09:39

The ones that are rested can fly up front,

09:41

break the wind for everybody else behind.

09:43

So I think

09:45

when we're working with those frustrations and fears,

09:48

it is really normal for us to experience those emotions.

09:52

We're human beings, we can't be robots,

09:54

we're trying to do our best work.

09:57

But we're not always going to be 100% all the time,

10:01

so we need some outlets and we need a bit of support

10:03

while we're going through those challenges.

10:06

At Test Double, we have a couple Slack channels,

10:07

one's called Salt and the other one's called Yelling,

10:10

all caps all the time.

10:12

We can bring those frustrations that we're feeling

10:14

and we can laugh about them a little bit,

10:16

which helps us clear the way then to ask why

10:19

or understand what's going on and dig into the problem.

10:22

So there's an ebb and a flow on teams.

10:24

When you're strong and rested,

10:25

you can take the point on the triangle,

10:28

you can lead the way,

10:29

and when you're tired or overwhelmed, draft a little bit.

10:35

As teams go through this,

10:35

that bond can be really motivating and powerful.

10:38

Overcoming those challenges together

10:40

can be really motivating for everybody on the team,

10:43

and the more that happens,

10:44

the more that cycle goes the other way.

10:46

We slide up the morale,

10:47

we stay at the front end of that curve.

10:52

So, how can we be better developers,

10:54

be really great to work with,

10:56

and be leaders on our team

10:57

where we can take the point on that triangle more often?

11:00

I think this mindset of eternal onboarding

11:03

is something that I've encapsulated

11:05

and I know that some people, though,

11:07

hear the word onboarding, eternally onboarding,

11:10

and that sounds really terrifying.

11:12

To me, I imagine it's sort of like

11:14

if we can keep this rejuvenation piece,

11:16

it's like a desert oasis.

11:18

We're walking through the desert, we're lost.

11:20

We can find a moment in the shade, get a drink of water,

11:23

pick ourselves back up and keep going on our journey.

11:27

Part of this thing when we're working on this legacy code,

11:30

and I say that with the pejorative quotes,

11:33

we have this idea that like if we could go back in time

11:36

with everything that we know now,

11:38

we could probably engineer a better solution, a perfect fit,

11:41

something that would be perfect to work with

11:42

from the beginning,

11:43

and I think that context traps us a little bit

11:46

and we need to flip our thinking.

11:48

If only we could go back

11:49

without anything that we are stuck with knowing,

11:52

getting that fresh blank slate again.

11:55

When we're new,

11:57

or when we're no longer new

11:58

it's hard to remember what that experience is like.

12:01

We underestimate the amount of complexity

12:03

that we're juggling in our brains

12:05

as we're working on these things.

12:06

And when we're too burdened by context,

12:09

it's hard to imagine what is possible.

12:12

We can't unchain ourselves from the thing that exists

12:14

if we're too stuck working with it all the time,

12:16

if it's forefront of mind

12:17

because we're afraid of it all the time.

12:23

How we answer this question, what does this code do,

12:26

is deeply impacted by how much context

12:28

we're bringing to bear.

12:30

So think about the teams that you work on.

12:33

The most veteran person on your team,

12:35

what would they imagine that your code does?

12:37

What does your application do?

12:38

How about somebody that joined your team a week ago,

12:40

what do they think the application does?

12:43

Somebody who left a year ago.

12:45

All of those developers have a probably different idea

12:48

of what the code is doing.

12:50

Taking it outside of the engineering team,

12:51

we've got these supports around the applications we build.

12:55

QA, logging, monitoring,

12:56

those tell us very different stories

12:58

about what our applications are doing.

13:00

Often there's not a lot of overlap between those.

13:03

Add in a third group of sales or product management,

13:08

end users, people actually using our application.

13:10

Is there actually overlap

13:12

between how all of these different people think

13:13

about what our app is doing, all the parts of it?

13:18

You ever been on a team that has 100% overlap

13:20

in understanding of what the application does?

13:23

I mean, I'm not naive,

13:24

I don't think this is actually possible.

13:25

It's probably kind of like shooting for 100% test coverage,

13:28

like questionably valuable.

13:30

I don't think that's actually the goal we want to shoot for,

13:33

but it does give us a bit of a litmus test and understanding

13:36

how do our teams processes,

13:38

how does our team cohesion feel,

13:39

and what are our cultures doing

13:41

that are supporting or failing us

13:42

when we're trying to work with code

13:44

that's frustrating or fearful.

13:47

Ultimately, then, when we are struggling to have

13:51

a cohesive understanding of the system

13:53

and how it all fits together,

13:54

we stumble into this world of legacy code.

13:57

And then the code has to make up

13:58

for those very human failings that we have on our teams.

14:02

Legacy code then has sole responsibility

14:04

for things that code has no right to be involved in.

14:18

Let's go back to our phonograph for a second.

14:22

The descriptions that you all were sharing

14:24

were things like antique and scratchy,

14:26

some of the qualities of the sound.

14:29

That type of quality

14:31

is exactly why people in the music industry

14:33

still utilize old tools like this to sample,

14:38

give flavor to the things that they're working on.

14:40

It informs some of the way that they choose to mix music

14:43

and make it sound,

14:45

to recreate this experience

14:46

of what music through a phonograph sounds like.

14:48

But they don't really rely on it

14:50

to record their entire albums anymore.

14:52

We're not doing a full series recorded on a phonograph.

14:57

But when it's well maintained

14:58

we know that we can just drop a record on there

15:00

and if we know how to put the needle on properly

15:02

we're going to get some cool sounds out of it.

15:05

If the machine's in disrepair, though, falling apart,

15:09

it's hard for us to understand how to work with it

15:11

or it might in fact just be useless to us.

15:15

So legacy code, when it's falling apart that way,

15:18

has to express everything that the app can do

15:20

for our customers,

15:21

has to encapsulate the tens

15:23

or hundreds of thousands of hours of problem solving

15:26

that we've solved edge cases in and express that.

15:30

Legacy code then has to tell us where it's broken

15:33

by itself without any support.

15:37

It has to reveal business goals and objectives,

15:38

what's good for our company and for us.

15:42

Without support it's sure going to show

15:43

where the limitations were

15:45

not in a fun way.

15:46

We have limited resources to invest in anything,

15:49

so of course the code's going to show off

15:51

when it feels bad to work with.

15:54

Code then also has to be expressive of the domain knowledge

15:56

and capture everything we understand

15:57

about the lives that our end user live

15:59

and how they see the world.

16:01

That's not the place for code to do.

16:04

Ultimately it's trying to tell us what's valuable

16:06

and there are people who spend their whole career

16:08

trying to figure out what's valuable

16:09

in the software we're delivering.

16:10

That's not the place for our code to do.

16:12

The most important part is that it has to onboard developers

16:15

into all that other stuff I just said.

16:17

How do we get new people thinking about this problem

16:18

in this way?

16:20

It's not the place for instructions for machines,

16:24

it's a place for humans.

16:27

So, how can we encapsulate ideas

16:31

that bring that stuff back to the human realm,

16:34

back to the work that we're doing as people?

16:36

I think there's a few qualities that we can embody

16:37

that really help with this mindset,

16:40

starting with leading with curiosity.

16:44

When we're coming at it from a point of judgment,

16:47

it's easy to start feeling those frustrations and fears.

16:50

But if we're curious about how did this come to be

16:53

or what were the limitations around it,

16:56

who designed it this way and why,

16:59

those kinds of questions help us

17:01

be a little more explorative.

17:03

We're acting as an explorer, getting a lay of the land,

17:05

the topography around us, seeing some cool stuff sometimes.

17:09

Sometimes the people that designed it

17:12

aren't at the company anymore

17:14

and we're acting more like an archeologist.

17:16

We're digging through our Git history or pull requests,

17:18

trying to put the pieces together from a pile of rubble.

17:21

That can be really hard too.

17:23

Leading with curiosity helps that feel a little more fun.

17:28

Next thing we want to do is pay it forward.

17:30

We want this to be an improving process,

17:32

a self-improving process.

17:34

And so if we can pass that along forward,

17:37

that can be really impactful

17:38

to the people that come after us.

17:40

We don't want to just do this without thought.

17:42

We want to invest in these things

17:44

and we want a return for our investment.

17:46

We want to get stuff back out of the things

17:48

that we're putting into this process.

17:51

The last one that we want to do is put up markers behind us,

17:54

trail mark along the way to where the safety is

17:56

in the oasis,

17:57

make it easier for other people to get there

17:59

without being frustrated.

18:03

In that way we're kind of acting like a sherpa,

18:05

getting everybody up the mountain safely

18:07

with their bodies and minds intact

18:09

and showing the way to some cool sites and visions.

18:15

So, applying this, let's go back to the basics.

18:21

Everybody has to turn on their application.

18:23

It's a beautiful Monday morning today,

18:25

so all of us would likely sit down

18:27

and do something like Bundle Exec Rails S.

18:30

Maybe it's more complicated than that,

18:32

so like kind of close your eyes for a second

18:33

and imagine what it's like sitting down, getting going,

18:36

how does that feel?

18:38

Whatever the start of your workday looks like.

18:41

Next I want you to imagine

18:44

what if I told you over the weekend your laptop died

18:46

and you have to start from scratch.

18:50

Hold your hand up if that feels a little uncomfortable.

18:54

Yeah, okay, yeah, that doesn't feel very good

18:56

when we know a brand new setup

18:58

isn't going to be a great time.

19:00

Maybe there's a lot of volume of services

19:01

that you're putting together

19:02

or there's something like fragile or convoluted dependencies

19:05

that we know that we need to build out.

19:07

Maybe access or secret management,

19:09

there's some other business process that's going to hinder you

19:11

from getting going really quickly.

19:14

Maybe it's just hard to seed your local database.

19:17

There's some sort of really customized local dev set up.

19:20

Maybe it's just a big app.

19:22

All sorts of reasons that things feel bad to turn on.

19:27

It's really gross.

19:31

I'm curious about, though,

19:32

how much of that feels bad because it's stuck in your brain

19:36

or in somebody else's brain and you have to remember it,

19:40

have to come back to it and rediscover all that information

19:43

every time you need to set up your application.

19:45

Like let's get that stuff out of our brains.

19:47

If we at the very foundation start by,

19:50

as I set up my application,

19:51

take a detailed or take a bullet list

19:54

of everything that I've done to turn this thing on,

19:57

I can invest that, pay it forward to somebody else.

20:00

This type of stuff is really easy to overlook.

20:02

We underestimate its value because it's easy,

20:05

like we trust that everybody around us is really intelligent

20:08

and can solve these problems as well.

20:11

If we take the time

20:12

and help make it a little easier for them,

20:15

we're going to avoid kickstarting that salty mindset.

20:17

If your first day at a new company

20:20

is hours of configuration and setup,

20:23

the likely path is that somebody's going to start thinking,

20:26

do I not belong here?

20:27

Like, am I not smart enough for this?

20:30

We don't want to start somebody down

20:31

that path of frustration on day one.

20:34

We also know that it's a good investment

20:36

because you just imagined what happens

20:37

when you get a new laptop,

20:38

you're going to help future you too.

20:41

Like that project setup is ubiquitous,

20:43

everybody has to go through it at some point.

20:48

Okay, onboarding documentation is foundational,

20:51

we can take it a little further.

20:53

It might not surprise you to know

20:54

that given that I work somewhere called Test Double,

20:56

I really enjoy test-driven development.

20:59

I also know that testing sometimes

21:01

is part of our legacy systems

21:02

that don't feel very good to work with,

21:04

and sometimes those tests are doing things

21:06

that code shouldn't do.

21:08

So if you're not familiar with testing, that's okay.

21:11

I'd love to chat with you some more

21:12

after in the hallway track.

21:13

We also have some office hours,

21:14

like a couple doors over from here.

21:17

Happy to pair with you on some early testing exploration

21:20

if that's not familiar to you.

21:21

If it's not, that's okay.

21:24

Don't focus too much on the details

21:26

of what I'm showing here.

21:29

We're looking at Factories as a tool

21:30

for setting up our testing suite

21:32

or doing a brand new application in the documentation.

21:35

Factory Bot shows us, yeah,

21:36

you can maybe have a user in your database,

21:39

might just have a first name and a last name, super easy.

21:41

But over time we start adding new things, our apps evolve,

21:45

maybe we've introduced the idea of a subscription.

21:47

Everyone knows that the Ruby tier subscription

21:49

is the best one.

21:51

The app maybe is an optional subscription,

21:53

you know, users could pay for that or not.

21:55

Further over time

21:57

maybe it starts getting a little bit more convoluted.

21:59

We start introducing things like

22:02

a decorator around the particular user that we're utilizing

22:05

or we move into a change in how

22:10

users are created during the workflow of the application,

22:12

maybe it's no longer linear.

22:14

Maybe it's something like a mandatory subscription

22:16

with like a limited free trial

22:18

and so we're not making users sign up.

22:20

There's all sorts of reasons or product requirements

22:22

that could come in

22:23

that are changing not the necessarily specifics of our code.

22:26

Maybe there's a validation,

22:28

it makes the code wider.

22:29

It doesn't really pass the squint test as much

22:31

when we're starting to see a bunch of indentation

22:33

in our Factory just in our test setup.

22:36

This isn't even for the code itself, right?

22:38

We're adding configuration options maybe into our factories.

22:41

It doesn't feel good if the code,

22:43

if our test code is the only thing that is now capturing

22:47

how do users get subscriptions

22:49

or how do subscriptions get attached to users.

22:52

There's some depth there.

22:54

Me as a new developer comes onto the team

22:57

making some assumptions about users

22:59

and how they're getting subscriptions on it,

23:01

maybe my first task is to fix a bug,

23:03

first thing I'm going to do is try to set up

23:05

my test environment and pair those things together,

23:07

and I don't know if you've worked with,

23:10

if anyone else has seen this error.

23:13

When you're focusing on other problems,

23:15

it's really easy to stumble into some obvious traps

23:18

when there's underlying complexity that we want to address.

23:22

So why don't we move past that?

23:23

How do we know what's worth digging into, making easier?

23:29

Let's think about those roles that we can take on.

23:31

As we're exploring and putting the pieces together,

23:34

who do we know on the team that understands how this works?

23:38

Why isn't it clear or documented?

23:40

Maybe there's a whole team in our company

23:41

that's responsible for managing subscriptions,

23:44

like let's go chat with them

23:45

and make it so that their knowledge can be spread around

23:47

to the other teams at our company a little better.

23:50

Or maybe all those folks are gone

23:52

so we have to do some more work

23:53

digging into those pull requests,

23:54

maybe some old Jira cards or something like that

23:56

can tell us the story of where did subscriptions come from,

23:59

why do they look like this,

24:01

and that might help us come to a point

24:02

where we can understand the problem a bit more,

24:04

in a bit more nuanced kind of way.

24:07

Then we can think about this more like that investor piece.

24:10

If subscriptions are fundamental to your business model

24:12

and that is a huge part of your revenue,

24:15

then that should enable us to say,

24:18

okay, let's go deep and understand

24:20

why this is a bit of a convoluted pairing.

24:22

Let's maybe even throw out the whole thing

24:24

and start from scratch

24:26

or increment it over time into something

24:28

that is a much more robust pairing

24:29

between those users and their subscriptions.

24:33

Maybe it's only like two users

24:34

that have paid for a subscription ever

24:36

and we can just say let's just throw all this code away

24:38

and just move on to something more valuable.

24:40

We want to get that payback

24:41

for what we're investing into it.

24:42

We don't know that without some of that exploration.

24:46

Last one being sherpa,

24:49

if we come across this and it's something

24:50

that isn't that valuable

24:51

but it's, you know, we want to keep it around,

24:53

add some documentation, get that stuff out of your brain,

24:57

the stuff you discovered, put up those markers behind you

24:59

so whoever then has to come fix the next bug

25:01

without changing the whole thing

25:03

has a bit of an easier time

25:04

sidestepping those frustrations that you felt

25:06

and aren't falling for the obvious errors

25:08

that make them feel like they're not

25:09

a really good developer.

25:12

Depending on our context, that exploration,

25:14

we're going to be asking very different questions

25:16

to different people at our company.

25:17

We're going to cross thresholds

25:19

or get out of our own little box that we're working in.

25:23

It can also really help us reveal the gaps and processes,

25:26

get us figuring out where there's flaws

25:29

in how we work together as teams and as people.

25:35

I think when engineers get left on their own

25:38

or there's unwieldy and obscure systems,

25:42

there comes this point where we can start

25:43

letting legacy code drive us around, make decisions for us,

25:46

take over product cycles

25:49

lost to legacy code spilling beyond its boundaries

25:51

and doing things that it has no responsibility doing.

25:55

We're kind of focused on that relentless tinkering

25:57

when we're left to our own,

25:58

which is good, that's a good quality,

25:59

that's what makes us good at solving problems

26:01

and overcoming those challenges here.

26:05

But sometimes it also devolves into playing code golf

26:07

and bike shedding on things that feel fun to work in

26:10

but aren't solving those really valuable or deep problems.

26:13

I think conversely also there's sort of this

26:15

perfection paralysis piece

26:16

where we're trying to keep all the context in our brain

26:19

all of the time,

26:20

design the perfect implementation at all times,

26:23

and that stops us from making forward progress,

26:26

making that forward momentum.

26:28

It keeps us tied to the context that we live with.

26:31

So, as we discover these things,

26:36

how can we start picking up people around us

26:37

so that it's not just a tiny oasis in the desert

26:39

but a full-fledged jungle?

26:41

There's a whole lot of things that teams do

26:43

to help each other draft and take point.

26:45

These mindset pieces can help drive us there,

26:48

but as we're going further, we can do things like pairing.

26:51

If you've never paired with people before at your job,

26:53

it's awesome and you should totally do it,

26:56

especially when you're coming across

26:57

a whole part of the system you've never seen before.

27:00

You should also, if you're in a position,

27:02

encourage everybody else around you

27:03

to like reach out across teams

27:05

and share that knowledge across boundaries

27:08

in your organization,

27:09

share that knowledge amongst the crowd.

27:12

Go deeper into the tools that you have,

27:13

your Git history, your PRs.

27:15

Get better at writing them.

27:16

Pull requests aren't for us today

27:18

for the review that you're doing now,

27:20

it's for me in, you know, 10 years

27:22

when I come across this problem later

27:24

and need to go further

27:25

through that archeology and that history.

27:28

Those team rituals that we can do can also really help this,

27:31

retrospectives and having everybody involved

27:34

in that backlog process.

27:35

Get everybody involved in those things

27:36

and understand how those work.

27:38

I'm not going to, I don't have time to tell you

27:39

about like how to do all that stuff really well.

27:41

You all are really smart and can do those yourself,

27:43

but don't underestimate the value of those social strengths

27:46

and those bonds that come

27:47

from building those processes better

27:49

and overcoming that frustration together as a team.

27:52

Really what we want to do is go boldly

27:53

into parts of the code that we're unfamiliar with.

27:59

Enabling teams to stay out of that black hole of burnout

28:01

lets us chart our own destiny,

28:04

change course, go different ways.

28:05

We're trying to enable change in our application.

28:08

Coming at it with exploration and paying it forward,

28:12

putting up trail markers

28:13

is going to help take pressure off the code

28:15

so that it doesn't have to do all that stuff

28:17

that code just isn't good at doing.

28:20

Got to get that knowledge out of our brains,

28:22

track it somewhere else,

28:24

spread it across multiple people.

28:27

It really is going to help prepare us for the marathon

28:29

that is working with old big systems

28:32

that are convoluted and complex.

28:34

All of us know that it's hard and it's a long journey.

28:38

There's more and more Rails applications

28:39

that are moving beyond a decade of their life,

28:41

which means there's also a lot

28:42

of really important work to do

28:44

to make sure that they are a polished, shiny phonograph

28:47

and not a piece of junk that's thrown out back.

28:50

We want to maintain them and keep them going,

28:52

bring them back from the brink.

28:54

So if you're struggling somewhere on this decline,

28:57

I'd love to chat with you.

28:58

Feel free to come talk to me after,

29:00

connect with me on LinkedIn or Slack or somewhere.

29:02

We'll chat about it, I'm really excited.

29:04

If you and your whole team is really struggling with this,

29:07

Test Double can support.

29:09

Feel free to reach out.

29:10

I'll share these slides as well in the Slack.

29:12

There's some stuff that really influences me

29:14

and drove some of this conference talk.

29:17

And the last thing that I'll say also

29:20

is that not everything is about technology.

29:23

So if you're really interested

29:24

in conversations like this one,

29:26

putting the people first,

29:27

and are interested in finding

29:28

more of a community around that,

29:30

some folks at Test Double are also really interested

29:33

in having those kinds of conversations.

29:36

Hopefully over time all of us

29:38

can continue building applications

29:40

and maintaining our Rails applications in a way

29:42

that we can get rid of that legacy code that feels bad

29:45

and just enjoy all the time going forward together.

29:50

Thank you so much.

29:52

(audience applauds)

30:01

I think I have like a minute for questions

30:03

if anyone, or comments.

30:06

For sure, what motivated me to,

30:08

or what was a specific motivator for giving this talk?

30:12

I don't have like a CompSci degree,

30:16

I came from a communications background.

30:18

Maybe that's why I'm a consultant.

30:21

And when I was in my, I did a bootcamp,

30:24

and I was super in love with like the trendy new

30:27

fresh JavaScript framework of the day,

30:30

and hence my like pot shots at React,

30:32

which I do love genuinely.

30:34

My first like real job after was at a consulting company

30:40

and we were helping maintain a system

30:41

for an arts organization, a not-for-profit.

30:45

It was a 14-year-old Rails application

30:47

with a two-year-old React front end,

30:50

and it was overwhelming.

30:53

As a junior that had come out of a bootcamp,

30:55

I felt totally unprepared in every way

30:58

for diving deep into that application.

31:00

And these are the things that helped me

31:03

get better at working in that big monstrosity,

31:07

but also made it easier for everybody else around me

31:09

to work on.

31:10

It helped me step up and find that comradery

31:14

in the frustration

31:16

and overcome those pieces with the people around me.

31:19

And it didn't take that much, surprisingly,

31:21

to get people thinking a different way

31:23

and feeling less frustrated

31:24

about all these roadblocks that we were hitting,

31:26

and we could have a good laugh about it

31:29

and have a coffee and then think, hey,

31:30

remember that time that this thing happened

31:32

and it blew up in production?

31:33

It was great.

31:34

Thank you, yeah.

31:36

Oh interesting, yeah.

31:37

The question is, how do you go from necessarily

31:40

like a git blame to finding the pull request

31:42

that it's attached to

31:43

or tapping into those other parts of the history with it?

31:47

I lean on JetBrains IDEs a lot,

31:50

which helps pull some of those pieces out for you.

31:54

Looking through our GitHub history

31:57

or whatever your repository place is,

32:01

it's sometimes really hard.

32:04

Like if there's not been a great process

32:06

at different organizations

32:07

about tying specific pull requests

32:09

to pieces of functionality,

32:10

we can get lost a little bit.

32:14

So I know that what I lean on is a pay tool

32:17

and not everybody wants to do that.

32:18

Maybe we can chat about it some more after, yeah.

32:23

Sure, so if I understand your question,

32:25

how do we know when we come across this legacy code

32:28

that feels bad and we're trying to get rid of it,

32:31

when do we just take some time

32:33

in the work that we're doing now,

32:34

do some refactoring up front,

32:36

versus when do we say, whoa, hit the brakes,

32:37

we need to spend some time together as a team

32:39

or like take a bigger initiative on this?

32:41

(audience member talking indistinctly)

32:45

Yeah, so I think the first one is thinking

32:48

about that investment.

32:49

Is this something that's actually valuable

32:50

in the whole application?

32:52

Is it central to everything that we're working on?

32:54

Is it enabling a whole lot of other work

32:56

at our organization?

32:57

If that's the case and it's super broken,

33:00

then maybe there's room for us to step up with our team

33:05

and say like, hey, this is a real problem,

33:07

all of us are hitting it,

33:08

maybe that's time for a retro or something like that

33:10

where we can sit down and chunk down the problem together.

33:13

Who else is experiencing this?

33:15

Who else is hitting this brick wall?

33:18

And digging deeper into the underlying problem.

33:21

Is this the problem?

33:22

Is the model, is it the pieces around it,

33:24

is there some architecture challenges?

33:26

That's where we can find if it, like,

33:28

when we know it's really valuable to the application,

33:30

that's when we really want to go deep

33:32

versus when it just kind of feels bad

33:36

'cause you stubbed your toe on it

33:37

but it's kind of a corner in the application

33:40

or like your git blame on it is like

33:42

somebody hasn't changed this code for four years or longer.

33:45

The age varies, don't take that number

33:48

as a fact or anything.

33:49

But if we're looking at the Git history

33:52

and it hasn't been touched in ages and it mostly works,

33:55

then you probably just want to like focus on, okay,

33:58

how do I like put on the blinders a little bit

34:00

and ignore all of the the garbage in this room

34:03

and just like get that thing done?

34:05

So it's really a nuance thing, right?

34:07

Like an intuition piece.

34:08

It's a good question though.

34:09

I'd love to chat more about it later.

34:12

At the back.

34:13

(audience member talking indistinctly)

34:14

That's true, yeah, okay, so if I understand,

34:17

when we're talking about getting things out of our brain,

34:20

that can be a really complicated process

34:21

because every team has different tools

34:24

or different places that we're storing information.

34:27

When we shove something into Notion,

34:29

it's really easy for it to disappear forever

34:31

and it does that on any tool that you utilize.

34:33

So the most important part is like,

34:34

where does your team already, where are you at now?

34:37

How does that information circulate today?

34:41

That's a good place to start.

34:42

There's I don't think a solid, fast and true answer

34:45

that I'm going to stand and say, like,

34:46

yeah, every team needs to use Notion and use it in this way.

34:50

It's a great tool if you understand

34:52

the ways that the people around you are already working,

34:56

and tapping into that kind of natural dynamic

34:58

is a great starting point.

35:00

Then we can start saying

35:01

we understand how this team is communicating and functions,

35:05

let's start making meaningful adjustments or tweaks

35:08

or moving us closer to a direction

35:11

where that information's discoverable.

35:15

So we tell all of our different clients

35:17

very different things depending on what they have going on,

35:20

meeting your team where it's at.

35:23

Internally, we just did a whole thing

35:24

around info discoverability

35:26

and making all of our own stuff come out,

35:29

and it's really reflective of our business model

35:32

and our internal team structure.

35:34

So that's I think the piece where we need our documentation

35:37

and the stuff that we're offloading out of our brains

35:40

needs to really match the culture

35:43

of the organization that we're in

35:44

and be intuitive along those lines.

35:47

So that's not an easy answer, right?

35:50

Yeah. Hey.

35:53

(audience member talking indistinctly)

35:54

- You nailed it right at the end.

35:56

So the question's about how do we

35:59

as junior or early career developers

36:03

feel emboldened and confident

36:04

in stepping outside of looking at the code as it is,

36:07

kind of staying in our lane, so to speak,

36:09

and reaching out to get deeper understanding or support

36:12

or putting our opinions out there?

36:16

Am I understanding? Yeah, okay.

36:18

So at the end you said...

36:22

Sorry, how did you phrase it at the end?

36:24

(audience member talking indistinctly)

36:26

- Okay, so there's a bit of of a starstruck piece

36:30

when you're an early creative

36:31

who's like working with somebody you really respect.

36:33

You're like, oh, they're so smart, they know everything,

36:36

which just is never the case.

36:39

They're going to have blind spots too.

36:40

So I think knowing that

36:43

everybody has to go through this process

36:44

of like when we're working in a big system

36:47

discovering pain points, things that feel bad,

36:50

and then tripping on them and learning from them,

36:52

and senior developers have just tripped

36:54

on more things than us on a project.

36:56

So when those seniors are really good

36:59

about distributing that knowledge

37:01

or putting up the sign markers behind them,

37:04

they can be really approachable.

37:06

And I love sharing code that I have done

37:12

or solutions that I've implemented

37:14

with anybody who's curious about it,

37:16

in part because if I can explain it or teach it in a way,

37:21

then my own understanding is more solid.

37:23

If I can communicate that idea,

37:25

it validates that somebody else can come

37:27

and work through this code and understand it.

37:30

And if they can't,

37:31

then there's a problem with what I've done

37:33

and it's not clear,

37:34

we need to improve that piece of it.

37:36

So I think there's some bravery that it takes

37:39

as an early career dev to jump out of the safety box

37:43

of where you feel confident and secure,

37:47

and the more you can encourage yourself to do that,

37:51

the stronger and faster you're going to get outside of that

37:54

and be more confident

37:55

diving into things that are unfamiliar.

37:59

Yeah, I want to say more about that

38:01

but I'm probably out of time.

38:04

Yeah, thank you all so much,

38:05

I'm looking forward to chatting with all of you.

38:07

I'm now not nervous 'cause my talk is over,

38:08

so I'll be super chill the rest of the conference

38:11

and I'm looking forward to our conversation.

38:12

Thank you all so much. (audience applauds)