On today’s episode we welcome two guests, Madelyn Freed and Sam Handler to help us discuss the topics of tech debt and trust. These ideas my not be new to the field of software development but our guests really help us unpack these topics in way that can be beneficial to all listeners. It is a common experience for coders to come across what is termed ‘tech debt’ and the need to pay back time and energy into code for something that was not written perfectly in the past. So what does this mean for the present? How do we approach righting these wrongs? And how do we ensure the minimum technical debt is incurred through our current actions? In this discussion we cover a broad definition of tech debt and look at the ways the term can be used in business agreements. Our guests help us discuss the role of tests in minimizing future tech debt and how these conversations can play out to everyone’s benefit. The conversation really centers around the idea of team play and doing what you can in a given circumstance. For an inspiring and multifaceted discussion of the intricacies of the life of a developer be sure to tune and hear it all!
Key Points From This Episode:
Transcript for Episode 67. Tech Debt and Trust
[0:00:01.9] MN: Hello and welcome to The Rabbit Hole, the definitive developer’s podcast in fantabulous Chelsea Manhattan. I’m your host, Michael Nunez. Our co-host today -
[0:00:09.8] DA: Dave Anderson.
[0:00:10.8] MN: Today, we’ll be talking about tech debt and trust. But before we continue, we have two guest today, we have Madelyn Freed and Sam Handler. How’s it going? Ladies and gentlemen.
[0:00:20.4] MF: Hey.
[0:00:21.1] SH: Hey.
[0:00:21.4] MF: It’s going good.
[0:00:23.5] MN: Awesome. Well, we’re talking about tech debt and trust. We’ll be going through some – the definition of tech debt and how do we actually get that point across to our team members. So we can actually get and fix up code that we have.
Tell us, what do engineers mean by technical debt?
[0:00:43.3] MF: That’s a good question Mike. There’s like the dictionary definition that we’ve been saying which I don’t have in front of me right now.
[0:00:56.3] SH: I have it.
[0:00:56.3] MF: Go, do it.
[0:00:58.4] SH: Wikipedia says, “Technical debt also known as design debt or code debt is a concept in software development that reflects the implied cost of additional rework caused by choosing an easy solution now instead of using a better approach that would take longer.”
[0:01:13.7] DA: Isn’t the easy solution the better approach?
[0:01:17.1] MF: No Dave.
[0:01:17.9] DA: Sorry.
[0:01:19.3] SH: Wait, it depends on context.
[0:01:21.9] MF: Yeah, it does. This term tech debt was first used by Ward Cunningham in 1992.
[0:01:31.1] SH: Yup.
[0:01:31.5] MF: 1992.
[0:01:32.1] DA: Our founding father.
[0:01:33.2] MF: He’s the founding father.
[0:01:33.6] DA: Of tech debt.
[0:01:33.6] MN: Of tech debt, there you go.
[0:01:35.9] MF: He signed the Agile Manifesto, he’s a great guy.
[0:01:38.7] DA: Declaration of Independence for software engineers.
[0:01:42.9] MF: Yeah. He’s the Alexander Hamilton. It’s a useful metaphor for certain circumstances because you tell that to a business person, you know, it means something bad.
[0:01:57.4] SH: Yeah, no one wants to be like in debt, it’s like, if you’re in debt, it’s like – you got to do something about that, you got to pay that off otherwise, you know, it gets worse. It’s like compound interest sort of thing.
[0:02:09.7] DA: Yeah, the man.
[0:02:10.4] SH: You don’t want to hear it. You do not want to carry a balance.
[0:02:13.9] MF: Don’t want to carry that balance.
[0:02:15.3] SH: That’s rough.
[0:02:16.9] DA: With a startup, like often, you know, they’re living their lives like investing money and kind of going into debt in a way.
[0:02:26.4] MF: It’s true. Debt can be useful. I think that the reason that this metaphor like struck us sort of was that it sets up this idea that tech debt and the things that we call tech debt are hard to explain to business people and that you have to give it sort of a spooky word so that people will pay attention to use that you’re allowed to work on it.
And that is very useful in a lot of context but it can sometimes obscure what’s actually kind of easy about explaining tech debt.
[0:03:03.3] SH: Yeah, I‘m like, I guess one other thing, apart from like this very useful idea that you know, you're this developer, they’re making irrational decision and you're like, “I’m not going to write test for this because we got to ship this by tomorrow and like, if I don’t, this contract’s not going to be fulfilled and the company will collapse.”
Then you know, you live with that decision but there’s also this really important aspect of what we call technical debt which is just like, there are all these aggregated like accumulated, horrible or not so horrible decisions from however many years your code base has been around and you, like as a developer, you know, you didn’t make a lot of those choices.
If you start working somewhere and they’re on Rails three. You started learning rails when it was at Rails five and you’re just like, now I have to upgrade Rails three to Rails five. That’s like you know, you didn’t take out that loan kind of thing and –
[0:04:04.9] DA: The guy who took out that loan is like probably moved on.
[0:04:07.3] SH: Right, totally. He still got like a Slack emoji or whatever. He’s like, you know, his decisions live on and people are like, “Man, yeah, Larry just did not want to upgrade and then he like, peaced out.”
It’s like sort of like this shared debt burden that everyone has which makes it all the more important for the team to be able to discuss it with you know, other parts of the organization because it’s like, you know, the person that made that tradeoff may not even be there anymore.
[0:04:38.0] DA: Yeah. I like thinking about the retrospective prime directive with legacy code like that. It’s like you know, regardless what we discover, we know that everyone did the best they could with what they had at the time.
[0:04:50.8] MF: Yeah, that’s a big thing for me when we talk about technical debt which is that there’s a big engineering culture about ragging on all the shitty code you have to interact with.
I mean, all of the terrible decisions that some random person made eons ago that you now have to struggle with.
[0:05:09.1] DA: Yeah, as opposed my like completely un-terrible decisions.
[0:05:11.4] MF: Exactly. You are not smarter than that because as I said, the last time I talked about this one day you will [inaudible] that and it will have been you.
[0:05:22.2] DA: Yup. Yeah.
[0:05:25.2] MF: Be kind to all those terrible decisions that someone had to make that one time long ago.
[0:05:30.4] DA: Right. Like tech debt is like everyone else’s code and your own code that you wrote six months ago basically.
[0:05:36.4] SH: Man, like two months ago.
[0:05:37.4] DA: Two months? Lets be honest.
[0:05:41.3] SH: There’s also this concept which is like pretty ill-suited to podcast but if you're listening, its’ called Martin Fowler has the idea of like tech debt quadrants. Basically, they’re just I don’t know, maybe you can think about you know, pick two of these and they can describe any kind of tech debt, there’s like sort of reckless and prudent debt.
[0:06:04.6] DA: Like an axis between reckless and prudent?
[0:06:06.4] SH: We don’t have to visually describe this. My god, that would be –
[0:06:09.2] DA: I’m visualizing it right now.
[0:06:11.2] MF: No, podcasting is obviously a visual medium.
[0:06:14.9] DA: Exactly.
[0:06:16.4] MF: Famously.
[0:06:16.5] DA: Close your eyes for a moment.
[0:06:18.6] MN: Yeah, the square, what’s the top left?
[0:06:21.2] MF: Quadrants.
[0:06:21.9] DA: Reckless and prudent.
[0:06:23.6] SH: It’s reckless and prudent and then deliberate and inadvertent. You can have reckless and deliberate where you are being like, I know this is bad choice and I’m doing it anyway or like deliberate imprudent which is like all right, we need to ship this without tests because like literally, the website is down so we just got to fix it.
Or reckless and inadvertent where you just like didn’t do a lot of advanced work to like try to solve a problem or do research so you know, didn’t know about a pattern or the last one would be prudent and inadvertent which is you took your time, you tried to make the right choice and you made a measured attempt to write good code. You just like, kind of missed something.
Anyway, those are like the – Fowler has these quadrants which I think are pretty good but they kind of get it like encapsulating, deliberate tradeoffs and just like stuff that accumulates for various reasons.
[0:07:24.2] MN: Yeah, we got to remember to put that in the show notes so that people can listen to that and actually see the quadrants themselves as well.
[0:07:31.0] MF: Yeah.
[0:07:31.7] DA: I’m trying to imagine these quadrants for like you know, messes I leave around my house too.
[0:07:36.4] SH: Yeah.
[0:07:37.8] DA: Reckless imprudent. I’m late to work, I’m just going to leave these dishes here. You’re one of those?
[0:07:45.2] MF: You knew all of the factors in place. Yeah, you want to move up into the right, as all graphs, you want to be more prudent.
[0:07:54.1] DA: Going to get ants.
[0:07:55.6] MF: Yeah, exactly. You have ants anyway. That’s when you were – what’s the other axis Sam? It’s Prudent and inadvertent.
[0:08:03.9] SH: Inadvertent.
[0:08:05.6] MF: You did your best but ants still come.
[0:08:07.3] DA: Gosh. Sometimes that happens.
[0:08:09.8] MF: Yeah. I think that when we say like there are all these difficulties, we know the feeling of taking out our own tech debt and especially when we’re like living in the tech debt of our forbearers that it’s hard to make the argument to business people to work on it.
I’m sure everybody here has had a tough time convincing someone. Do you guys have stories like of trying to make the case to someone and not being able to?
[0:08:40.3] MN: Yeah, it’s like, even like the concept of testing can go over people’s heads and you want to explain to you know, the project manager or the product manager like, “Hey, this is going to take the rest of the day because we want to make sure that we have coverage to ensure that this is not going to happen again.”
Oftentimes, the response is, “But, I mean, you’re writing it right? Why don’t you just write it the best that you can so it doesn’t happen and there are no problems ever.”
But you don’t know that you’re going to run into a problem in the future but you can have tests that will cover those problems when they arise.
[0:09:17.7] MF: Right.
[0:09:18.2] MN: That’s usually like the really difficult part. I want to make sure that these things are covered and I was like, but, you write good code, right? Like, isn’t that what you do? Yeah, but, it’s because -
[0:09:29.8] DA: Except when you write bad code.
[0:09:30.6] MN: Yeah. Except until the website goes down.
[0:09:34.7] DA: Then it’s like, then you got to write more code when that goes – no longer that guy who writes that code.
[0:09:40.0] MN: I think, the case, it’s really difficult to make that case though overall. Every person, every place you work is a challenge that will always look forward to and not at the same time.
[0:09:52.3] MF: Yeah.
[0:09:53.2] DA: They’re like upgrading software case like you’re trying to for Rails or like definitely envisioning like specific moments where I was like, let’s not use Python 2 anymore. Let’s move on, we’re good, let’s not use like libraries that are no longer used. We’re already invested in it, right? Maybe we are not confident in the test coverage we have and we’re just like okay, this is our life.
[0:10:19.6] SH: What if I told you -
[0:10:22.0] MF: This is a trap.
[0:10:23.1] SH: What if I told you that arguing for technical debt should be easy.
[0:10:29.3] DA: Well I’d say -
[0:10:30.1] MF: For 9.99.
[0:10:30.3] DA: Please, do go on.
[0:10:31.9] MN: Yeah, first of all, four easy paymentx, it’s 1.99.
[0:10:36.9] SH: Anyway, we’ve got premium segment at the end of this, subscribe on Patreon.
[0:10:43.7] MN: Patreon.
[0:10:45.2] MF: Send me a check directly.
[0:10:46.1] DA: Right, here’s my memo.
[0:10:50.2] MF: Yeah, I think it’s easy.
[0:10:51.3] SH: Why?
[0:10:52.8] MF: I think it’s easy because if you are making the argument well enough, it is just a business argument.
Like the things that are difficult, like the things that are tech debt should be valuable and the reasons that they are valuable is directly understandable by business people.
For example, like the reason that tech debt is bad is because it – when something goes wrong, it takes longer to fix it. When you interact with the code, it just takes longer to understand it. You have to re-remember how the looping, whatever, through a million controllers works again and again. That takes a long time and our salaries are expensive, that’s what it is, it costs more. Just period.
Those cases have to be made in that manner. I mean, it can be. If you can’t make them in that manner, you can’t figure out how to explain it from a business context, it might not be valuable.
[0:12:01.3] MN: Right.
[0:12:02.8] MF: You have to kind of live with that. For example, you want to try something out real cool.
[0:12:10.4] SH: I don’t’ know.
[0:12:11.7] MF: You could frame that as technical debt, you know? Just because you want to try a GraphQL which by the way is great. But you know, it may not actually be paying down technical debt, it may actually be taking it on and you have to be okay with trying to make your case from a business perspective and having somebody say no.
If you’re good enough at making that case, I think that everything can be boiled down to that.
[0:12:41.2] SH: If you’re making the case, it’s like, you can’t make the case in a technical way, like Madelyn was saying. It’s like if you’re like, “Yeah, it will make it so much easier to add more controllers.” It’s like, okay, well that means literally no one and that means literally nothing to someone that’s not already writing code, you have to be like, “It will make it faster to write features in this pretty concrete way,” and then that becomes something that you could negotiate about or make the case for.
That’s why you have the concept of technical debt in general is so that you can communicate those concepts.
[0:13:23.5] MF: Yeah, I think that that’s, it’s hard, it can be a real heavy lift I’ll say in business-y speak, to explain what test are, to explain what versions, you know, of you know, big infrastructure are to someone who doesn’t do that as their job.
[0:13:45.3] MN: Right.
[0:13:46.6] MF: Fortunately and unfortunately for us, that’s our job to be able to explain that and to be able to say, “Okay, I can actually explain why having good tests, having well written method names,” whatever it is, is important. “I need to get you to care about that even though it’s not your job to understand it.”
[0:14:08.2] MN: Yeah, just to reiterate what Madelyn had mentioned. I tried to use time and money as part of the explanation to why we should pay down this tech debt. I think what Sam mentioned about being able to – “We need to refactor this particular part of the code base because it will allow the ease of releasing more features if we do this now,” will incentivize the business to want to do that because they want more features out faster.
To explain to the business that you know, the fact that this particular piece of code is difficult to work with, takes a longer time to release code that we should work on making it easier for everyone to work in this particular domain or in the application, will incentivize the business to want us to spend time on that so that we can release things faster than we normally can.
[0:15:05.1] DA: Yeah.
[0:15:06.0] MF: I think that there’s a couple of ways – there’s a couple of ways to make that argument stronger which is to put it in a business context. I think that there’s like – there’s a good faith portion of it that engineers have to behave in accordance with, which is, you have to be trying to explain it to a non-technical audience, you have to be doing your best to be empathetic to other people’s understanding, take the time, maybe go to a meeting.
Maybe draw a diagram like be kind of doing that leg work to make what your argument is understandable.
[0:15:43.1] DA: Right.
[0:15:44.1] MF: Then, also, you have to - there are two more things. One is that, have kind of an idea of how long something is going to take or have a way to investigate how long it’s going to take. Don’t be a ninja hero 10Xer whatever the hell. Don’t go off and do it by yourself, work as part of the team and if you try to make your case and people aren’t believing you and they make a decision that you don’t’ like, be chill.
Accept the decision if you did your best to make the case in a business context.
[0:16:20.0] SH: Yeah, I feel like engineers like when they’re really close to the code, I’ve felt this before where I’m just like, I’m the only one that knows how this works and like, I’ve just really know what needs to be done to make this better and it’s going to make, and it’s like –
[0:16:33.1] DA: Yeah, you’re the hero.
[0:16:33.9] SH: Yeah, well, okay but like someone else could like spend like you know, four days and then they would be the one that like knows how it works. I’m like, yeah. Not that big a deal and like, you really need to understand yourself - like the business has to be healthy for you to get a salary, I guess, depending on what startup you’re at.
Like you know, the overall success of the business is like what matters and like the engineering team, like, you know, if awful code could sustain the business, that might actually be the right choice. It’s just like empirically not, if you want to have a sustainable code base.
[0:17:12.0] DA: Right. That’s even kind built into the Agile Manifesto to agree, you’re really more concerned with the working software. Doesn’t have to be beautiful software or like debt free software but just working.
I really like that idea of like having empathy for the other people like the business people and also like the idea of like having self-understanding about like, knowing, being able to separate what’s important for you personally and what’s important for like the larger goals of the team.
Because that can be a little bit challenging like Sam was saying. When you get really invested in the project.
[0:17:48.1] MF: Yeah. I guess the upshot of all of this is that you can make the best, most pristine argument you could ever, make it’s so beautiful.
[0:18:00.2] SH: Diagrams.
[0:18:01.6] MF: So many diagrams.
[0:18:02.1] SH: Graphs, PowerPoint.
[0:18:03.4] MF: You’ve been having meetings for years.
[0:18:04.8] SH: Party favors at the meetings.
[0:18:06.9] MF: You bring snacks, good snacks too.
[0:18:08.8] MN: Good snacks, yeah. Mango Lacroix, yeah.
[0:18:11.7] MF: Mango?
[0:18:14.2] DA: Coconut?
[0:18:16.3] MF: Yeah, if I want to estrange the audience, I could tell them that four flavors are coconut. Who knows.
[0:18:25.3] SH: All of our Patreon donations.
[0:18:27.2] MF: No.
Anyway, you can make this pristine argument and give out everyone Coconut Lacroix but it can go nowhere and if you don’t have trust in your team. And if the team doesn’t have trust in you, trust is the number one way to get the things you want done in your organization.
And there’s a lot of ways to tell whether you have trust in your team. I’m kind of just parroting some XP concepts of the whole team, where you know, who is the whole team? Who is in the room, who is in your team room? Is everyone who is important to make a decision there for the important conversations?
You know, ask yourself like, “How many steps do I need to take to talk to the important people? Do I need to stand up for my chair? Do I need to open a door? Do I need to like talk to an executive assistant to make sure? You know?
[0:19:26.8] MN: OR schedule a meeting, like yeah.
[0:19:28.7] MF: Exactly, is it hard, how hard is it, how much friction and also, you know, do you – who comes to your stand ups? Are they useful? I think a big part of hole team is like it is not the tech team versus the product team, it is not the tech team versus the business team. It’s like, the biggest problem in New York tech right now, I think.
[0:19:49.4]MN: Yeah.
[0:19:51.0] MF: It’s on two opposing teams? You are the team so figure out how to invite them. There’s a way to build trust on your team and – Sam?
[0:20:02.3] MN: Take it away Sam.
[0:20:03.9] MF: Take it away Sam.
[0:20:05.0] SH: Okay, here is your 10 point plan for putting trust on your team.
[0:20:08.6] DA: The first spot, give them the first five and then the rest they got to pay on Patreon, as that will –
[0:20:13.2] SH: Yeah, exactly. No, these are like kind of common sense things. The big one is just sort of the forming human relationships piece. That’s it, pretty much everything –
[0:20:27.6] MF: To getting an end.
[0:20:29.0] SH: The everything that I’m about to say is kind of about, okay, form a human relationship. Part of that is forming relationships with like the right people which is as Madelyn says, is the real whole team.
Part of that is inviting like the actual whole team to stand up. So like, if you don’t have a stand up, think about why that is but then, also, for retrospective, like everyone that you know, is on that whole team should be there, thinking critically about what went well and what went poorly and having an opportunity to reflect on that.
Then same thing for demos. Demos are super important for building trust like if you have demos, everyone should be there and you should also be demoing both user phasing stuff and purely so if you paid down some tech debt, demo that.
Show the before and after, the people needs to know and that will help the folks that aren’t spending all day coding, it will help them understand what you’re doing and why it like makes your life better.
[0:21:29.4] MN: Right.
[0:21:31.3] SH: Then, working on your ability to explain technical concepts to people that are not developers, this is you know, people in your everyday life, like explain what DNS is to your dad.
[0:21:42.3] MF: Make him care about it.
[0:21:44.6] SH: My dad does not care about that.
[0:21:46.2] MN: Definitely, my dad does not care.
[0:21:47.6] MF: Right, if you get your dad to care about DNS, you are made in the shade, that’s some top stuff.
[0:21:53.5] DA: Some passion.
[0:21:56.3] SH: There’s other simple stuff, I don’t know. Like, have team events, try to have team events like not necessarily just in a bar. If you’re having all of your team events at a bar, you’re probably excluding people and also it can be hard to hear and remember.
Another thing you can do is to form working agreements, that’s like the team gets in the room and a brain storm stuff that they can all agree on about how they work, this is really good for building trust especially across multiple functions from developers to products to sales, to whatever.
If part of the working agreement could be like, “Check your email once a day,” or, “Respond in Slack with an acknowledgement within two hours if someone ats you.” That kind of thing.
[0:22:41.3] MN: Yup.
[0:22:41.8] SH: That can do a lot to build trust because then you sort of know the rules of the road for interacting with one another.
[0:22:49.0] MN: When someone happens to break those rules, then people can either reconvene and discuss why the rule is broken and if there is an extreme case, there should be a discussion as to whether we should keep it or whether people who are violating need to get in line with the working agreement but everyone will trust each other and that they’re following rules that everyone agreed with.
[0:23:10.1] MF: Yeah. It’s good for when the rules are broken, you can point to the wall where the rules are you know, it’s just like, it doesn’t mean that everyone will always follow them forever.
[0:23:20.5] DA: Right, but you have a shared context and you don’t need to feel bad about being that guy.
[0:23:24.2] MN: Yup.
[0:23:24.9] MF: You know, you can put in all the process that you want, if the team isn’t trustful of each other, it does not matter. I feel like the thing you need to do is be trying to build human relationships. Then you can also do process things to make yourself feel better.
You can like act, you know, it’s good and it feels good to act but I think the main thrust of it is, are you building human relationships, you know, when you walk towards someone, do they always flinch because you only tell them bad news, you know, like, talk to them more often, you know?
If it hurts, do it more. Speak to them about human things like you know, breathing and metabolism.
[0:24:10.2] MN: Yeah. How’s the weather and stuff like that.
[0:24:12.6] DA: Check, check.
[0:24:13.7] MF: Yeah, that’s super important and also, if you know, you’re having demos and you’re having inviting people to places and they’re not coming, talk about why it’s not useful. Ask them.
And then also, yeah, I think like, having as Sam said, having demos is like the tool I feel like for some of this is you invite someone week over week and they see you build it, bit by bit by bit and you let them ask you questions over and over again.
They know that you're not screwing around, you know?
[0:24:48.5] DA: It’s a good opportunity to talk about like what was hard and why it was hard and what would have made it easier.
[0:24:55.7] MF: Exactly.
[0:24:56.2] DA: Might be your tech debt.
[0:24:57.5] MF: Yeah, exactly. They will know in detail about the fires that happened and all the pain and they’ll see your face. I think it’s really important that like a business person doesn’t just know the tech lead on the tech team.
[0:25:08.8] MN: Right.
[0:25:09.7] MF: You know, does everyone know each other because you’re all just human being on the same team. There’s not like a hierarchy of who’s allowed to trust each other.
[0:25:17.9] MN: Right. Gain trust, crush tech debt, win. That’s it, right there.
Do we have any teach and learns today that we would like to discuss?
[0:25:29.3] MF: Yeah, I’m new to Ruby on Rails and I’ve been just zooming up that monolith and the thing that I just finally figured out today is symbols in Ruby.
[0:25:43.4] MN: Nice. Symbols rule.
[0:25:46.2] MF: Couldn’t figure them out.
[0:25:47.0] SH: Symbols are the best.
[0:25:48.9] MF: Finally I was like, what the hell is this colon thing? And that’s what I learned today and they are cool.
[0:25:55.8] MN: Yeah, symbols are great.
[0:25:56.9] SH: There was this old book where I feel like symbols wouldn’t get garbage collected in Ruby.
[0:26:06.4] DA: Ruby too, right?
[0:26:07.9] MN: Yeah.
[0:26:10.2] SH: I think it was older. Actually, I don’t remember. Anyway, hilarious, they fixed it.
You know, if you were like creating symbols willy nilly in your code, you could end up like you know, messing yourself up pretty bad.
[0:26:23.6] DA: What did you do?
[0:26:24.1] DA: You make a lot of those symbols.
[0:26:25.6] SH: Yeah, exactly.
[0:26:28.5] DA: I had like – I have one as well. I was working today, I was working in code and I wrote an object in Python like just a regular object.
[0:26:38.9] MN: Wow. Like a class?
[0:26:42.2] DA: That was representing money and I wanted to be able to add the money and multiply the money so these magic methods and so, I was like pairing with someone and teaching about how you interact with like the operators in Python and having the left multiplier and the right multiply in fixed multiply, all those crazy things.
[0:27:02.0] MN: Awesome.
[0:27:03.4] SH: Neat.
Today, I was pairing with someone and she did CP-PR and then a directory and I was like, “What’s the P flag for?” And she started cracking up and she was like, I was like, “What’s so funny?” And she’s like, “I’ve told you this three times already.” The P flag preserves the timestamps when you copy stuff over.
[0:27:31.0] MN: Snap.
[0:27:31.2] SH: Pretty cool.
[0:27:32.5] MN: That is awesome.
[0:27:33.1] SH: Pretty cool.
[0:27:34.8] MN: That is all – I definitely –
[0:27:35.5] SH: You heard it here first.
[0:27:36.3] MN: Yeah, you heard it here first.
[0:27:38.0] SH: Second or third, you know, who knows.
[0:27:38.8] MN: Yeah. That’s awesome, I didn’t know that, that’s pretty great.
[0:27:42.0] DA: I mean, you can still learn that tomorrow.
[0:27:45.3] MN: I’d like to thank both Madelyn and Sam for coming on down, thank you so much for joining us.
[0:27:51.5] MF: A pleasure.
[0:27:51.2] SH: Anytime, you’re the best.
[0:27:54.1] MN: Follow us now on Twitter @radiofreerabbit so we can keep the conversation going.
Like what you hear? Give us a five star review and help developers just like you find their way into The Rabbit Hole. And never miss an episode, subscribe now however you listen to your favorite podcasts.
On behalf of our producer extraordinaire, William Jeffries and my amazing co-host, Dave Anderson and me, your host, Michael Nunez, thanks for listening to The Rabbit Hole.
Links and Resources:
