Scary Code

About this Episode

In this episode of the Acima Development Podcast, the panelists join forces and discuss the things that scare them in code and how to avoid these pitfalls. Mike begins by recounting his experience with a fast-growing startup that used a poorly managed customer management system. This system lacked version control, searchability, and a test environment, which forced developers to tweak code in production. Additionally, Mike shares another experience with a codebase riddled with security vulnerabilities, illustrating the dangers of inheriting poorly written third-party code.

Will adds to the discussion by highlighting the broader organizational issues that can lead to scary situations in coding. He emphasizes the importance of maintaining a strong chain of trust within a distributed workforce and ensuring diligent code reviews. Will warns that when organizational control breaks down, it becomes a significant concern, especially with large volumes of foreign code entering the system. He argues that fostering a sense of ownership and responsibility among team members is crucial for maintaining code quality and preventing issues.

The conversation then shifts to strategies for cultivating ownership and responsibility in coding teams. Mike and Will discuss the importance of giving developers genuine control over their work to foster investment and care. They touch on the challenges of balancing team freedom with organizational needs, noting that allowing developers to make decisions, even if it means making mistakes, can lead to better long-term outcomes. Eddy also emphasizes the value of training and mentoring junior developers to ensure consistent code quality and adherence to best practices.

Transcript:

 MIKE: Hello, and welcome to another episode of the Acima Development Podcast. I'm Mike. I am hosting again today. With me today, I have Eddy and Will. There's a chance we may have some additional folks coming and going. We're kind of in an influx today [laughs], but we're going to start here. I am excited about what we're talking about today because I think it'll be fun.

And I'll just lead with the topic. We're going to talk about things that scare us in code. And how do we avoid having some of those things happen? Because I'm hosting, I get to start with some stories [laughs], and I'm going to start with stories that are long enough ago that the victims are not obvious [laughs]. And the companies are likely, well, more than likely; the companies are out of business, so we don't have to [laughs] be too sensitive about it.

There's one example I think illustrates kind of everything, maybe not everything, but many of the things that scared me about code. I worked at this place early in my career, a fast-growing startup, really fast-growing startup. They were growing like crazy, and they needed to have a customer management system to manage all of the new customers they had. And somebody knew a guy who [laughs] had built something, and they paid for it, and we got it.

And this system consisted of a Microsoft SQL Server having a whole bunch of custom extensions added to it and a whole bunch of queries so that the entire system ran inside of the Microsoft SQL Server. And some of the components they called out to were compiled code for which we didn't have the source code. And the areas for which we did have the source code, that source code was just stored procedures inside the database, and that's where most of the code was.

Some things about that. There was absolutely no version control [laughs], which means any code there is, the only chance you have to do anything about it is to tweak it in production because there was no test system. There's only the production system, and there's no code repository. There is only the production system. If you want to change something, you go change that stored procedure live and hope for the best. And [laughs] further, because it's just stored in the database, all you have is those stored procedures, and you want to find anything, there's no search system. You just have to try to figure it out. And they referenced each other all over the place. So [laughs], you had to go find them.

And sometimes you drilled all the way down, and you found a compiled component for which we didn't have a source code, and you just hoped it did the right thing [laughs]. Maybe it was sending out emails. Who knows what it was doing? You didn't have access to it anyway. And we used that thing for years. Oh, that was an interesting piece of software. I ended up making a number of changes in there that we needed. But I could go on. I'll mention some of those key characteristics again. No version control. No searchability. No test system. You can only test it in production. And it came from a third party. It came from a third party. The development team didn't have any choice over it.

At that same company, we inherited a codebase. Our company decided to bring it on to try to bring in some customers. And I didn't know about this codebase ahead of time, and none of us did. But apparently, they had some security holes before we acquired it that were actively being exploited. At least there was something like version control in this system. However, this was their SQL injection. They were handcrafting all of their queries. In this case, they hadn't sanitized their SQL. And this was in processing financial data. And they'd already lost, I think, over a million dollars before we found the hole. You imagine that didn't go over very well [laughs], especially this small startup. And probably led to the demise of the company shortly thereafter.

Some things in common between those. Notice the third party. Developers having no access until afterwards, so inheriting a codebase. And a lot of times, you don't acquire code from a third party, but it's handed off, and you don't have the insight, and lack of adherence to anything like best practices and difficulty in searchability. There's a couple of worse stories [laughs], but they also illustrate a lot of the things that I think are worst in code, scariest in the code, which are stuff that I don't understand, and I have to go dig in because I'm inheriting it, and I have to go figure it out.

Poor adherence to good practices [laughs]. Lack of searchability. Lack of test environment. Man, all of those are horrible. And both of those projects kind of checked all of the boxes. And I could go on, but I'm going to give you all a chance. Will, you've been around in this industry for a while. You've probably got your own stories. What have you seen that scares you in the code, and what have you learned from it?

WILL: If I'm talking about things that scare me, it really honestly goes [inaudible 05:11] time. I can remember the time where I deleted the prod database or the various things I screwed up. But really, they all had this one centralized theme, I think, which is when sort of organizational control kind of breaks down. That's really the thing that concerns me the most with sort of bigger organizations, like if you're an organization where they're really pushing sort of a distributed outsourced workforce, right? Like, I might be experiencing some of that right now. And there is...a lot of people have, like [inaudible], is minding the store.

Code reviews are really, really difficult. And it is still very difficult to find people who are diligent in their code reviews and making sure that people are really looking after stuff. And that's when things start to go bad, especially when you get this sort of injections of a large volume of foreign code into your organization, your distributed system. So, that's really what keeps me up at night, where it's like, people are checking things into production. People are checking things into the app all the time. Who is minding the store?

And it becomes, you know, past a certain point, you're doing a trust fall by necessity. You physically cannot manage all of the code. You can't do it. It cannot be done by any single person. And so, you're just sort of...you trust the people and that sort of chain of trust is a very fragile thing and shockingly easy to break down.

MIKE: Yeah, I think my experience is totally --

WILL: It's just sort of like this organizational chain of trust.

MIKE: Yeah, I was just saying my experience is totally consistent with yours. And [laughs] the way you say that organization breaking down, and it doesn't have to be inheriting a bunch of that outside code, like you say. You can have just something as simple as a change in organizational structure so that you don't have the same team cohesion that you had previously. And say the people watching the store were out taking care of something else; stuff starts to fall apart.

WILL: Let's talk about this. Let's talk about maintaining that chain of trust and how do you do it. Because I'd say the best model maybe that I've seen that is scalable, not without faults but scalable and practical is, you know, each sort of section of the code, you know, major subsystems are owned by a team. And they have a watchdog who is responsible and proactive enough to keep this subsystem under their thumb. And I don't know if I have a better working model, really.

MIKE: Well, that watchdog you talk about, I feel like if somebody feels like they own it, that is [laughs] not told that they own it, but genuinely has some opportunity to get invested in something, it makes a huge difference. I know when I build something, I care about it, even if it's something, you know, that's not that important. If you make a pile of rocks, you can get a little fond of that pile of rocks because [laughs] I built that. That act of creation binds you to it.

I think that some of that applies in our jobs as well; if we feel we had say in what we're building, feel because we actually did. I'm trying to make the distinction here. Because you can have kind of faux control where somebody says, "Yeah, you own this. You're on call tonight." But you don't get to make any of the decisions. Well, you don't really have control. You have responsibility without control in that case.

And that's where I think is kind of an anti-pattern because if you have the responsibility without any control, it just burns you out because you're disempowered. On the flip side, if somebody gets to actually make decisions, creative decisions of what they're doing because, you know, they own it, they get to make those decisions, then they become much more invested. You know, it sounds like I'm talking about a trick like, here's how you get your team invested. Rather, I'm saying you've got to surrender some control.

You've got to, as leadership, be willing to say, "I don't get to call all the shots here because I'm not close enough to be able to make the good decisions." And if you're making those decisions, you may make the wrong ones. And there's always cases like this where there's more art than science, where it could go either way. If you don't have enough trust in your team to make their own decision, then you're seizing that ownership for yourself for no gain. It's just hogging the ball, right [laughs], and not letting anybody else play. And that, I think, really poisons things. I think that in order to get the ownership that Will was talking about, to have somebody really claim the code and be willing to care enough about it, they have to actually have it genuinely be theirs.

