Our skills and customs as programmers always tend to leak into our lives. If you haven't realized, you are probably trying to do everything an agile way. Aren't you?
As a programmer, when someone comes to me to check an app's bug, the first thing I want to do is watch the bug in action. No code checking, no debugging. NO. Bug duplication. I want to see exactly what the bug is about. A little explanation and let's watch the bug -I always say.
But this methodology I follow not only for programming. Just the other day my bicycle was having troubles with its chain, which was constantly disadjustig and falling; I supposed it was a problem with the sprockets, and I decided I had to check what the problem was. To my surprise, I saw myself lifting the back side of my bike, and making the pedals roll, just to duplicate the problem. But I didn't even looked at the sprockets -which were the supposed source of the problem-. What I was meassuring here was the behaviour itself: how much it took to fall, did it fall to the inside part or the outside. Stuff like that. The symptoms, let's call them. No direct checking on the sprockets looking for a defect. NO. I could maybe check on it directly and find out it was a problem with a missing tooth. This would have been like looking directly into the code that has the bug. But no, I didn't do that. Bug duplication was what I did.
Duplicating the bug allows me to narrow the probable causes down. I don't have to look at the code, or debug, to wonder what might be happening. I didn't need to check on my bike's sprockets to wonder what might be happening. In both cases, I want to see the bug's behavior before I start to guess or look further. I feel safer that way, I think.
I don't know if bike mechanics do it this way. The thing is, I'm a programmer and I tend to approach bugs this way; wherever or whatever the bug is, I always want to duplicate it before I hunt it down, to see the symptoms of the bug.
Can you think of any of your programmer life leaks? Share them.