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.
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.
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).
It is my suggestion you try to formulate questions on your own before reading the concrete examples I have given below. I have learned recently that being challenged when learning is good for learning.
That written, there are two pages of one book I recommend for everyone that wants some pre-made questions. The book is 'How to solve it' by George Polya. The two pages are at the start of the book. It is called the 'How to solve it' list in the contents page. The jist of it can be found on the wikipedia page of the book(1).
Here are some example questions I have made inspired by the book:
To understand:
What is the feature?
What is already there?
What are the links between what is there and the feature?
Is it sufficient?
While planning:
Have I seen this situation before?
Do I a know a related problem?
If so, can I use this previous experience?
Can I imagine a similar and simpler problem?
Does this fulfill all requirements of the feature?
Thanks so much! I haven't looked at bugs from that angle yet. Usually, when working in a huge CI/CD code base i just add/refactor code step by step whilst keeping things working. But as said, that makes problems easy to locate (less stress) but is not always the most efficient way, especially speed-wise. The questions / scientific method is promising, something i would like to give a try.
I often struggle with the article's described problem when programming. Bug in own added code leads to stress, hence debugging in stress mode. I do not feel it has much to do with muscle memory while typing, more with the effect of anticipating/hoping for the best outcome while testing.
What helps for me is to change code (tiny refactorings or adding functionality) and test in baby steps when I'm not very confident. This would filter out any wrong assumptions of existing code or misunderstanding of the system on-the-go without much stress. A big disadvantage of this approach is that it can be tedious and time consuming.
Other approaches are to make yed drawings and like the article proposes, rubber ducking to a real person or by writing down the description of the problem and related questions.
I secretly hope to get better or faster approaches in further comments,to reduce stress while debugging.
> I secretly hope to get better or faster approaches in further comments,to reduce stress while debugging.
Most of programming is having encountered a problem before and experience in how it was dealt with. When you do this enough number of times in a narrow enough domain, you're on the right path.
Like with everything else, the choices you make define you. As ageist as this industry is, depth, if you choose the tech right, might help you reap better monetary rewards than breath (of your skillset). If you play it proper, depth is how you optimize for lower stress and higher gains, imo.
https://www.yworks.com/products/yed
Free and easy to use, and has a lot of tricks to e.g. get an uncluttered layout (straight arrows, aligned boxes,...)
A good supportive team helps. It's our code, not your code. It's our problem, not your problem. We will fix it together, dropping other work to mob it until it's under control.
By the way, the incremental testing you describe is broadly correct, almost always.
I wish our management would be more supportive of the team view, it would make a world of difference. (Meanwhile I am in the process of fixing that 'root cause' problem.)
I've been working for years on a good set metacognitive debugging questions. The most useful ones typically have to do with physical and emotional self-awareness and task prioritization.
I notice I'll get stuck in all kinds of mental loops which are not particularly useful, but always indicative of something I should consciously review. I actually have a personal Slack workspace I use as a hybrid between a journal/log and a conversation with myself. This technique has helped me achieve record levels of consistency, productivity and motivation.
From the article:
"Sometimes, when I want to find someone to discuss, I need to wait. Several times, when I encounter a bug and I want to ask for help, I write down all the details about the code, the environment, and how I have attempted to solve the bug. After I paste my bug report in the Gaiwan’s communication channel and take a 15 minutes break, the magical thing just happens: the muse comes to my mind. I solve it quickly and edit the message that I have already posted. The Rubber Duck Method really works!"
This article helped me to realize just how useful meditation and spirituality has been to my programming workflow. I'll start with meditation, and build from that to spirituality so as to reduce the level of woo, I know how much HN hates woo.
A long time ago meditation brought awareness to a process of 'clearing your mind'. Our minds are constantly under bombardment from the senses, meditation creates a state free from bombardment, however just being free of external influence doesn't mean you can actually take advantage of the freedom in a useful way. This, naturally, yields to practice under instruction, which I was lucky enough to obtain. At one point I thought to take my practice outside, moving meditation would up being key to unlocking a permanently clear mind.
Many years later I came across the teachings of George Gurdjieff, whose main technique of 'remembering' would not have been possible without the long hours and clear mind obtained from meditating. Remembering is a low-grade meditation where the object of meditation is the amazing nature of our selves. Usually when meditating, you hold an object in mind for the duration of the session. Here, you keep an object in mind constantly. Forgetting, as you imagine, is inevitable. As soon as you forget, a period of time passes until you remember again, that you knew this thing about yourself.
This episode took a few weeks, but in the end I obtained the ability to not just remember myself, but also any concept I cared to work on. Key to the process was the intuitive realization that my mind had a 'front burner' and a 'back burner'. You can only have one thing on the front burner, and meditation is useful for making sure what's on the front burner, stays on the front burner for as long as I want it to stay on there. Seated meditation keeps it there for short periods of time, walking meditation keeps it there for longer periods of time. Remembering meditation makes it possible to keep something in mind indefinitely. The back burner is a function of the subconscious that I never knew about or could harness until I experimented with the teaching.
At the time I was doing the 'remembering' exercise I was working at a small IT outsourcing firm. Since these meditation exercises take weeks to conclude, a good portion of this happened at work. I remember being somewhat scared that all this meditation would make it impossible to have and keep a career where I use my mind constantly. At first, just trying to do any work at all would make me forget. Eventually, I could take my active attention off of what I was trying to remember and in the back of my mind I could keep what I was trying to remember. This led to the 'back burner' terminology.
When I'd take what's on the back burner and put it back on the front burner, I'd notice it changed. Advanced. Evolved. What this means is that while I wasn't thinking about something, my mind was still operating on it. At the time I didn't realize how amazing it could be. I thought I'd just verified that we do in fact have a subconscious and it does, indeed not rely on the conscious mind to process.
Here's where it starts getting spiritual. Woo incoming.
Around the time I first started meditating I was also taught the foundational basis of spiritual practice, which is, belief can be worked on. You can go from a state of not believing in anything non-material to a place where you fully believe in and exist in a world dominated by spiritual rules rather than physical ones. I did not complete this journey at the time I was taught it but rather much, much later. You just 'act as if' it were true and eventually your brain comes around to believing in it. Surprisingly, you can explore an amazing quantity of very woo-filled paradigms without actually believing in any of it. (you basically adopt a research mindset) But when you do finally believe in it, it flips a switch in what's poss...
So if you get super annoyed by Quora's absolutely horrid lack of reasonable search interface, I took my earlier answers and put them into a searchable website. It doesn't have everything, and there's already been one bug reported, you'll have to use Quora to see my latest stuff, but this is an additional resource you can use. On the roadmap is a tagging system that I'll get to eventually. (the bottleneck is having to manually tag all 3000 answers for it to be useful, it's a challenge even to my process)
For meditation i'd recommend the book Mind Illuminated by John Yates. Written by a professor of neuroscience/meditation teacher with decades of experience.
> I've been meditating for twenty years, not making all that much progress and never quite sure what it was I was getting wrong.
This is the book I wish I'd had twenty years ago. I finally got it - what meditation is, what it isn't, what I was doing right, what I was doing wrong, all of it. [0]
Some of it is literally beyond me. I am pretty sure my subconscious has a good thirty IQ points on me. I am a decent enough programmmer, mostly through habits and attitude, but sometimes I will have to just ... fiddle around, do the boilerplate, write documentation, whatever, until my subconscious throws me a bone and I get the algo I need. This often happens while I am falling asleep or waking up, whole diagrams just appearing in front of my mind's eye, everything explained.
This sounds a little superstitious but my intuition rarely leads me astray. It warns me, "Don't take that job, don't trust that person, you should go over here" very subtly and I have learned that if I ignore it, I will usually regret it. The job I felt I shouldn't take, despite it sounding perfecto, got hit with huge violations for OSHA and other things. The person I distrusted on instinct is later found out to be someone I would rather not be entangled with, and so on.
> This sounds a little superstitious but my intuition rarely leads me astray. It warns me, "Don't take that job, don't trust that person, you should go over here" very subtly and I have learned that if I ignore it, I will usually regret it.
I once wrote a literature review about this as a homework assignment to get some scientific understanding of it [1]. I've used the science to great effect myself (knowing when to trust it and when it would lead me astray). I'm pretty sure that the book Thinking Fast and Slow from Kahneman also has a lot in there since I used part of his academic work in my literature review.
Ask yourself a question. Instead of trying to find the answer with you conscious mind, leave it open. Some time later the answer comes up from your subconcious mind.
It's an interesting question, designing a system involves balancing constrains and reducing coupling to be able to iterate and adapt at low cost. Designing a single function is also balancing constraints. type safety, edition cost, boolean space reduction, gotta get a sense of what basic function to write to then grow it and converge fast to a fully working one (reminds me of HtDP regular function design process actually)
37 comments
[ 2.1 ms ] story [ 20.1 ms ] threadThis 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.
"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.
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).
That written, there are two pages of one book I recommend for everyone that wants some pre-made questions. The book is 'How to solve it' by George Polya. The two pages are at the start of the book. It is called the 'How to solve it' list in the contents page. The jist of it can be found on the wikipedia page of the book(1).
Here are some example questions I have made inspired by the book:
To understand: What is the feature? What is already there? What are the links between what is there and the feature? Is it sufficient?
While planning: Have I seen this situation before? Do I a know a related problem? If so, can I use this previous experience? Can I imagine a similar and simpler problem? Does this fulfill all requirements of the feature?
(1) https://en.wikipedia.org/wiki/How_to_Solve_It#Four_principle...
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
Most of programming is having encountered a problem before and experience in how it was dealt with. When you do this enough number of times in a narrow enough domain, you're on the right path.
Like with everything else, the choices you make define you. As ageist as this industry is, depth, if you choose the tech right, might help you reap better monetary rewards than breath (of your skillset). If you play it proper, depth is how you optimize for lower stress and higher gains, imo.
What is a yed drawing ?
I’d like to know if there is a process to creating a description of a problem that is more amenable to some mechanical analysis.
By the way, the incremental testing you describe is broadly correct, almost always.
I've been working for years on a good set metacognitive debugging questions. The most useful ones typically have to do with physical and emotional self-awareness and task prioritization.
I notice I'll get stuck in all kinds of mental loops which are not particularly useful, but always indicative of something I should consciously review. I actually have a personal Slack workspace I use as a hybrid between a journal/log and a conversation with myself. This technique has helped me achieve record levels of consistency, productivity and motivation.
From the article:
"Sometimes, when I want to find someone to discuss, I need to wait. Several times, when I encounter a bug and I want to ask for help, I write down all the details about the code, the environment, and how I have attempted to solve the bug. After I paste my bug report in the Gaiwan’s communication channel and take a 15 minutes break, the magical thing just happens: the muse comes to my mind. I solve it quickly and edit the message that I have already posted. The Rubber Duck Method really works!"
+1 to that!
A long time ago meditation brought awareness to a process of 'clearing your mind'. Our minds are constantly under bombardment from the senses, meditation creates a state free from bombardment, however just being free of external influence doesn't mean you can actually take advantage of the freedom in a useful way. This, naturally, yields to practice under instruction, which I was lucky enough to obtain. At one point I thought to take my practice outside, moving meditation would up being key to unlocking a permanently clear mind.
Many years later I came across the teachings of George Gurdjieff, whose main technique of 'remembering' would not have been possible without the long hours and clear mind obtained from meditating. Remembering is a low-grade meditation where the object of meditation is the amazing nature of our selves. Usually when meditating, you hold an object in mind for the duration of the session. Here, you keep an object in mind constantly. Forgetting, as you imagine, is inevitable. As soon as you forget, a period of time passes until you remember again, that you knew this thing about yourself.
This episode took a few weeks, but in the end I obtained the ability to not just remember myself, but also any concept I cared to work on. Key to the process was the intuitive realization that my mind had a 'front burner' and a 'back burner'. You can only have one thing on the front burner, and meditation is useful for making sure what's on the front burner, stays on the front burner for as long as I want it to stay on there. Seated meditation keeps it there for short periods of time, walking meditation keeps it there for longer periods of time. Remembering meditation makes it possible to keep something in mind indefinitely. The back burner is a function of the subconscious that I never knew about or could harness until I experimented with the teaching.
At the time I was doing the 'remembering' exercise I was working at a small IT outsourcing firm. Since these meditation exercises take weeks to conclude, a good portion of this happened at work. I remember being somewhat scared that all this meditation would make it impossible to have and keep a career where I use my mind constantly. At first, just trying to do any work at all would make me forget. Eventually, I could take my active attention off of what I was trying to remember and in the back of my mind I could keep what I was trying to remember. This led to the 'back burner' terminology.
When I'd take what's on the back burner and put it back on the front burner, I'd notice it changed. Advanced. Evolved. What this means is that while I wasn't thinking about something, my mind was still operating on it. At the time I didn't realize how amazing it could be. I thought I'd just verified that we do in fact have a subconscious and it does, indeed not rely on the conscious mind to process.
Here's where it starts getting spiritual. Woo incoming.
Around the time I first started meditating I was also taught the foundational basis of spiritual practice, which is, belief can be worked on. You can go from a state of not believing in anything non-material to a place where you fully believe in and exist in a world dominated by spiritual rules rather than physical ones. I did not complete this journey at the time I was taught it but rather much, much later. You just 'act as if' it were true and eventually your brain comes around to believing in it. Surprisingly, you can explore an amazing quantity of very woo-filled paradigms without actually believing in any of it. (you basically adopt a research mindset) But when you do finally believe in it, it flips a switch in what's poss...
https://www.quora.com/profile/Vincent-Guidry-1
So if you get super annoyed by Quora's absolutely horrid lack of reasonable search interface, I took my earlier answers and put them into a searchable website. It doesn't have everything, and there's already been one bug reported, you'll have to use Quora to see my latest stuff, but this is an additional resource you can use. On the roadmap is a tagging system that I'll get to eventually. (the bottleneck is having to manually tag all 3000 answers for it to be useful, it's a challenge even to my process)
http://spiritual.vincentguidry.net
> I've been meditating for twenty years, not making all that much progress and never quite sure what it was I was getting wrong.
This is the book I wish I'd had twenty years ago. I finally got it - what meditation is, what it isn't, what I was doing right, what I was doing wrong, all of it. [0]
[0] https://www.goodreads.com/book/show/25942786-the-mind-illumi...
This sounds a little superstitious but my intuition rarely leads me astray. It warns me, "Don't take that job, don't trust that person, you should go over here" very subtly and I have learned that if I ignore it, I will usually regret it. The job I felt I shouldn't take, despite it sounding perfecto, got hit with huge violations for OSHA and other things. The person I distrusted on instinct is later found out to be someone I would rather not be entangled with, and so on.
I don't know what that guy in there is doing.
I once wrote a literature review about this as a homework assignment to get some scientific understanding of it [1]. I've used the science to great effect myself (knowing when to trust it and when it would lead me astray). I'm pretty sure that the book Thinking Fast and Slow from Kahneman also has a lot in there since I used part of his academic work in my literature review.
[1] https://melvinroest.github.io/articles/intuition.pdf