We had so much fun last time out talking about programming idioms that we thought it was worth revisiting the topic and exploring a few more. To kick things off we talk about the idea of 'bike shedding', the supposed history of the term, and how it can apply to various situations in which something trivial is more engaging than an important matter. From there, we turn to the more common idiom of the hammer and everything appearing to be a nail. We see this problem arising when programmers tend to lean into their own expertise or method, which is not always the most appropriate. We also cover the overuse of refactoring, the detrimental effects this can have, and why rubber duck debugging can be such a satisfying experience. Tune in to hear it all!
Key Points From This Episode:
{{addCallout()}}
Transcript for Episode 263. Circling Back to Programming Idioms
[INTERVIEW]
[0:00:01.6] MN: Hello, welcome to The Rabbit Hole, the definitive developer’s podcast, living large in New York. I’m Michael Nunez. We have a Rabbit Hole roll call.
[0:00:11.2] DA: Dave Anderson.
[0:00:12.5] WJ: William Jeffries.
[0:00:13.8] MN: Today, we’re circling back to more programming idioms. I think we had a good time talking about idioms of the past episode and we are to circle back on some more.
[0:00:26.9] DA: Yeah, we really started to grock this topic, we shaved the yak or two, all the way down to the turtles that are there.
[0:00:37.9] MN: Under boy lotion, who knows?
[0:00:40.7] DA: Yeah, it is kind of hazardous for those animals so, it’s a bit FUBAR.
[0:00:45.8] MN: Oh man, it’s a bit.
[0:00:47.0] DA: That’s the recap. If you don’t understand any of those words, then you can listen to the previous episode.
[0:00:52.1] MN: There you go. One of the ones that we hear often and I have not ever heard this one until I started programming at a professional shop is bike shedding and I didn’t know what that meant. I thought when I heard the word bike shedding, I think it was like bikes would shed like how snakes will snake their skin. I was like, “Bikes don’t do that, I will say rust. What do you mean bike shedding, what?”
[0:01:17.4] DA: Like a lobster.
[0:01:18.9] MN: What does the term bike shedding and how is it used in programming, William?
[0:01:23.8] WJ: The explanation that I heard was that it came from a project where I don’t know if this is a real project or this was a hypothetical project to illustrate the phenomenon but they were building a nuclear reactor. It’s like a power plant, right? Extremely expensive very high risk and wildly complicated and so they needed to agree on whether or not they were going to spend the $200 million to build the power plant and nobody really had anything to say about it.
It was just kind of a, “You know, yeah, okay,” but then there was a bike shed that was also going to be built right by the nuclear power plant and everybody had input in what color should it be, how big is it going to be, how far from the street is it going to be. Because it is just much easier to have opinions about this smaller less important thing, it's easier to grock than it is the actual important thing.
[0:02:20.7] DA: Yeah, I heard that story too although I thought it was about a real life story that happened at Google where they’re like arguing over the bike shed at Google about how many bikes should be there on the campus because they just have all the soft serve machines and whatever but they are not focused on delivering the software, whatever but I think your story is closer to the origin, which I looked at just now and it is actually a parable, I guess, to explain Parkinson’s law.
[0:02:53.3] WJ: What is Parkinson’s Law?
[0:02:55.5] DA: His law, it is called Parkinson’s Law of Triviality, basically stating that the amount of time spent discussing an issue in an organization is inversely proportional to its actual importance in the grand scheme of things.
[0:03:11.2] MN: Oh wow.
[0:03:13.6] DA: Which is a pretty sick burn, but that is definitely something that happens.
[0:03:18.9] MN: Yeah because it is all easy to pick apart the bike shed or the very small minute things, the color of the button or name the variable of this particular third-party or micro service that we want to build versus the actual micro service that we’re going to build.
[0:03:36.4] DA: Yeah, I think it really concrete and painful example of this that I have encountered in my career is when you are applying AB tests as though everything is a nail that needs your AB test hammer, so you can really apply that in a way that bike sheds, all of the details and tries to crowd source and finds statistical significance in things that you could probably just decide and move on with your life.
[0:04:08.9] MN: Don’t be bike shedding, boys and girls, get to the root of the problem and solve that instead. Any other idioms that people want to share? Actually, you called out one that’s really interesting, the “When you have a hammer? Everything looks like a nail.” That you just want to go and back things and it’s like, “Oh is that a problem? Is that a programming problem? Is that a problem that a user wants to solve? We could do it and we could solve it.” It’s like, “Woah, no one add — calm down there Bobby.” You don’t have to solve everything through software especially if these is not asking for it.
[0:04:42.0] DA: Oh yeah, that’s like a much broader perspective of that where yeah, maybe you don’t need to program something. Maybe you could use Excel or whatever.
[0:04:52.4] MN: Yeah, it may look like a nail, no need to use a hammer Bobby, you can cool down.
[0:04:56.8] DA: Yeah, I think Graph QL is my favorite hammer. You can also think of like a specific technology as a hammer. I think React is another hammer that people really love to swing around.
[0:05:09.3] MN: It’s like a sledge hammer of JavaScript front-end frameworks. You’re just like, “Every answer is React.”
[0:05:15.7] DA: Right, yeah. It’s like, “We need a statically generated page.”
[0:05:19.5] MN: To do the thing.
[0:05:21.0] DA: That’s generated dynamically with React components that are all nested in very complicated. And that is not to discredit that hammer or smashing a lot of different things with it.
[0:05:34.5] MN: Yeah.
[0:05:35.0] DA: It’s a very good hammer.
[0:05:36.2] MN: It’s a solid hammer, it gets things done. Any other programming idioms that you want to share?
[0:05:43.2] WJ: Refuctoring is one that I heard recently, which I thought it was great.
[0:05:46.4] MN: Re what?
[0:05:49.0] WJ: Refuctoring. It’s where you refactor something, it was fine until it is totally unusable.
[0:05:56.1] DA: I feel like this might be a neologism. I have never heard of that before.
[0:06:03.7] MN: That is crazy, hold on, so it’s when you refactor something that –
[0:06:07.6] WJ: You just make it worse like it was – I mean maybe it wasn’t that good to begin with but after you refuctor it it’s [inaudible 0:06:13.2]
[0:06:14.7] DA: Yeah, I feel like I’ve done that recently where I just went down this refactoring journey and then my commit message was made things more complicated.
[0:06:25.8] WJ: A lot of times it happens with the best of intentions.
[0:06:28.1] DA: Yeah.
[0:06:30.4] MN: I can only imagine that something like that happens, well, you all are familiar with Enterprise Fizzbuzz?
[0:06:36.5] WJ: Yeah.
[0:06:39.1] MN: Enterprise fizz buzz is a project –
[0:06:42.0] WJ: It’s like 15 files with like a ridiculously complicated direction structure.
[0:06:46.3] MN: No.
[0:06:46.8] WJ: It’s like seven classes.
[0:06:48.6] MN: I think it’s more like a 100 files of classes that exists with test and all sorts of craziness just to do fizz buzz. I think that might be – it must have been a symptom of the refuctoring. Be careful. Don’t go too far off in the refuctoring because that will be – you will end up with a really nested and tons of design patterns that make confuse your developers at the end of the day. Definitely check about Enterprise Fizzbuzz for that though.
[0:07:20.5] DA: I feel like one that comes up pretty often in my experience is rubber duck debugging that it is always kind of one of those really surprising things that happens where you are talking through a problem and the solution just manifest itself. It just happens, you just think of it out of nowhere even though you are trying to explain it to someone or who is your rubber duck or you’re trying to explain it to your rubber duck on your desk or your wooden frog as it were. That is one of my favorite ones.
[0:07:55.7] MN: Yeah and it is always best to have a physical, right? Especially in the world that we are in right now where you may be isolated in a room in a completely different country, William, I am not speaking about you but a lot of people may be in your situation, right? Like you are –
[0:08:12.4] DA: Right, no one else speaks English around you.
[0:08:14.0] MN: No one else speaks English around you but –
[0:08:16.2] DA: Except for you rubber duck.
[0:08:17.3] MN: Except for your rubber duck bro. I mean, you can practice your Spanish with the rubber duck too and I think that that like the idea of going line by line through a piece of code will help you identify the bug that’s currently messing things up in your –
[0:08:32.2] DA: Yeah, maybe it will – the rubber duck will provide judgment to you when you’ve gotten too far with the refactoring. If you explain your approach you may realize out loud that it may not be necessary and there’s actually a psychological scientific thing that happens when you are explaining a problem to a rubber duck or to another person even, even if they don’t speak English where it’s a different part of your brain that’s used to think about a problem and try and figure it out versus explain a problem by like actually verbalizing it and talking out loud, we can kind of use both those parts of our brain to get deeper in the prompt. That’s one of the great things about pair programming or deduct or what have you.
[0:09:21.8] MN: William, do you rubber duck in English or in Spanish right now?
[0:09:25.5] WJ: Oh, absolutely English man. Doing foreign language programming is so hard.
[0:09:32.1] MN: Oh I can only imagine. I can only imagine.
[0:09:35.6] WJ: It makes me really respect the engineers who come from other countries and work entirely in English, it's like, “Wow, okay.”
[0:09:45.6] MN: That’s amazing.
[0:09:46.1] WJ: I think you get used to it eventually. But oh man, you take so many mental cycles to just kind of put the right vocabulary word. There’s none left over for solving a problem.
[0:09:54.7] MN: Yeah, I think that was about a good amount of idioms. I don’t know if we missed any, I am not too sure. But we may need to circle back on more of these idioms. I think these are the ones that we should –
[0:10:05.2] WJ: I think we got all of them. I think we’re good but we didn’t –
[0:10:08.7] DA: Now I want more. One more, no?
[0:10:10.6] WJ: No.
[0:10:11.0] MN: No, I think – I don’t know, I mean, feel free to –
[0:10:13.5] WJ: I think we have exhausted it, there is nothing left.
[0:10:16.1] MN: I think we went through the list and if there are anymore that you feel that we may have missed, feel free to hit up Radio Free Rabbit on Twitter. I would love to hear anymore that we have. If you got them, we’ll share them on the next one.
[END OF INTERVIEW]
[0:10:30.5] 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 podcast. 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.
[END]
Links and Resources:
