SE Radio 512: Tim Post on Rubber Duck Debugging

Tim Post of echoreply.io discusses rubber duck debugging, a way to wrap your head around problems and solutions. SE Radio host Felienne spoke with Post about rubber duck debugging, and how it can help you find answers to complex problems. The show also explores the role of documentation in problem solving and how techniques from rubber duck debugging can help in creating better documentation and in executing code reviews.

Show Notes

Related Links

• Pass Nothing from Javascript to VBScript in IE9
• Blog post: Rubber Duck Debugging & How to Use It in Documentation
• The Pragmatic Programmer
• Can gcc accurately catch useless conditionals?
• Tim on Twitter: @tinkertim

Related Episodes

• Episode 494: Robert Seacord on Avoiding Defects in C Programming
• Episode 367: Diomidis Spinellis on Debugging
• Episode 283: Alexander Tarlinder on Developer Testing
• Episode 278: Peter Hilton on Naming

Transcript

Transcript brought to you by IEEE Software magazine.
This transcript was automatically generated. To suggest improvements in the text, please contact [email protected] and include the episode number and URL.

Felienne 00:00:19 Hello everyone. Welcome to Software Engineering Radio. My name is Felienne and today on the show with me, I have Tim Post. Tim is the Systems Programmer who set his site on the human components that go into software. He was formerly the Director of Community Strategy for Stack Overflow and Principle Developer Relationships for Swim. He is now on his own adventure with his own developer marketing company, Echoreply.io. Welcome to the show, Tim.

Tim Post 00:00:44 Thanks. It’s great to be here.

Felienne 00:00:46 So, you say you have your sites on the human components of software, and that’s really nice because that’s the topic of today’s episode as well. More specifically, we will talk about Rubber Duck Debugging. And of course, we’ve talked about debugging on the show for a number of episodes. We had 367 on Debugging, but that was I think, a different type of debugging, right? Because rubber duck debugging is something very specific. Can we start the episode by giving your definition of rubber duck debugging?

Tim Post 00:01:16 Iterating over your problem statement and how you deduced it until you effectively come to the solution to your own problem. It was a term that was very popular in the mid to late 90’s, in the programming scene because we didn’t have, what a lot of people just take for granted today, which was the Internet. It was still Arpanet back then. And even at the universities, if you wanted to post on an internet forum, you had to have crazy levels of access. You needed to know how to use a VAX. You needed to do a lot of stuff. So we couldn’t just Google error messages or things like that. We would have to sort of, sit there and go frame by frame through the problem that we experienced and look at every single piece of evidence that we had there until we eventually stepped through the problem enough to arrive at a theory as to why it happened, and then thus a solution that we could try and it was generally right.

Tim Post 00:02:15 That became popularized again when Stack Overflow became hugely popular in software engineering circles because on Stack Overflow, there’s a thing about duplication. Some duplication is good, provided that you’re actually asking a question in a completely different way. Asking a question in the same way, multiple times to a group of developers after going through something that we call the eternal September, is usually a bad idea because you’re going to get a poor reception because they’re going to ask you if you search first. So what happened was people were so reticent to post questions on Stack Overflow because they weren’t sure if they had searched enough. They weren’t sure if they had gotten enough information. They weren’t sure if they had actually done the thing that was the golden egg there to get a question to go viral, which was to give all of the information that was necessary.

Tim Post 00:03:10 So in the course of trying to write the perfect question, that would get a perfect answer. Most people had collected enough evidence on their own to have actually solved their problem and produced this wonderful artifact with lots of great formatting and stuff that never actually got posted because they had already figured it out. That’s what was known as rubber duck debugging. There’s some, I don’t want to say controversy, but terms like this tend to come in existence. There’s no origination for them really. People simultaneously realize that they’re doing something that helps. The person that first taught it to me was talking to, it was one of my first mentors her name was Linda. She knew more about token ring networking than, than any human being would ever want to know. She would talk to the pictures on her desk until she would figure out why something with token ring was. And if you have ever worked with token ring networking, all of the millions of things that could go wrong with it. And that’s how I learned it. So yeah, there’s the many different iterations of it over the years, but it, it comes down to that. It’s just really realizing that you had the answer the entire time. You just hadn’t really thought about the problem yet.

Felienne 00:04:16 Interesting. So I think the first thing you said was iterating over the problem statement. Maybe we can pick that apart and talk about those two things, separately, Because firstly, there is the part problem statement, like what is the problem? How do you define that? What is a problem statement? How do I refine and iterate over it? What is even a good way to express this problem statement that some people need do it vocally. They literally talk to their photos or to their rubber duck. Other people might do it in a written way or even in codes. How do I shape that problem statement?

Tim Post 00:04:51 What’s even weirder about the question is for every different domain, you have to do it different. You might be really, really good at stating a problem in programming, but horrible at talking to your doctor. So you might be able to say that, when I turn all of the optimizations on and GCC version X dot Y dot Z, and I look at the intermediate output, I can tell that this isn’t being applied and I’ve done this and that and the other, but you go to the doctor and you’re going to say this hurts. And number one, I mean, we understand that the problem statement is whatever you understand it to be at the time. It’s not really a statement until it’s, a bit more coherent. Most problem statements turn are, start out at least as just raw brain dumps of code, compile, not Java problem. That’s what goes through your head. And when we have these things, we often experience a sort of heightened sense of anxiety that compounds it a little bit more, but minimally returning to the question. If we look at a problem statement is the minimum combination of words and artifacts that allows someone to understand your problem and ideally reproduce it.

Felienne 00:05:58 Great. Yeah. I think that makes total sense where you say, well, you need a bit of domain knowledge. Sometimes also, even in the software domain, I like this analogy of going to the doctor, but even in the software domain, sometimes you’re, you are a user of software and it crashes. And then you report that to the owner of the software and you just say, well, it crashes. I have no better hypothesis for you. Here’s a screenshot. So clearly I like it that you’re saying you really need domain knowledge to come to a problem statement, which sometimes is part of your problem, right? Sometimes you have to, you get an error message with the words you don’t really know. And then your first step is finding more information. So that’s, that’s great advice. Then let’s do the other part, right? The, the iterating over, because sometimes you can be stuck in a loop, right? Sometimes you’re like, I have this problem and I’m thinking about it and I’m thinking about it. Maybe I’m talking or writing or Googling, what is iterating? How do I make progress there? How do I know I’m making progress?

Tim Post 00:06:52 The thing that you have to remember is you’re constantly making progress. You’re just not aware of where you’re making it. The process of being stuck. The process of struggling itself is important and it needs to last for some arbitrary amount of time, but for something happens and all of a sudden your perspective shifts just a tiny little bit and something all of a sudden is there that wasn’t there before. So most people think I’m stuck on this when they’re thinking about it. When in fact they’re making progress, it’s like, you have to wait. I remember Megamind the movie, if you’ve ever seen it, where they’re in this evil fortress and they’ve managed to aim the sun at an opponent and they’re going to vaporize them with the sun and they have a satellite that’s going to do this for them. And the minion is like well, the weapon has to warm up sir, and then the Megamind is like wait, the sun has to warm up? And that’s the thing with how humans look at themselves cognating.

Tim Post 00:07:51 If there’s no artifacts of things being accomplished right away, no work is getting done. And that’s one of the things that you have to, when you’re problem solving, you have to put that out of your head. And that also ties back to, you can’t always say calm down. That’s one of the worst things that you could ever say to somebody that’s in a state of duress or upset. But you can say, this is going to go faster if my heart rate goes down a little bit and you can start working. So if it’s not coming to you, you have to start working on, okay, am I in a state where I can actually solve this problem? So you’re still making progress no matter what something is changing, you’re just not aware of it.

Felienne 00:08:27 Yeah. I think that’s a really good takeaway. A bit of a comforting thought that people think, right? Oh, I’m stuck, but this is okay. This is part of the process. I am learning, even though I’m stuck.

Tim Post 00:08:39 We struggle as part of the process. That’s how we’re born. I mean, well most some of us anyway, some of us are not necessarily but most of us have to do quite a getting out of there is not easy. The next thing that you do is you have to give yourself credit. You realize that you’re understanding, or at least you’ve ruled out certain things in the problem. And you can make a good bit of progress by this by saying, look okay. I know that it is none of this stuff whatsoever, because if I take that completely out of the equation, then you start separating other stuff that couldn’t possibly be it. And this may not look like you’re making progress toward a solution. But what you’re doing is you’re helping your brain focus on, you don’t have to continually worry about, did I check my like- when you’re getting ready to leave your house, did I turn off the coffee pot?

Tim Post 00:09:24 Did I turn off my, did I have, do I have my keys? Do I have this? You have to break your brain out of that sort of loop. And eliminating things is often a great way to do that. And then eventually what you’re going to do is you’re going to realize that in front of you, you’re sort of isolating the problem. And if it’s code there’s, it’s going to be certain suspect files. And in your case, it might even be three different repositories for three different microservices these days. The other thing that’s important to note, and we should probably say somewhere is the ability to actually conceptualize the entire breadth of problem spaces and software engineering in Kubernetes is quickly exhausting. Our systems are getting bigger than we can physically conceptualize in our heads. We can’t keep track of everything that’s going on.

Tim Post 00:10:08 So again, how we approach this is more about not like results, but technique. So you just really have to keep chipping away at it and being really cognizant of what changed, if anything. And then there’s also, you have to set a time out, at some point the time to live for the struggle is over and you have to ask somebody. So progress here is you need to know what your next step is going to be. And you need to know when that is going to be. And it’s look, I’m going to mess with this. I’m going to give this three more minutes. And if I don’t get forward progress toward a solution toward actually checking this code in, that’s it. So time boxing is also a way to make forward progress because maybe you’ll be looking at a different error message. That’ll be great.

Tim Post 00:10:50 Or maybe you’re talking to someone else about the error, or maybe you’re looking somewhere else, but whatever. Or maybe you just decide, look in five minutes, I’m going to put this away until tomorrow. If that’s a possibility, I mean, that’s often a luxury whatever’s happening. If you get to the point where you’re completely disillusioned, you can make progress happen. But ideally is you’re just building on the, the next thing that you, discovered the whole area of the process. The biggest thing is just not getting discouraged and also realizing that we’re at the precipice in the tech that we’re using, where we are, the generation, we are the workforce that is going to realize that our designs have exceeded our capacity to fully understand them. And we are the ones that are going to have to make the tooling to make the next generation of problem solvers equipped. So that’s something that people, especially engineers that are working out there right now in the modern Kubernetes workforce, they really have to keep this in mind because it is 800 times harder for them than it’s for even people that are, hacking at modular kernels. And that sort of stuff, what they’re doing is crazy levels of complicated.

Felienne 00:11:54 So great. So there was so much in that answer, I’m going to take three things. So rush three things that I took away that are really, really valuable starting with that last point where you say sometimes oftentimes the complexity is just bigger than what fits in your brain. I really like that. I think in many cases, this is true. Secondly, you also said time boxing, right? Sometimes it is good to say, okay, 10 more minutes, one more hour, whatever. And then I’m going to, there, there are other open issues in the repo. Let me just do something else and leave this for a bit. And then the first thing where you said I also like, that’s like this process of elimination. I don’t know what, what the problem is, but let me see am I connected to the internet? It’s my database up?

Felienne 00:12:34 So there’s always some things you can check and maybe it’s not that, but it would be a pity if there’s nothing wrong and it’s just your internet connection, right? So I also like this that you have to sort of sanity check a checklist. Is it this, is it this, is it this, then maybe you’re still not solving virtual problem, but at least you’ve gathered some information. So I was wondering if you maybe have a concrete example, you mentioned the token ring in the beginning of the episode of your former colleague, do you have nice story of a problem where you were like super stuck and then you did rubber duck debugging and it’s helped?

Tim Post 00:13:07 I do actually, in it’s on Stack Overflow and I can search for it right now.

Felienne 00:13:11 Oh cool, we can totally add that link to the show notes so that some people can read along.

Tim Post 00:13:15 This is one of the first ones that went viral. I’m still a community leader at Stack Overflow. I’m no longer an employee there. I’m still an elected moderator, I’m one of the first. I’m going to be, I’m part of the carpet there. This might have been almost 10 years ago. The original post is actually deleted. So I’m going to give you a screenshot that you can share with your users as well. Any 10K user on Stack Overflow can see this. It has a thing here, use this with interpretation over 10,000 can see deleted posts so that they can know that they’re deleted and vote to undelete them. But essentially, if you don’t have 10,000, it’s a 404. I will provide a screenshot for this at the end of the call. I love all programming languages, even the esoteric ones, like ‘fainbruck.’ (I don’t know how many bad words I can say on the podcast, but. . .)

Tim Post 00:14:01 Every single one of them has some intrinsic personality to it, which I find valuable. So, I love poking around at them. Visual basic is no different. I would never use that to program a toy for a toddler, much less anything else, but some people unfortunately have to trade their labor for money every day. And you don’t always have the luxury of refusing. So this is someone that had to work in this custom VB framework that couldn’t get anything to happen. I’ll read the question out loud. I have a framework written VB script inside some function of this framework, parameter of the function is checked for nothing, but I can’t pass nothing to VB script in IE9. And in greater than nine, no, nothing, nothing in IE9, nothing, nothing, nothing. Anything less than IE9 it’s there. How can I, I don’t know, it’s very late. And then finally, and the author’s name is Mitchell. And Mitchell if you’re out there, I just happened to see him editing this one day and he edited the question and eventually answered it. And he said, “I found the answer: quit my job and found a better one. That’s the answer to the question.”

Felienne 00:15:08 Yeah. You can see the frustration in their eyes. In IE9, nothing, no, nothing. It’s just that he’s so frustrated.

Tim Post 00:15:16 Nothing, nothing quit it. Quit the job, find a better one. That was his answer. And it got 22 up votes and it got flagged for moderator attention because it’s not really an answer. Well, it is an answer to the question, but it’s not technically verifiable; you will not have that problem anymore.

Felienne 00:15:30 If you just quit your job.

Tim Post 00:15:31 He actually got a couple of, apparently there’s some other people that are condemned to this sort of hell. He actually got some good answers there. So it’s an example of, at some point, cutting your losses obviously, and I think Mitchell’s now gainfully employed somewhere else where he’s not so IE9. So that kind of dates this back to, I think 2012, yeah? That’s really a good example. And that there’s plenty of others. And on Stack Overflow, generally it’s always acceptance like you have a typo, or you forgot a semicolon, or there was just this thing that it is so unlikely for. This was not a problem in program. This was synthetic sugar, or this was something else. Or there would be things like, people cause infinite recursion in jquery. And they were like, why does this crush my browser, this sort of, kind of poking, it’s a cherished part of agriculture, even when things aren’t necessarily breaking, they could be broken in theory.

Tim Post 00:16:26 And how would you fix it if they were? So, we go and we mess around with that sort of stuff. And that’s how you find, I think really the most interesting instances of people, essentially what you’re doing is you’re teaching yourself. You’re being your own mentor by just spelling it out and thinking about it. Logically, I think we also, the more we get into the code, the more we begin to understand it, the more the dopamine starts and a lot of us really follow the dopamine so to say. The more you get hooked on a problem, I think that’s also when the iterative approach really applies because you really, like trying something else, that’s almost as good as like having another cocktail as far as the rush that it gives you. I think that also plays a big role in how people apply it to.

Felienne 00:17:09 So let’s go back to that mix Stack Overflow example, because I’m not sure I’m really grasping the rubber ducking in here. So you think by formulating this question, he came to the conclusion that he needed to quit his job, or was there also some cold content that he reached?

Tim Post 00:17:26 Exactly. He formulated this. What he eventually did was he said, it’s just not possible to do this. And he basically proved that to himself. Or if it is possible, it would require I think an investment that he just wasn’t willing to put into it whatsoever. But he did through his exploration, his open exploration of what he was doing. People were actually able to come up with solutions that might have worked at the time. So rubber ducking is sometimes you pass it off to someone else. You often see evidence of this on Stack Overflow where people post almost a solution in a comment? That means they’re thinking about it out loud as well. And sort of looking for it, validation from it. So platforms such as this, where developers are encouraged to just kind of fire one off the hip, and there’s even some extrinsic motivation to do that. If you might be right, you can get some points for it, you could see it actually happening live on the side if you watch the new question feed sometimes.

Felienne 00:18:25 So let’s also consider new examples. Are there also situations where you would say, well, if you’re stuck in such a way, then rubber duck debugging is not going to help you, or is it always a good choice?

Tim Post 00:18:38 You can’t, at some point you could conceivably — I could go outside and learn how to mine for iron and eventually build a car and drive over to your house. But I couldn’t rubber duck my way to your house. If I had to drive there to get it, I had to be in a car and get there. At some point, you realize the absurdity. It’s just “yes, I could figure this out entirely myself.” In theory, at least, if I was given a few hundred years, I could get to the bottom of this problem. And I think that’s also where we are going to run into problems as complexity continues to go up into the right, because we used to be able to look at any practical programming problem, you could look at it in a depth-first perspective, in a breadth-first perspective.

Tim Post 00:19:25 So, essentially how wide is the lake or how deep is the lake? And with microservice proliferation and separation concerns, and the way that especially node projects are starting to become structured with different domains and things like that — looking at it, visualizing it in your head, breadth-first is almost near impossible. It’s harder to, I think, know right away if you’re going to be able to get your way through it. Like, a good challenge would be just cut yourself off from Google and try to solve it — or cut yourself off from the internet completely and try to solve something. Try to write a functional piece of software using only the documentation that’s shipped with whatever you’re using. Only the book. You only have the manual, and see if you can do it. You need to have a lot of experience to be able to confidently say, I have been forced to do that enough times and I was able to do it. And yes, that it is indeed possible. But at some point you have business goals, you have a job, you have a life, you have work-life balance. You have sores in places where you’re making contact with your chair. So get up, you have to do it at some point, I think it becomes just like the sunken, you have to be able to give up on it, and time boxing and things like that happens.

Felienne 00:20:44 Yeah. And that’s where the time boxing comes in, I guess, where you have to say, this is enough.

Tim Post 00:20:52 Certainly as you begin to get into a certain role and you’re with, and you can start, problem sort of take on a bit of an aroma, a bit of a smell. Like this smells like something that’s going to take me all week, because it has these three characteristics that tend to mean all week. But really off the top of the head, you have to just say, what’s the cost of this problem? What is it holding up? What would it cost if I just do it in a different way where I’m not going to run into this particular problem? Those sort of things, you have to be thinking about that the entire time that you’re doing it and not because you want the guilt of, oh my goodness, my thing didn’t work, or it has a bug or something like that. It’s just how much energy is required to get to the end and always choose the shortest path. Or at least as far as you can without taking shortcuts and doing dumb stuff.

Felienne 00:21:39 Okay. So I think we talked about like the goals of rubber duck debugging and the process in general, let’s go a little bit more concrete. I am stuck. I have a problem. Help. What do I do? Like, what is the checklist or the plan or the approach? What can I do to get started? Is there like a template that I can fill out?

Tim Post 00:22:02 We actually used that analogy so many times when people were waiting for support about Stack Overflow. We would cut them off from asking questions because they were literally asking question for every step in every task that they were given to do during a day. And it’s not that people don’t want to help you, it’s that you’re getting a paycheck for something, help you a little bit more. That is the first thing is you need to be able to sit down and answer the question. What am I doing? What is the goal here? That is the very first step that’s what kind that gets you cognizant of the fact that you need to time box it a little bit too. What is the goal here? The goal here is I check this code in by 3:30, so it gets through the CI server by five, so it can ship by six.

Tim Post 00:22:43 That’s the goal there. So that’s where you want to start at that sort of high level. You want to start asking the basic questions that Colombo or anybody else would ask. Get in there and gum chew a little bit and just say what isn’t working. Okay. How do I know that it’s not working? Cause I get this error message. Why am I getting this error message? That’s what happens when you try to, de-reference a type pun pointer? What is a type pun pointer? Okay. Problems. I learned something. Okay that’s type punning and I can’t do that on this platform. And you would continue to do that until you start to break apart the problem into sort of smaller problems or different areas of responsibility.

Tim Post 00:23:29 So, is this looking like it could be that my compiler is wrong? Should I be going that direction? Does this look like there could be something going on in this library that I don’t understand? Should I be going in that direction? Do I not understand what I’m doing in this code at all? Should I be stepping through it line by line, reading it out loud that often helps too. If you step through, especially if you have a lot of conditionals or switch statements or state machines or things like that, actually audibly saying what you assert them to be or where you think they should be, versus reality can often be something there. So bringing it into another dimension is often helpful too. Doing what I do if your viewers could see, which is talking with my hands a lot, is another way to bring it into another dimension.

Tim Post 00:24:13 Or you could just start writing it out in paper. I know a lot of people don’t like to use dead trees like that, but if you, it can be helpful or you could use your drawing app. But getting it out of the 3D or 4D space in your head and into the physical world where you, it becomes a subject to you? Does something to help you solve the problem. Finally, you’ve also got to realize as programmers, we like to be something better than the sum of our experience, right? We like to be the person that struggled through doing all of those things that taught us all this amazing stuff. Plus the unique thing that we bring to it. You’ve got to be constantly treating problems as opportunities to learn something or to study something or to go off in a direction that you weren’t there before.

Tim Post 00:25:04 So sometimes when you’re time boxing something and you just like, this is really something that I’ve got to master, or this is something that I’m going to spend a hundred hours, 10 minutes at a time doing this. Or I can spend two hours really thoroughly getting to know what’s going on here and save myself a ton of time. So, at the time boxing phase, you got to kind of think about that too. Like what’s my investment in the problem. And what’s my investment in me here, as I’m trying to go through that and do I have a, there’s something that I like to call an afgo, which is “another freaking growth opportunity.” Can I have an afgo? Is it possible? That’s something you’ve got to ask yourself when you do it too. Yeah, it’s just about also being gentle with yourself.

Tim Post 00:25:47 And I think as engineers, I think it’s part of the very homogenous nature of the industry from the mid 90s to just recently, it’s still that way. But we seem to frown on ourselves when we don’t know something. And this whole career is about not knowing something and wanting to know more. So I don’t understand why people get all bent out of shape when something doesn’t work or when something’s doesn’t compile. Every great idea I’ve ever had has been an accident that came from a bad idea. So that’s the other thing that I’ve got to tell people is, we have to lighten up a little bit and do things. It’s not so much remembering being young and struggling and stuff. It’s giving yourself permission to go back there and experience it again because it makes you a more well-balanced professional and adult. If I’m honest, that’s true too. You really have to do that. People take themselves way too seriously at the moment.

Felienne 00:26:44 Great. Again, I think there were three things in there that I will take away from this. And the final thing about the permission to learn, right? Where I like that, that people say, well, maybe this what I’m reading now, maybe I’m learning something. Maybe it’ll not help me solve the problem, but at least this is a growth opportunity. I can learn something about this framework, about this tool. So that giving yourself permission to learn something in the context of a problem, I really like that. You also said that it can be a really good idea to get the problem or the solution or the partial solution out of your head and onto something else, like paper or the whiteboard code. And then the first thing that he said, I also very much like that where you said, well, one question leads to another question, right? The first, maybe the question is why doesn’t this work? And then this might lead to a smaller question like, why isn’t this class initialized, right? Why is this, no I would not have expected this. And then you still don’t have the answer. But if you have one question that leads you to the next question, then at least you’re gaining information. So I very much like that as well.

Tim Post 00:27:47 Another good example was, and here’s one that it was a live question that I asked on Stack Overflow as a seed programmer. And it is because my brain was incapable of saying that doesn’t quite look right. I had a program that was leaking memory on an embedded system until literally it just overflowed. And I spent almost a week trying to solve this. And what had happened was I used a semicolon on the end of a conditional statement, which basically meant that everything that followed it wasn’t a condition anymore, just ran all the time.

Felienne 00:28:21 Ah yes.

Tim Post 00:28:23 And my compiler happily do that.

Felienne 00:28:27 Yeah, sure. It’s a valid code.

Tim Post 00:28:30 My compiler was like, wow, far out. I really like that. Can we do that again? And I was like, I’m a terrible programmer. This is one of those instances where you can do everything right and still don’t. I mean, it’s just going to take a week of space before you come back to the problem and you actually find it. So at some point you’re just not meant to know the answer to this problem right now. It’s just the way that I think about it. You’re not capable of seeing it. There’s some sort of cache going on or something? Always blame caching also. Every problem it’s always caching. There’s something going on that no matter how many times you look at this, you’re not going to see the problem because you’re not going to see it the way it really is. This is also experienced by people that climb Everest and other places, people that trek out in Siberia, you lose all sense of direction in everything because everywhere you turn, it’s just white, everywhere.

Tim Post 00:29:31 Or in the desert, it’s just like sand everywhere. Even if your IQ was instantly three times as much, and your vision was suddenly perfect and your chair was suddenly comfortable and the room was suddenly not cold anymore. And suddenly you had an extra hundred thousand dollars in your bank account, all of these things, they’re not going to make you solve the problem any sooner than you’re just going to otherwise. And one day you’re just going to notice it. So I think that’s also the other thing that we have to come to with is, you really have to figure out the investment in advance of what you want to do when you hit any kind of problem, no matter what kind of solution you want to do. Whether it’s rubber ducking or whether it’s, I want pay someone to research this for me and figure this out, cause I do that too.

Tim Post 00:30:19 I don’t have time to chase every problem in software engineering. I pay people to do that. And at some point, it’s what we call R&D and we don’t choose when we’re going to do the R&D sometimes the R&D just happens when you’re in the middle of giving a demo with the 5,000 people watching at a conference and something just doesn’t go right. And you have to do it there. And I think as an industry, as a whole, I think we should be a lot more celebratory of that instead of like snickering or laughing. Because again, this is what happens to us. This is what happens to humans. This is what being alive and having to show a skill is like, and we should be celebrating these occurrences a lot more because that means we’re more welcoming to these sorts of things. And we have less bugs that just, go unfixed forever because no one wants to touch them because they don’t want the shame. They don’t want, the cheese touched like Diary of a Wimpy Kid. You don’t want to be the last person to touch that bug ever. I think also we need to change the culture a bit.

Felienne 00:31:21 Yeah. I think both points that you’re making again are very good. Firstly that sometimes you are not too meant to solve the problem now. I think we’ve all been there or you’re like, you’re knee deep in a bug, but it is absolutely dinnertime. You’re so hungry. You’re like, okay, never mind, I quit. And then you sit down five minutes and then you have the answer, right? Just because you allowed your brain to take a break. So I think that’s proper advice. Sometimes you have to let it rest.

Tim Post 00:31:50 The parent company that cofounded the marketing company that I’m currently running does a lot of ransomware responses. And it happens way more than you think. It happens a lot more in the medical and financial sector than you think. Almost every time that they had to respond to malware that they thought was like out of circulation or stuff that hasn’t really coming up anymore? It was because someone had to go to dinner and checked in a really botched workaround for something that was worse than the something to begin with. It’s not only that, it’s dangerous. We feel like parents to our problems. Like we are the ones that have to raise them and solve them and put them through college. I don’t want to put my parents through college or my problems through college. I want to give my problems to someone else or just let them be on their own to begin with. So that’s something else to consider too.

Felienne 00:32:47 Yeah, I think that’s again great advice. So let’s talk about different programming languages or systems because you mentioned node I think, and you mentioned Kubernetes? Like are there some situations where rubber duck debugging is more helpful or less helpful, certain languages or platforms or frameworks or certain classes of bugs where it may or may not work?

Tim Post 00:33:13 I think it’s a good first, as long as you fail fast, it depends if you’re doing incident response, then people that do incident response at four o’clock in the morning, took everything I said about calm and give yourself the opportunity and stuff like that. And they’re like I want to go back to bed. It can be your first thing. It’s usually something silly. You could go on that route, but it would really depend. I think it’s not so much a prescribed solution as it is a technique to figure out what the right approach would be. I think it’s more useful algorithmically when you have time to step through it and experiment and study and change the input and change the output and all that stuff. If you’re thinking on your feet, honestly, I’m fully aware of what it feels like to have the answer, but not know how you came up with it.

Tim Post 00:34:06 So, I tell people mostly trust your instincts in that kind of setting and just do what you think is right. If you’re really confident, there’s a reason for that. It’s just not apparent to you why you’re that confident in a situation. There was a time at Stack Overflow the database server went down and Sam Saffron — “waffles” — just pulled this script to rejuvenate the database from ashes like a phoenix. That was absolutely bonkers. And they let him do it because he was like, I know this is going to work. And he talked about that on ‘this developer’s life.’ That’s absolutely what you have to do when you’re in the moment. You have to trust your instincts and you have to get those instincts. You want to put yourself in a position where you’re scared, where you have to respond to that stuff where it’s only you and that’s one of those. So that’s it. Other than that, I think it’s just like any other razor that you would apply. I think Occam’s razor is popular. Hanlon’s razor these days is really popular: Never ascribe to malice that which can be explained by people just not adulting correctly. Then talking to yourself, sometimes there’s just nobody better to talk to. Or ask. Ask someone that knows, and always ask yourself if you know the answer first. I mean, you don’t know unless you ask.

Felienne 00:35:23 So, let’s talk about documentation and, specifically, I want to talk about documenting things you find while rubber duck debugging, right? So, you are asking yourself all these questions and maybe you stumble upon different interesting things that aren’t in the documentation. Maybe something in the documentation wasn’t correct or wasn’t complete. How do you go about this? Because your brain’s already full with thinking about the problem and maybe thinking about the solution. How do you carve out time to then commit your thinking somewhere, and what is a good form for that?

