On the show today we welcome back our great host, Michael Nunez, from his baby leave! We are talking about refactoring, something that Mike is easing back into after his break. We discuss a bit about refactoring old Java code and what this can mean in practice. From there we get a bit more philosophical and explore some ideas about how to approach refactoring someone else's code with appreciation for the limitations they likely faced. We draw on some wisdom from Sandi Metz and Martin Fowler and remind ourselves and our listeners why good habits are more important than gifted writing. Michael and Dave do their best to internalize these sympathetic ideas and consider the possibility of including their postal addresses and contact details in the code they write! For all this and some more, tune in today!
Key Points From This Episode:
Transcript for Episode 111. Refactoring: Quotes and Experiences
[0:00:01.9] DA: Hello and welcome to The Rabbit Hole, the definitive developer’s podcast, here in fantabulous Chelsea, Manhattan. I’m your host, Dave –
[0:00:08.1] MN: Yo.
[0:00:09.7] DA: Oh, my God. Oh, hey.
[0:00:11.1] MN: What’s up?
[0:00:11.9] DA: Hey, it’s Mike. Yo. Yo, what up?
[0:00:14.2] MN: I’m here.
[0:00:15.1] DA: He’s back.
[0:00:15.3] MN: It's live. We’re live. Yeah. I’m back to work. That’s what happens after the money runs out, would you say? You’ve got to come back to work and pay the bills.
[0:00:27.0] DA: You get all those diapers. Yeah.
[0:00:28.4] MN: Oh, yeah. I got to get diapers and wipes. Food is included, don’t worry. That comes with the mama. Mama’s doing great. A lot been healthy and feeding the baby.
[0:00:38.1] DA: We got to feed the mama though.
[0:00:39.3] MN: Yeah. You got to feed the mama. Mama’s got to get fed. Shout out to my wife, Annie, I love you. Yeah. No, it’s been great to bond with my son. That was a lot of fun. I’m glad to be back.
[0:00:51.4] DA: Oh, yeah. I’m sure it’s great seeing them learn all kinds of skills.
[0:00:55.7] MN: Yeah. He still has to written his hello world app yet, but we’re going to get him – well, I got to get him soon.
[0:01:01.2] DA: Yeah. We’ll definitely tell him about some refactoring, like what was that like When we first make his first hello world, because I want to, okay, we can –
[0:01:08.5] MN: Yeah, we need to refactor some of that – just a little abstraction. Teach a baby how to refactor hello world is crazy.
Yeah, so the topic today as we are on my return, will be refactoring. I think, I've been back for about a week and was looking at some code, one way I find to get more simulated to a code base in a new place is to look at the code and see how I can refactor it and make it more easy to read.
[0:01:38.8] DA: Yeah. Just try and play with it a little bit. Do you try to commit that back in to the code base, or do you just play with it to understand it a little bit better?
[0:01:50.3] MN: I've got a feature to build, so like anything that touches the feature that I'm building, in those files I try to do the refactor. It goes in with the commit. Then people were like, “Oh, that's cool. Yeah, awesome. Thanks. Greatly appreciate it.” I'm at a client and we’re using Java. It was a really cool thing too. I haven't Javaed in five years. I had a finance bank and all sorts of really old –
[0:02:15.4] DA: You got to flex those Java muscles. Some Java 7.
[0:02:20.4] MN: Yeah, it was like Java 4. It was old. It was old stuff. It's really great to look at really good written Java code and then being able to identify like, “Oh, I think this could be refactored,” and try to figure it out and then actually get it and nail it and then your poll request gets approved from the refactoring is pretty great.
[0:02:39.1] DA: Yeah. I guess, seeing a Java project that's well-thought-out. They're not suffering from crazy problems. It's just a matter of writing the solution really well.
[0:02:49.8] MN: Yeah. I think definitely this codebase follows a lot of design patterns that you would regularly see in a Java application, because that's the only way you write Java code, is with using well-versed and well-written design patterns, because when you don't, it's all over the place.
[0:03:07.1] DA: Yeah, you got to do dependency injection. You got to do that strategy –
[0:03:10.2] MN: String a four – yeah, strategy and builder and all that good stuff.
[0:03:13.9] DA: Just blow that dust off the top.
[0:03:16.0] MN: Oh, yeah. With that in mind, being able to refactor was definitely a great way to get more assimilating and get back on my feet when it comes to the Java code.
[0:03:24.8] DA: Yeah. That's a great point. I think buried into your statement also is that you were just for factoring the code that was adjacent to the feature that you're working on. You weren't going all over and rewriting the entire code base.
[0:03:41.3] MN: Oh, no, no, no. Come on. It’s my first week back Dave!
[0:03:44.7] DA: This is like, well, this over here is a stinker, this one's got to go.
[0:03:49.9] MN: Yeah, I smell that cold smell from two tabs away. I'm not doing that. I mean, like I said, I just got myself back to work, work life, family life. It's a little difficult, which one step at a time. One step at a time.
[0:04:03.4] DA: Yeah. Actually, that’s the most practical way to apply refactoring, because you're applying it to something that's going to help you meet a goal. You're going to change the code to make it more easy to understand, easier to read and for you to reason about and then make a change to it, so that it's better.
[0:04:22.4] MN: Yeah. I mean, definitely that is my thought process, as going through this new code, because I haven’t programmed in like four months. I’ve been essentially on vacation trying to keep a baby alive. It’s been kinda hard.
[0:04:41.3] DA: You're not doing exorcism Java drills, or –
[0:04:43.7] MN: No. No. In fact, when I found out that I was learning Java, I was like, “Oh, no got, I've got to brush off the –” What's the name of that book? Oh, my God. Effective Java 2. I know that's an old book. That's an old Java book.
[0:04:57.7] DA: You know, I just heard that they have Effective Java 9 now.
[0:05:01.0] MN: Yeah. No, no. I got the second edition. This I’ll imagine.
[0:05:05.4] DA: Yeah, I got that one too. It’s like, “Oh, have you heard about generics?” I was like, “Wow. The future. It’s here.”
Yeah. I have been thinking about refactoring too. The project that I'm working on for a while now and now those things that I've seen that identify with my first day, I'm like, “I really want to refactor this, but I'm not going to – it's not the right. It’s not the right time.”
[0:05:32.1] MN: They’re not ready. They’re not already.
[0:05:34.7] DA: I keep on hearing these great quotes from different people. Some folks that we work with did a workshop with Sandi Metz and there's all kinds of wisdom floating around in our Slack channel. There's a great quote here that the cost of code is in the reading and not in the writing.
That's something that really resonates with me a lot. You hear echoes of that with other people, like Martin Fowler, says similar thing about any fool can write code that a computer can understand. Good programmers write code that humans don’t understand.
[0:06:09.9] MN: Yeah, because how often are you – you only write that piece of code once, but that piece of code gets read hundreds of times.
[0:06:18.2] DA: Right, exactly. There's one piece of code that I end up finally can I sink my teeth into and refactor. It was code that I had read dozens of times. Literally, it had not changed for a year and a half, since the application was created. It was so gnarled and twisted and it was like, the logic was pulled into itself.
There’s all these if statements everywhere. It’s like, “What is happening here?” It was interesting to take a step back and look at that and try and understand what the real intent was and how to work around that.
[0:06:55.6] MN: Yeah, because as you mentioned, that piece of code existed since the beginning of the application. As things build around it, I guess a developer may have been building around it literally without looking at what that piece of code was doing.
[0:07:11.9] DA: Right. Every piece of code that's added to it is working code, that does what people need it to do. It becomes harder to actually think about changing that code, until you actually really need to. Then it's really hard.
[0:07:28.4] MN: Yeah. Then once that code has a lot of logic around it, then it becomes a lot more hard to refactor. Someone's got to do it. Roll up sleeves and make it happen.
[0:07:36.4] DA: Yeah. Yes. It's been fun. I've been working with our buddy, a friend of the show, Conrad.
[0:07:42.0] MN: Oh, yeah. Conrad Benham.
[0:07:43.2] DA: What up? He's a big fan of refactoring. We've been looking at these pieces and where we need to add new functionality. We're like, “Okay, we're not going to just shove it in here.” You could easily just put it in there, shove it in another if statement. We've been looking for a seam to stitch the new code and in a different class, like write a contract that a method can implement, so it'll take some arguments and return some other thing, pull out the code that's doing that right now and then change it away from all the craziness that's happening in the rest of the world.
[0:08:22.6] MN: Oftentimes, you can jump in and just want to refactor everything. I think it takes patience to look at something and call to refactor and know how to, right? Because you can as you mentioned, you can refactor and then just shove it in the same file, or class, but is that really the refactoring that is necessary, or is it much bigger than what that is?
[0:08:46.5] DA: Right. It's like, you can add another and helper method or something, so your 250-line class is now getting close to 300 lines. When maybe there's three different things that that class is doing. We just need to get our scalpel and start doing some surgery. I was going to say ninja sword, but that's probably not too elegant. Probably not going to end too well for you.
[0:09:14.5] MN: Yeah. I have another quote to read. “Programs must be written for people to read, and only incidentally for machines to execute.” That's Harold Abelson, Structures and Implementations of Programs.
[0:09:26.2] DA: That's a classic.
[0:09:27.7] MN: Yeah. Again, this just shows that you can write that piece of code once, but it probably gets read many, many, many more times than it has been written.
[0:09:38.1] DA: It's doing its job. It is being executed by a computer but every time someone new comes on and they to relearn how all the fiddly bits of that really complicated 300-line class works, then you're going to lose some time.
[0:09:54.1] MN: Yeah. The other quote is, “I'm not a great programmer. I'm just a good programmer with great habits.” That's Martin Fowler. No, Martin Fowler, I think you’re great. I think you’re a good programmer. He just brushes his teeth. That’s all he does.
[0:10:08.8] DA: That’s all he does. Refactors well. Let’s just say –
[0:10:11.2] MN: Imperfections every day, twice a day. Yeah. You're a great programmer, but I understand what you're going here. It has to do with refactoring, how to refactor as you mentioned before and the ideas of refactoring.
Part of the reason why I wanted to talk about this as well as it was a quote online that I've read way too many times. I think Dave laughed, because he's never heard of it before. I'm sure, some of our listeners may have. Something along –
[0:10:38.1] DA: Before we jump into it, that quote from Martin Fowler, I really like that, because it's kind of a bold statement. Like, “Yeah, I'm great. I'm just good, really.” It's also humble because you think about how – it's like, “Oh, well. This person's a rock star. They're a super athlete or something. They have something like innate talent."
But it's hey, actually this is just learned skills and practices that. If I do this rigorously, then I'll be fine. If I stop doing it, then I'm just going to be a mess.
[0:11:16.8] MN: Right.
[0:11:17.5] DA: It's so much more that we could cobble it together. They could take all this stuff and just mash it together and make it work in a big ball of mud. That person is not me, for sure.
[0:11:30.2] MN: Not me either. Definitely.
[0:11:32.4] DA: We'll just keep brushing our teeth.
[0:11:33.5] MN: Yeah, twice a day. Yeah, the other quote was, “Code, as of the person who ends up maintaining your code is a violent psychopath, who knows where you live.” Which when you think, I probably would be dead by now.
I remember writing really old code as a young developer starting new, skin in the game. I wrote some crap. I probably still write some crap and I try my best not to write crap. If there was a violent psychopath working, first off, why are you hiring this person? Secondly –
[0:12:12.8] DA: Can you imagine, it’s like your Git commit had your address and your phone number on for a single commit?
[0:12:19.1] MN: I get prank calls. I’m, “Why did you write this?”
[0:12:21.2] DA: I guess you got your email in there, but nobody –
[0:12:24.2] MN: Nobody's going to follow your home based on your email. Yes, all right –
[0:12:29.0] DA: Oh, that would be sweet though. If you see a nice commit, you just email and be like, “Hey, I just want to let you know.”
[0:12:34.0] MN: This was good stuff.
[0:12:34.8] DA: This is good stuff.
[0:12:35.7] MN: I'm going to do that. If I find a good code, I'm going to check the git commit, git blame. Git blame makes it feel they did something wrong. I want to do the nice version of git blame.
[0:12:45.5] DA: That’s what the psychopath does.
[0:12:47.2] MN: Yeah, he git blames.
[0:12:48.6] DA: He finds your home address.
[0:12:50.5] MN: Exactly. I'm going to git blame, but then I'm going to send them email, “Hey, I was reviewing this code. That's pretty nice. Good job. Good job.”
[0:13:01.0] DA: As I said, we're not psychopaths. What do you do if the person is a psychopath in a psychopath situation?
[0:13:08.3] MN: Oh, man. I don't know. I mean, this quote is kind of ridiculous, because I haven't heard of an incident where a violent psychopath has killed someone, because they wrote a nested if statement. That's just not – it’s highly unlikely that this is what's happening and it's highly – this shouldn't be the way you code.
[0:13:30.1] DA: I’m going to give a shout-out Erica.
[0:13:32.0] MN: Yeah. That shout-out was a thread – the tweet started by a GeekSam, who wrote that they’re over the whole code, like there's a violent psychopath who's reviewing your code or whatnot.
[0:13:48.2] DA: They're closing that chapter of their life.
[0:13:49.8] MN: Yeah, exactly. It obscures another perspective of your work and express kindness and care for yourself and others. It's just a thread and there was another reply, which resonated with me more which is the following, “Read code as if the person who wrote it knew what they were doing, but were operating under constraint with the context you're not aware of.” I felt that quote is much more better than the crazy psychopath one.
Because we’re constantly reading code and we can always say, “Oh, my God. This is bad. We need to refactor it.” It wasn't that I – I like to think that it wasn't that person's intention to do bad code. Imagine waking up in the morning, “I'm going to write bad code today.” I don't think people do that on purpose.
[0:14:34.0] DA: Right. Or sometimes you try to refactor something with all your might and you just can't get it to be any cleaner. Then you just take a step back and you're like, “Oh, my gosh. What if they were right? What if they got it all right?”
[0:14:48.4] MN: Yeah, exactly. Yeah. That can also happen. That tweet was by Kerrizor. I thought that that was just a much better way to look at refactoring when you review code.
[0:15:00.8] DA: How cool. Yeah, I'm going to like and retweet that.
[0:15:04.6] MN: Yeah. I thought it was dope. It's been evident, even in the conversation that we've had that it's never about what was written. It's about what you read. Because that's when we're factoring comes in, when you read the code. If you read the code and you have – before you even have any bias towards that code, you would think, “Hey, I don't know the context. This person could have been under the gun and needed to be deployed yesterday,” like we've all had to deal with that stress.
[0:15:30.0] DA: Oh, sure. Yeah.
[0:15:31.9] MN: Always be nice when you read the code. Don’t be the psychopath. Just be nice.
[0:15:37.4] DA: Yeah. Send flowers, not a mail bomb.
[0:15:39.3] MN: I think in that thread – hold on. If you go to that thread, I think someone's like, “I wish someone sent me a postcard. That'd be nice if I got a postcard for writing kindness code.” I'm like, “Oh, yeah. I guess, if we had the person's address, either you get postcards or you die.” I don't know. One or the other.
[0:15:57.6] DA: All right. I’m going to start putting my address and all my equipment in messages. We’ll just see what happens. We’ll see what reality we’re in.
[0:16:05.5] MN: If you guys see Dave Anderson's address, please send him flowers.
[0:16:09.8] DA: It would be nice.
[0:16:10.8] MN: Please, or a postcard. Do a postcard.
[END OF EPISODE]
[0:16:14.2] DA: 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 like you find their way into The Rabbit Hole and never miss an episode, subscribe now however you listen to your favorite podcast.
On behalf of our producer extraordinaire, William Jeffries and our amazing host, Michael Nunez who is out being a dad and me, your host, Dave Anderson, thanks for listening to The Rabbit Hole.
[END]
Links and Resources:
