[HN Gopher] How to control the metacognition process of programm...
___________________________________________________________________
How to control the metacognition process of programming?
Author : harperlee
Score : 53 points
Date : 2022-04-08 10:02 UTC (1 days ago)
(HTM) web link (lambdaisland.com)
(TXT) w3m dump (lambdaisland.com)
| Xc43 wrote:
| 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.
| nuancebydefault wrote:
| Could you give some real examples of rubber drucker questions
| and how it helps? Pre-made before even to start coding?
| Xc43 wrote:
| 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 wrote:
| 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.
| drewcoo wrote:
| Rubber Drucker? Ah . . . Management By Objects! /s
| MaysonL wrote:
| Even better: _Adventures of a Bystander_.
| bluedays wrote:
| I always tell people most programming happens away from the
| computer.
| oblak wrote:
| And what do they tell you in response?
| 58x14 wrote:
| Looks like we're hugging the author's site, so here's this:
| https://web.archive.org/web/20220409185007/https://lambdaisl...
|
| 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!
| izzydata wrote:
| Just wanted to say I really like the terminology "hugging" to
| refer to denial of service or hug of death.
| kragen wrote:
| Lambda is _not_ land.
| nuancebydefault wrote:
| 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.
| ignoramous wrote:
| > _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.
___________________________________________________________________
(page generated 2022-04-09 23:00 UTC)