EDDY: There's a few key things that both of you said that I kind of want to elaborate a little bit on. And losing control of the codebase is a little interesting because if the staff is trained right with the expected conventions and what we have planted for team rules and such, that can be mitigated. But also, there was a joke that was said [chuckles] a few weeks ago. I'm not going to name-drop the person just because he's not here.

But it basically said, I'm paraphrasing, but it basically said, as a senior developer, if you take a junior developer under your wing and cultivate their decision making, you can then, at that point, have a proxy battle from them in your behalf in order to enforce some of those decisions that you want. It's kind of funny. But the more that I've adapted to that ideology, I've found myself also enforcing some of the ideologies from my peers, which is another benefit, I guess, to that fear.

MIKE: You know, a few hundred years ago, for any skilled trade, maybe not any, but a large number of skilled trades, people learned the trade by apprenticing with a master in the field. And, to your point, one of the best ways to learn something is to watch somebody else do it and you apprentice with somebody. Well, and you can see this in the works of, say, artists, where artists who apprenticed with the master end up having work that looks very similar. Of course, they diverge in their own way, but the apprentice does tend to follow the master. And I don't think that we should shy away from that.

Certainly, people are going to diverge and go their own direction. But there's real value in not having to make some of the hard decisions yourself when you're getting started. And you're going to rely on the expertise of the master while you're still learning. That's what kids do with parents. And, of course, parents sometimes get it wrong. And a lot of times, you know, the basics of adulting [laughs], you're going to pick up by watching. And they're probably going to have at least somewhat right, and you're going to pick up on that and learn the things to do. That's how we learn as humans. We learn from more experienced members of the tribe and don't have to make the decisions: hey, should I eat this berry? Is this going to kill me? And look [laughs] to somebody else who might know that answer already.

And so, you know, I think that it's worth leaning in, leaning in there. And if you are a leader, it's okay to tell people, "Hey, that berry, I saw that make somebody really sick the other day," or maybe "20 years ago. I've been doing it for a while. And I don't want that to happen to you all, so don't eat those berries. There's a reason we don't eat those berries." Maybe there's a reason we don't test in production. And follow the best practices of setting up a test environment, setting up a staging environment that you can test in so that you can test things. And put a lot of investment into that so that you can do solid testing before you get to production. You're not going to get poisoned that way, in the way that you would if you go straight out...

EDDY: I want to say that it's kind of funny because you say if you've lived that pain, you're saying, "Don't eat it. It's bad for you." But sometimes, your body acclimates to that substance that you're eating, right? And then, you just don't notice that it just tastes awful. And that's kind of just what happens in code. It's like, you might be doing a bad practice, but you're just so used to doing it. Your body just got so used to doing that that you just don't realize, you know, that it's bad [laughs] until you have someone else who's trying it for the first time, and they're like, "Oh, dude, this is pretty gross, dude."

MIKE: [laughs] Yeah, it's true.

WILL: There's a lot of things that were, you know, they were good until they were bad, or even worse, more commonly, they were relatively benign diseases. They weren't going to kill you until you got to a particular stage. I've done all kinds of things in a small team, small, high velocity, tightly integrated team, but we're fine. They were all fine. But on a more, call it, enterprise scale, you know, organization, they would kill you dead as fried chicken. So, it's not a cut-and-dry thing. The argument would be that for those small, high-velocity teams, if you're not moving fast, if you're not cutting corners, you're not going to make it to enterprise scale where you can go so slow.

MIKE: That's a really interesting point. You can get away with a lot of stuff when it's just yourself. You can get away with a lot of stuff.

WILL: And you have to. Let's talk about the things that are going to kill you when it's just you out there on a wing and a prayer. Like, you need to ship, and you need to ship today. And like, oh, you don't know how to do that? Well then, you're just going to do the best you can. Overwhelmingly, the thing that is going to kill you is running out of time or money, right? Like, 10 [inaudible], if not higher. And so, it's like, oh, security is not so tight here, and I'm like, no, it's not [laughs], you know? It's not.