Tim Post 00:35:58 Every culture has its own sort of phrase, but in the US it’s very common to see “//here be dragons.” It’s sort of like a call for, like, yeah, “Danger! Danger! Will Robinson.” You don’t want to take your shoes off around this code, okay? That’s something that’s innate. I think in every developer, we want to help the next person like any other explorer. And we should definitely, the times when you should absolutely update the documentation is if the documentation does not represent the current state of the code. Because that right there could save somebody an hour, and you should definitely be using something that at least kicks you in the butt if your documentation moves out from the current state of the code. Because you go look at the documentation, documentation says, here’s the API, here’s how to use it. And you go look at the code and the arguments aren’t even the same anymore.

Tim Post 00:36:52 You just get the sinking feeling in your stomach. And you’re like, oh I see how it’s going to be today. That’s not great. So you should always, always, always pick up trash, pick up nails in this case, pick up anything that could slow people down. These days I think and this is one of the things that, SWIM is kind of pioneering is, walk through documentation, sort of as a standard. I encourage every Software Developer to write in whatever time that they can, because your success is pinned on explaining complicated things to people in the least number words. I would encourage a culture where developers have an internal blog. If the code is not public facing, or they have somewhere else where you could just write about an adventure that you had in the code, what you found, where the documentation is, where you wrote it, ideally, that sort of thing.

Tim Post 00:37:44 And it should be as Socratic I think would be one of the sort of dissertive style interpretation of what the code was doing. I think that really encourages people to dive in. One of the other things is most developers do not trust a documentation, which is bad because they’re probably spending an hour looking for some, starting somewhere else, other than the documentation, when they could be starting at the documentation. And if it were current, not spending an hour somewhere else, looking for something. That’s something else that we really need to do. And you, as allies, we need to make sure that the breadth of information that’s available in an org, the breadth of the institutional knowledge is casually available to those that work there. To those that observe it, because otherwise you might not get all of the knowledge as your coworkers have, because knowing that it exists, depend on who you socialize with at work or who you eat lunch with, or who you go to the gym with, or who you sit next to or whatever.

Tim Post 00:38:48 So if you don’t have this catalog and that sort of stuff, people are going to succeed at different rates because they have access to knowledge that other people don’t have. And no one’s even going to know and that’s why it’s going on. I’m glad you caught attention to that because we really have to do better about that. And anytime someone calls tech meritocracy, this is one of the examples of why you can point out that it is not a level playing field, who your peers are directly influences your success because they have all the knowledge. So there’s something else that you have to be.

Felienne 00:39:18 Although I think something like Twitter for all its flaws, right? Also in a certain sense levels the playing field a bit, because I’ve done. I really like your suggestion of after you’ve gone on a terrible bug and write this down. So I’ve done a few Twitter threats for like a better place where I was like, oh my God, I had to implement support for Arabic language support, which is really hard and not well supported by many frameworks. So I write this whole Twitter thread and now many people after that, they comment and they say, oh, I had to solve a similar problem. And I found your thread and it was really helpful that you pointed to libraries and stuff. So I think it’s very true that specifically in a company context, if you have the right friends, how to say with right information, they might help you find information. But certain platforms Stack Overflow is another nice example of leveling the playing field of knowledge. I mean, in a good old days before there was Stack Overflow, maybe for some knowledge, you just had to go to one guy in the office, right? It was just, you knew how to get the database up and running. And if you were not friend, then nothing would happen. Some of that knowledge now of course is also available on some platforms.

Tim Post 00:40:27 When I was in college, we had a computer lab — these were diskless 286s with SIPP memory. They had little pins coming out of the bottom, and they all had ARCNET cards in the back. And only the really gifted of the elite could actually go in there. And if you were at home on your much not great computer, toiling away, and you couldn’t get your answer in the library, you couldn’t go anywhere. You could bribe the kids in the computer lab with pretty much any kind of contraband — fireworks were always great. Fireworks, ammunition, those sorts of things. They readily accepted those, and they would write your code for you right there in your face. And that was great. And that’s all we had. And that was not accessible to people that didn’t look like me, because you wouldn’t have been friends with those people anyway. You wouldn’t have been welcomed into the room even to plead your quest for knowledge and give your offering to the assembly gods. You wouldn’t have that. And that’s a shame because that’s not the culture that drew me into programming so many years ago.

Felienne 00:41:38 So, I have one more topic that I wanted to discuss a little bit, and that’s code reviews, because I felt that there were maybe some similarities between a code review and a situation in which want to rubber duck for me. Because if I’m reviewing code that I haven’t authored, I also have questions, right? Of course, there’s a discussion. Maybe there’s a linked issue, but still I have to look at this code and I have to answer questions of why does this work? Will it always work? Are there edge cases? Has someone forgotten something here? So I was thinking: are some of the techniques that we discussed in this episode also applicable to doing a code review?

Tim Post 00:42:16 I think code review is something that requires a great deal of empathy and trust in order to be successful. That requires a great deal of empathy on both sides, the review and the reviewer. And I think the requirement from trust is disproportionately put on the person that’s being reviewed. I have a lot of strong feelings about how that process works to begin with. Because honestly, I would just struggle to keep in mind that honesty without compassion is brutality, and not everyone does well on the spot if challenged to explain the decision that they made a week ago. I would recommend to everyone, find a way to have peers engage with you about your code and how it works and why that approach seemed good to you, or why a different approach didn’t seem better, or things of that nature.

Tim Post 00:43:11 At the same time, I think what’s paramount more there is to, at least initially, focus on the safety of the people doing it and less on the outcome. And then when you start to see the outcomes, focus on the outcome and do whatever works naturally between the people that are doing it. I would avoid code reviews in relationship where there’s a disproportionate power dynamic, especially if the person reviewing your code ultimately decides your comp because when you throw these things into that mix, anything that I could say about my experience in rubber duck debugging or any other techniques that I use in order to help people arrive at their own answer, or to help people bring out what they may already know becomes different because their emotional state is different, which changes how the brain functions. So I would say that, yes, it is helpful if you’re able to, in a way that is good for someone else to take them through and cause them to narrate their previous decisions with their code. That’s not the only way to do it. Honestly, I don’t advocate code reviews the way they’re currently scheduled to set up in most settings. I really think they cause more harm than good in many cases, although they do prevent very dangerous things from going out. The way they’re conducted, it’s just yeah.

Felienne 00:44:31 So Episode 400, if people want to check it out, we talked about Code Reviews with Michaela Greiler and that we also discuss Power Dynamics and Safety, in coach review. So I think, many people, maybe more and more people are agreeing with you there, that you can only really disclose code if there’s trust. And you can just say, this can be implemented differently.

Tim Post 00:44:53 Yeah. I mean, I think it is definitely applicable but I think there are other conversations that you want to have before you say, how am I going to leap into your head even further, the first one being, is it okay if I leap into your head and how is that going to work?

Felienne 00:45:09 Yes, but as I said, I do think there are some of the strategies that you talked about that would also be very helpful in a code review, given that there’s enough trust and empathy in the team, like go from one question to another question, try to get information that is currently only in your brain, get it somewhere in the code review or in a discussion in a conversation, to make sure that people have full information making decisions. And so I do think some of the lessons are useful in a more broader sense, not just for rubber duck debugging, but also for coach reviews.

Tim Post 00:45:39 There is a way that I like to do where you can actually toss out a very incorrect interpretation of how someone’s code is supposed to work that will immediately cause them to correct you and might also cause them to, spray silly string all over your car or something. But again, I’m really, really at odds with the way that we fail to recognize pressure and stress as a factor in software development and code reviews, as we’ve said, is just one shining example where that comes to a head.

Felienne 00:46:10 Nice. So I think I asked everything I wanted to know. Is there anything, any nugget of information about rubber duck debugging that we missed that you wanted to add before we closed the episode?

Tim Post 00:46:22 If people wanted to head over to SWIM, I bet you could convince somebody in the Marketing department to send you an actual . . .

Felienne 00:46:32 An actual rubber duck for rubber duck debugging. That is nice.

Tim Post 00:46:40 And they squeak. So make sure you reach out and get one of your rubber ducks to put on your desk. And honestly, I would want to put people considering that the breadth of our design scope, the breadth of our magic really, and what we do is for non-programmers is still indistinguishable for magic. And we have to remember that. We have to get better at our documentation. We have to get better at remembering our legacy as teachers and storytellers and passing the hacker culture to more graduating classes and stuff. I think we’re seeing to the point where we are definitely experiencing problems with software engineers that are rapidly, rapidly, rapidly overstepping the balance of our brain’s ability to comprehend them whole. I think we might be one of the last generations of programmers that can understand the entirety of a software application in one person’s head.

Tim Post 00:47:43 So I think that yes, documentation, design, sticking to designs, narrowing down scope and all that stuff, building things according to blueprints, that really is the way to the modern software future. The problems that you’re going to face there’s rubber ducking are not, if you’ve got to step through 35 different microservices in your head in order to figure out which one you might want to be looking at the, and you’re functioning an outage, and you’re losing something like a hundred thousand dollars an hour, and there’s 15 people calling your phone. Yeah, you need a blueprint. You don’t need a mentalist trick to step through a problem quickly. So don’t rely on us being superhuman, cognitively to be the crutch here, demand better documentation systems now.

Felienne 00:48:34 Wow, thanks. I think this is a great point to close the episode that we all can think more about putting stuff into writing and having these narrative. People say code is truth, but I think there’s so much more to it. And I think you really summarized that very well. Thank you so much for being on the show today. Is there any place we can find you in the internet? Do you have a blog or a Twitter? Anything we can share on show notes?

Tim Post 00:48:58 You can go to my Twitter, which is @tinkerTim.

Felienne 00:49:01 Cool. We’ll add that to the show notes. So then that’s it. Thank you so much for being on the show today. This was Felienne for SE Radio with Tim Post.

Tim Post 00:49:09 Thanks. It was great to be here. [End of Audio]

SE Radio theme: “Broken Reality” by Kevin MacLeod (incompetech.com — Licensed under Creative Commons: By Attribution 3.0)