The end of legacy code

[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)