EDDY: There's an estimation of good time for half a day. So, you need prep time to get there. But sometimes the party is in the next hour, right?

MIKE: [laughs].

EDDY: So, you're like, well, dang [laughs]. Well, I guess I'll just put in an extra cook to turn on the heat a little bit, you know, get it done in an hour, and hope that it tastes the same.

WILL: Exactly. I mean, being worth robbing, you know, by cybercriminals, being considered worthy of being a ransomware target is, you know, that's first world problems, baby. You made it [laughs]. It's like getting sued by a patent control. Like, hey, there you go, like a disturbing truism that, like, a rite of passage to be like, oh, I've got an actual business now. I'm actually a businessman now, is getting sued for the first time. Your first legal letter where somebody tries to shake you down. It's like, oh, you made it, baby. There you go. Look at us now.

MIKE: [laughs]

WILL: I'm worth robbing.

MIKE: So, we're digging into this idea that the consistency that is absolutely critical for managing a larger organization can be less so when you're working with a smaller organization because your circle of trust with a smaller organization is so easy to maintain. You all know where things are bad when you've got the small team. I'll say, "Oh yeah, there's that bad thing. We all know it's terrible. Don't step there."

But as you grow, that shared knowledge becomes harder and harder to maintain, and it becomes more and more important to have standardized practices, standardized ways of sharing information, ways to replace people when they move on or, you know, otherwise removed from the organization. And that's a challenge as you grow, and it's going to chafe a little bit. And you're going to be like, "Hey, I miss my freedom to do whatever I wanted." And to have the maturity [chuckles] to say, "You know what? I need to change. I need to change what I'm doing, or else I'm going to cause harm because being a cowboy is not going to work anymore."

EDDY: There was an off comment, you know, that was kind of relevant to what you're saying but I kind of want to expand on a little bit. It was, you can tell someone the direction and tell them, "Hey, don't step there, right? There's a trap door. You're going to fall." But what do you do in the instance when you tell someone, "Don't step there." And they respond with, "Oh, it's okay. I can fly," right? Like, what do you do [chuckles] in that circumstance? You're like, "No, dude, you can't fly. I've been there." And they're like, "Oh, no, no, it's fine. I'll be fine." Like, what do you do? How do you keep quality when the individual believes that they're not affected?

WILL: It depends on the blast radius of the problem. I am a believer in sort of you break it, you bought it. If somebody is willing to say like, "I want to do this thing. This is my thing. I will take ownership of it," and the blast radii is small enough so that if it goes bad, then...you know what I mean? Like, it is a human-sized error with a human-sized sort of level of consequences, and somebody comes to me and says, like, "No, I'm going to do it my way," I'm like, "Okay, do it your way," you know? I believe in sort of agency like that. You have to be mindful because, a lot of times, things can be slow-growing systemic problems. Make a judgment call whether you can afford to let somebody go and try it their way.

In my estimation, the way I make those decisions is, is it a really big deal for you, and can you shoulder the consequences of it yourself? And so, if it's a manager, it's like, okay, the manager's team can shoulder it. If it's an individual developer, then the individual developer can shoulder the consequences thereof. I don't know. If I can say "Yes," then I will, honestly, because that's how people learn. And if I can, I try to explain why. Or I'll come up with a sort of rubric to be like, "Okay, try it your way, and these are the conditions under which I will say, you were right, and I was wrong. These are the conditions under which I will say, ah, you know, I mean, this is just tomato, tomahto. Both are, you know, more or less equivalent. And these are the conditions under which, like, can we all agree that I was right and just do it my way now, you know?"

EDDY: I agree. You're like, at what point does it start tasting bad? If you're saying add more sugar but without the added sugar it still tastes okay and you're okay with the taste, you're like, "Yeah, yeah, it's fine. It still tastes all right."

MIKE: [laughs] It goes back to --

WILL: And I'll say there's a lot of stuff out there. The overwhelming majority of decisions fall into that, I would say, broadly, you know, that tomato, tomahto kind of a situation. It's very rare that you'll have a black-and-white this is wrong scenario.

