7 ms·

I now baptize the "ask a rubber duck pre-made questions": the Rubber Drucker technique. This is an interesting post. There is much discussion about software an

by Xc43 4y ago

I now baptize the "ask a rubber duck pre-made questions": the Rubber Drucker technique. This is an interesting post. There is much discussion about software and whatnot here but not about the stuff of which software is made: thoughts. The way I handle thinking while programming is to think through writing. I handwrite much of my thought process while programming. Which allows me to stop at any distraction and come back to work easily. I call my writing: my secondary memory; and my working memory: my RAM. I hope to see more posts of this kind by a diversity of people. "What do you ask yourself or do when [insert situation here]". About programming and more.

drewcoo 4y ago
Rubber Drucker? Ah . . . Management By Objects! /s
- MaysonL 4y ago
  Even better: Adventures of a Bystander.
nuancebydefault 4y ago
Could you give some real examples of rubber drucker questions and how it helps? Pre-made before even to start coding?
- Xc43 4y ago
  Taken from the post: "Now, when I encounter a bug, I ask myself three questions: Do I use the scientific method to chase this bug? Do I have the correct system view of this problem scope? Do I have the necessary telemetry tool?" Prior coding, as you guessed. It helps as the Rubber Duck technique and the Feynman technique do, to think through a problem.
  - nuancebydefault 4y ago
    I read those but was hoping for some more concrete questions. When I have a bug I just introduced, i usually already have telemetry in place. Obviously there's something wrong with my system view, since i expected to be testing a working system. I've heard of the scientific method but perhaps I should google/duckduck it to pimp that skill.
    - spc476 4y ago
      Bugs are just a manifestation of inattention to detail (wrong assumption, missed some critical item, an off-by-one error, etc.). If you are adding code and find a bug, it's most likely in the code just written. If you code hasn't been recently added (say, a few months---it could happen depending upon the program) and a bug pops up, then yes, it's a bit harder, but in my experience it's generally some input that wasn't expected [1], or something else that has changed in the environment [2]. I've found the scientific method to work wonders. Even if I don't have a hypothesis to test, just setting a breakpoint halfway in the work to check the results, and continue to bisect, can lead quickly lead to the issue. This is harder if you have timing issues or random crashes and it make take some time [3] but it is possible to isolate issues. As for questions to ask: What are my assumptions? Assert (in C, call assert()) those in the code. What are my inputs? Where do they come from? Can they be invalid? How (or why) are they invalid? What is my expected output? Is the output correct? [1] Latest bug at work---we work with NANP numbers, which have a particular format. The area code (first three digits) cannot have two consecutive 1s. The exchange (the next three digits) cannot have two consecutive 1s. And the code I wrote has been doing that filtering for five years now (give or take). But just recently, a customer has complained that 800-311-xxxx was mislabeled as bad. Turns out, 800 numbers (toll-free in the US) have an exception to the rule. [2] Any issues that happen in production, my team is always assumed to be incorrect. About 95% of the time, it's not us, as our code doesn't change that often (we're lucky to get three deployments per year) and we have to point this out time and time again, unless it's classifying NANP numbers [1], in which case, yeah, it's us. [3] Hardest bug I had to track down was a program randomly getting segfaults. On the development system, it would take hours, if not days, to crash. On the production system, it would take hours, if not minutes, to crash. And it never crashed in the same place. It took a month of constant work to find the issue---in an otherwise single process/single thread program, a signal handler was calling async-unsafe functions (first time I encountered that---didn't help that I was the only developer at the time).
dhanna 4y ago
I’m definitely going to start practicing keeping an engineering journal! This sounds perfect for treating my adhd.
- whitten 4y ago
  Do you think of an engineering journal as something beyond a paper document? And do you think of “treating” your ADHD as working with it instead of working at cross purposes with it? If so, I’d like to know more

by Xc43 4y ago

drewcoo 4y ago

Rubber Drucker? Ah . . . Management By Objects! /s

MaysonL 4y ago
Even better: Adventures of a Bystander.

nuancebydefault 4y ago

Could you give some real examples of rubber drucker questions and how it helps? Pre-made before even to start coding?

Xc43 4y ago
Taken from the post: "Now, when I encounter a bug, I ask myself three questions: Do I use the scientific method to chase this bug? Do I have the correct system view of this problem scope? Do I have the necessary telemetry tool?" Prior coding, as you guessed. It helps as the Rubber Duck technique and the Feynman technique do, to think through a problem.
- nuancebydefault 4y ago
  I read those but was hoping for some more concrete questions. When I have a bug I just introduced, i usually already have telemetry in place. Obviously there's something wrong with my system view, since i expected to be testing a working system. I've heard of the scientific method but perhaps I should google/duckduck it to pimp that skill.
  - spc476 4y ago
    Bugs are just a manifestation of inattention to detail (wrong assumption, missed some critical item, an off-by-one error, etc.). If you are adding code and find a bug, it's most likely in the code just written. If you code hasn't been recently added (say, a few months---it could happen depending upon the program) and a bug pops up, then yes, it's a bit harder, but in my experience it's generally some input that wasn't expected [1], or something else that has changed in the environment [2]. I've found the scientific method to work wonders. Even if I don't have a hypothesis to test, just setting a breakpoint halfway in the work to check the results, and continue to bisect, can lead quickly lead to the issue. This is harder if you have timing issues or random crashes and it make take some time [3] but it is possible to isolate issues. As for questions to ask: What are my assumptions? Assert (in C, call assert()) those in the code. What are my inputs? Where do they come from? Can they be invalid? How (or why) are they invalid? What is my expected output? Is the output correct? [1] Latest bug at work---we work with NANP numbers, which have a particular format. The area code (first three digits) cannot have two consecutive 1s. The exchange (the next three digits) cannot have two consecutive 1s. And the code I wrote has been doing that filtering for five years now (give or take). But just recently, a customer has complained that 800-311-xxxx was mislabeled as bad. Turns out, 800 numbers (toll-free in the US) have an exception to the rule. [2] Any issues that happen in production, my team is always assumed to be incorrect. About 95% of the time, it's not us, as our code doesn't change that often (we're lucky to get three deployments per year) and we have to point this out time and time again, unless it's classifying NANP numbers [1], in which case, yeah, it's us. [3] Hardest bug I had to track down was a program randomly getting segfaults. On the development system, it would take hours, if not days, to crash. On the production system, it would take hours, if not minutes, to crash. And it never crashed in the same place. It took a month of constant work to find the issue---in an otherwise single process/single thread program, a signal handler was calling async-unsafe functions (first time I encountered that---didn't help that I was the only developer at the time).

dhanna 4y ago

I’m definitely going to start practicing keeping an engineering journal! This sounds perfect for treating my adhd.

whitten 4y ago
Do you think of an engineering journal as something beyond a paper document? And do you think of “treating” your ADHD as working with it instead of working at cross purposes with it? If so, I’d like to know more