MIKE: I was going to say that goes back to the ownership discussion that we were having before. If you don't give the team...so this is opinion of me, but I think it's right [laughs]. If you don't give people ownership, then they won't have any reason to take responsibility, and you get ownership by making those choices. You're committed now. You've made the choice. You see how it works, and now you care how it turns out. And, yeah, maybe you've made the wrong choice, and you learn from it. Maybe you make the right choice, and now you've got something defensible, and you'll care about that the next time.

Giving people that chance, you know, the tomato tomahto chance to do it their own way, it may sound superficially important, but I think that it's actually critical for giving your team the opportunity to actually make consistently good code. Because if you take away that control, well, then nobody cares. I don't want to say it's like slavery because you can leave the job [chuckles]. But if you don't have any agency in it, then you just don't care.

EDDY: Well, and I think what's more important is if you have a new cook in the kitchen and you're constantly holding their hand, they're not really going to learn anything. However, if they end up burning the kitchen, they are going to remember. And they're going to be like, "Dang, I had to clean all this up. And all this mess, I had to clean it up." But then, guess what? The odds of them burning the kitchen again for the same recipe probably isn't going to happen anymore. So, I think there is some benefit to putting trust in your cooks.

MIKE: I was building on what you said before, where you have to have that watchdog that keeps going. And the way I say you develop that, I think you're right that you need to have somebody who cares enough to keep people in line. And I think you only get that, and this is why I've been talking about the ownership: if that watchdog actually feels like they own the code, feels like because they do.

They're only going to care enough to keep the code good if their actions matter, you know, if they actually get to make those choices, which means you got to let go of the hand and let them do it, which is going to be uncomfortable. But then they will own it, and they'll learn, and they'll become that fierce owner, you know, it's their thing, and care enough to keep the code solid. And I think that having a culture of giving people the chance to actually own the code is hand in hand with having quality code, that you can't take away control and expect the best practices to continue because it rubs against human nature. That was my high-level idea.

WILL: Yeah, no, I totally get it. And so, the question that I have for you guys, this is kind of a broad thing, but, like, how do you cultivate that kind of [inaudible]? How do you value people who have been around long enough to take ownership? What are engineers like that worth to you? How do you build that stuff up? How do you keep...I would say, I love institutional knowledge. I love people with ownership. I love all that stuff. I am very fairly stridently against the idea of seniority as if, like, sort of years on the job is a suitable proxy for these desirable qualities. So, how do you make that happen?

I won't bury the lead, but one of my great bugbears of the industry and one of the things that I...I really hate the fact that you've got to move around to move up, and I understand the countervailing forces there. But, like, if you didn't want to do that...because all these things that we're talking about, these watchdogs, this ownership of code, this isn't the kind of thing that you can have with people moving every two years. But if you're not moving every two years, there are consequences for your career, which can be fairly significant. How do you manage all that stuff? How do you create these cultures that we all agree we need but there are so many headwinds against?

MIKE: Well, Netflix, if I remember right, so I'm going from memory here, but my understanding is that for years, they had a policy that if you got a job offer somewhere else, they would match it. No questions asked. They cared enough about that continuity. They put their money where their mouth was. And so, they had some of the best-paid engineers in the industry by some margin, sometimes, like, you know, 30%, 50%, 100% more than some of their peers.

But I tell you, you do that, and you get a committed team who cares enough to stay around. I think they did the things because the company cared enough to actually do what they said and value their team members. The result was they got a team that made them extremely successful. So, I think that there are examples in the industry of people doing right. But there's a lot of examples of being short-sighted because there's a lot of incentives to be short-sighted, to say, "Well, we need to save money. We need to make the stock price go up., And we're going to get that by reducing costs," which is a reasonable thing to say. But then what happens next is dicey, right [laughs]?

You say, "Well, what you do next shows what you value. And if what you do next is continue to value your team and pay them appropriately, well, that shows what you value." If what you do next is say, "Well, let's get rid of all of our senior experts because they cost a lot, and let's hire a bunch of new folks without any context and, you know, it'll work, right?" Well [chuckles], you've shown your values. And there's a hazard, I think, to leadership to make decisions that will probably turn out well in the short term but will lead to a steady decline over the long term.

EDDY: It's like what do you do when the only two people in Coca-Cola suddenly die and they're the only ones that know how to make your recipe, right? You can get pretty close to the genuine taste, but you just know that it's going to be a different taste, and it's not going to be the same.

WILL: Well, like, the great [inaudible] are full of indispensable [inaudible 27:49], right? And I think there's a counterargument to be made that your initial team is the people you could get. But as things go on, as the company gains legitimacy and financial power to compensate and hire and retain good developers, that original team maybe, like [laughs], uncomfortably accurate definition of a technical co-founder, is the best developer you can get to work for free.

MIKE: [laughs]

WILL: So, you could start bringing in more heavy hitters as time goes on. And a lot of the decisions, engineering decisions that were, I think, defensible, if not absolutely correct at the time, are no longer so. There's a flip side to that as well. Everything is a golden [inaudible] [laughs], right? You're always trying to find a balance.

MIKE: Sure. What you probably don't want to do, though, is hire these great, new folks, keep them around for six months, and then send them out the back door. And maybe you're deluding some of the people there originally, or maybe you do ask them to leave. But you're still looking for continuity with people who know what they're doing. There's still the respect for expertise and, again, not seniority per se but expertise.

WILL: Well, yeah, and then it becomes a sort of a leadership challenge in that you need to sort of walk people down where they were, at one point, a law unto themselves, and now, you know, maybe they have a manager. And I think, arguably, the current stock option regime mirrors that, I think, pretty well in that, you'll have your founding teams, and they'll get a big slug of equity. Like, your initial hires they'll get a big slug of equity, and that equity will appreciate and appreciate and appreciate.

And people will come in. You'll get your series A round. And you'll start to bring in some real hitters, and they'll get more compensation. But the people who came there blocked the stock, and it's worth a lot more now. And so, they have, you could argue, golden handcuffs on one hand. But you could argue they're paying for institutional knowledge and continuity, even though they might not be continuous in the same role. Everybody sort of gets a...it's a fair shake there.

MIKE: It's interesting that we started by saying, "What scares us in the code?" And we're talking about stock options [chuckles]. And I don't think that's off. It seems like a tangent, but I think it's inseparable in that we're talking about the practices that lead to ownership and people caring enough to make the code solid.

WILL: Well, exactly. Well, we talked about the code for 5 or 10 minutes, and then we immediately jumped to the real problem, which is sort of maintaining the team, maintaining that culture of engineering excellence, maintaining a sense of ownership and responsibility as things scale, as things get bigger, as the problems get more complicated. I mean, that's it. That's the issue. There's no two issues around it. As long as everybody is coordinated, and focused, and disciplined, you can sleep pretty soundly. I mean, every once in a while, something's going to go bad. But, man, dude, nothing makes me happier than a problem that got successfully opened, closed, and resolved, and I didn't have to lift a finger. I'm just like, ooh, ooh.

MIKE: [laughs]

WILL: Oh yeah, oh yeah. What's up? Oh, that was Saturday.

EDDY: For those who are fans of --

WILL: You guys had a rough Saturday, boys.

MIKE: [laughs]

EDDY: For those who are fans of Emperor's New Groove, there's a meme where he goes like this, and it's like an okay because it's just so perfect. And that's what you made me think of when someone reports a problem, and it just goes fluid, and it just goes perfect. Awesome moments that you sleep like a baby.

I do want to say that there's a couple of situations or circumstances that sort of keep me up at night, and one of those are having a tower, where the foundation of that tower on the right side is held by a twig. It's so freaking scary because that's legacy code. And touching something where you just don't know where it is, you can make the change that's super scary. And I feel like a lot of us sort of try to avoid that and find another alternative because it's like your whole app is rooted off of it [laughs]. So, that's one of the things that keeps me up at night.

MIKE: That goes back to the continuity we've been talking about. Hopefully, you can keep the continuity so that you have somebody who knows how to work with that twig and can share it, sometimes, though, you don't. And in an older codebase, you probably don't have people, and if they do, they're probably spread thin and don't have much time to talk to you about it. And that's a difficult problem that –-

WILL: I don't know, I'll say that just, for me, I don't spend a lot of time thinking about pieces of the codebase that have been running without complaint for many years. Those are not high on my [inaudible]. Nothing like battle-tested code. Although, gentlemen, if you can't hear, I am being paged. I think it's time. I think it's my time. I will talk to you guys. See you guys.

MIKE: As Will was saying, if it's working, you don't have to worry about it. Sometimes, though, it stops working [laughs] or needs to be changed. And then, you got to have somebody who can go in there and fix it. I can bring up one example. She's not here, so I'm not going to name. But I worked with a really good engineer who was obsessive about detail, and she'd see something, and she just couldn't help figuring out why it worked and how it worked.

And it meant that it took her a long time to get things done initially because she would understand what was going on before she pushed up the code. But it also meant that once she'd worked in the area, she understood it, and she could get that job done. And anybody else who needed to work in that code would go to her because [laughs] they knew that she could help them understand what was going on.

Having somebody who can have that level of focus where they will take the time to actually figure something out is so valuable because it solves your twig problem, Eddy [chuckles], because they'll take the time to figure out exactly how it's working. And there's a hazard there because you might think, well, their output is not as high. They're not cranking out a bunch of code because they're going to take longer to get things done generally because they're not going to push out their changes until they're sure they work. But they provide immense value to the team [chuckles] because having somebody who actually gets it is just so valuable.

EDDY: I agree. I agree. Now, there is another thing that keeps me up at night. And this is when you have a long chain, and they're all connected to one another. And in this chain, it calls another chain, which calls another chain, which calls another chain, which calls another chain. And, suddenly, you have 17 chains that are hooked up, right?

MIKE: Link after link [chuckles].

EDDY: Oh, that was so bad because then what you have to do is...and they tell you, "Oh, modify this chain." And you're like, ah, see, I don't know. I don't want to modify the middle. That's too scary. I don't want everything to just split open. So, what I find some people do it's like, oh yeah, we'll modify the tip. We'll modify the end. We'll modify the other end. And that's why you get a long series of chains, and that really keeps me up at night any time I have to touch any of that code.

MIKE: Well, and if you're doing that also without doing any refactoring, you probably end up with 20 parameters to the end of the chain, where the chain began to try to promote reusability. And then, oh yeah, well, there's this component that could be reused. But if you haven't figured out what's going on in that chain, the reason why you have it, then you're not going to reuse one of the components and kind of branch the tree where you need to. You're just going to tap in at the end and add another parameter to make it do what you wanted, rather than going deeper into the chain. The part that does do what you want, you could have [inaudible] in there.

EDDY: Yep. Which is why I sort of adopted the ideology of singleton classes. I really do enjoy them a lot. They're much easier to work with.

MIKE: Singleton can have a few different meanings. Could you clarify exactly what those parameters are that you're --?

EDDY: Sure. So, for me, a singleton class is just a single hand of responsibility for that class, and that's all it does. [crosstalk 37:45], right? Like, don't branch off of that. It's possible that you can go beyond that if you want to, but don't violate that. It's part of...there was a book that we read on Ruby, which was...I don't recall the exact name of it off the top of my head. You might remember it, Mike. But the whole –-

MIKE: On "Design Patterns"?

EDDY: The "Design Patterns," yeah. So, part of the idea of the design pattern from that book was don't go beyond of what the class is intended to do because you risk maintainability and reliability from that class. So, if you say, oh, this class' whole purpose is to structure a hash, and that's all it does, and you're like, oh man, but it would be really nice if it would also do this, and you're like, yeah, see, it works. And you can do that, but don't do it, right?

MIKE: Single responsibility, single responsibility. So, I wasn't sure where exactly you were going because sometimes singleton can mean that you've got something that's self-contained, so it's both...there's only one instance of it in all of your running application because the class will only create one instance of itself. And so, you have that single shared instance across the application, so you avoid issues with duplicates of it.

And so, if you're managing a connection pool, for example, you don't want to have two managers of the connection pool. You want to have one, so you don't...only one person in charge. But what you're saying is something a little different, which is single responsibility principle, your unit of code. And if you're functional programming, you don't have classes, but you should have your function. It should do one thing. It should do that thing well, and it should do nothing else. And if you've got something else to be done, well, some other unit of code should do that.

EDDY: Agreed. Now, you run into issues where you implement modules or concerns that essentially do the same thing, but they deviate slightly. And that's also a problem that's really hard to address.

MIKE: Are you talking about people writing code that's almost the same but not quite?

EDDY: Yes.

MIKE: [laughs] Yeah. And so, they end up diverging.

EDDY: And, suddenly, instead of maintaining just one, you're maintaining two. You're maintaining three [laughs].

MIKE: Well, that gets to the don't repeat yourself. Don't repeat yourself is actually kind of subtle because there's times when you absolutely should repeat yourself. And here's where I take that. In cases where the repetition is trivial and makes things easier to understand, then you should repeat yourself such as in a display component. To take something to its logical extreme, let's say you said, "Well, all markup uses tags, so I want to make sure that every single tag is written by shared code." And so, you have to go through this shared code to render a tag.

And maybe you have some sophisticated component. Maybe you're writing a front-end component where that actually does make sense. But if you're just writing out some markup, then that's probably a really bad idea because you're going to have all kinds of complexity, or you could have just thrown some text out there, and it becomes far harder to manage.

Likewise, unit tests. People sometimes think, man, I'm going to make sure that I have no duplication. So, they take anything that might possibly be shared and put it into a shared example that's in some other file that you have to go digging [laughs] to find. It makes it so hard to see what it is that you're testing, where if [inaudible] the details and repeated them, then it would be a lot more comprehensible. So, I'd say don't be so DRY that it chafes [laughs].

EDDY: I've received code where I've reviewed where they've obscured all the dependencies to top level in the specs, and they just call one subject, right? Boom. And then, like, that's the whole context for that test. And I'm like, no, what? What's going on here? And so, I have to go and I have to dig to figure out what's all the dependencies for that. And I'm like, sometimes I wish, man, can we make this a little bit more DRY? Just a little bit more so that we have...because tests, in general, should document themselves, right?

MIKE: Yes.

EDDY: And if you're obscuring that for your reader, then you lose context and it's really easy to keep all that in your head. So, I have tried to push a bunch of new tests that I've written, right? And I've applied a bit of dryness to it.

MIKE: Well, less DRY [inaudible], like, in this case, less DRY. You are going to repeat yourself. It's important for legibility. But then, on the flip side, you say modules will do the same thing. That's where it actually matters a lot to not repeat yourself because you are going to have to maintain two things, or then three things, or then four things that are slightly different that basically do all the same thing. And now you've got to maintain all of them. And, in that case, for important business logic, yeah, put it in one place and one place only. For unimportant display issues, repeat yourself at will.

EDDY: I have pretty much bent the knee, and I've said, all right, I'll settle with damp [laughter].

MIKE: You like your code moist.

EDDY: Yeah, it's a little moist, you know, best of both worlds. It's fine. You know, not too extreme one way or the other. But you have ideas from both is really where...because you have to be able to differentiate between syntactical opinions, right? That doesn't really, like, it has the same functionality, you know, same everything. But the holdup really just becomes from that individual's opinion on how the code should read versus how it functions, right? So, at that point, you really just...you have to give in. And you're like, eh, it was just syntax, not a big deal.

MIKE: Let people make their own decisions a little bit [laughs].

EDDY: Agreed. And it came back.

MIKE: It did come back. That's maybe a good stopping point, actually.

EDDY: Agreed.

MIKE: So, we looked around a lot and didn't talk a lot about specifics in the code but a whole lot about practices that tend to drive good code. And so, we sleep well at night when we give people the agency or ownership to make their own decisions. It sounds like it might make you sleep worse at night [laughs]. What's my teenager out there doing [laughter]? And if you've given that teenager the chance to make good choices since they were three, then maybe you are sleeping at night because you trust them to make the choices you've already seen them making.

EDDY: I'm not a father personally, but I do attribute my tests to do the parenting for me [laughter]. So, I sleep better at night knowing, you know, that my tests are holding me accountable.

MIKE: That's great. Well, thank you, Eddy, and thank you [inaudible]. It's been great and until next time on the Acima Development Podcast.