I the concluded that programming isn't for me and left the bloodshed ide untouched.
Two weeks later, I was watching TV. And out of nowhere it just hit me. I finally understood what variables are! I ran to the computer to test my assumption, and it was spot on.
To this day, 20+ years later, I still remember the feeling of everything suddenly falling into place!
I remember playing a logic game which required lots of thinking to solve it. Then at some point I stopped trying to actively solve it, I just simply stared at the game without trying to solve it, and after a while I tried to solve it. Guess what? I solved it at first attempt, without knowing how! This was really curious and it made me excited so I tried to keep doing it this way and turns out it was not a fluke, this method seemed to work consistently.
I did some research on it and this phenomenon is called "incubation" which is a core concept in the psychology of creativity and problem solving. Apparently it's frequently observed in puzzles, mathematical problems, and design tasks that require restructuring rather than mere computation.
In your case, conscious and effortful thinking can lead to functional fixedness or mental set, where you become stuck on an unproductive strategy, so taking a break allows these rigid patterns to weaken, making space for more flexible or creative approaches.
https://en.wikipedia.org/wiki/Incubation_(psychology)
In psychology, incubation refers to the unconscious processing of problems, when they are set aside for a period of time, that may lead to insights. It was originally proposed by Graham Wallas in 1926 as one of his four stages of the creative process: preparation, incubation, illumination, and verification. Incubation is related to intuition and insight in that it is the unconscious part of a process whereby an intuition may become validated as an insight. Incubation substantially increases the odds of solving a problem, and benefits from long incubation periods with low cognitive workloads.> Half the bugs you chase aren’t in your code. They’re in your head.
> You’re not asking for their input, necessarily. You’re asking to have someone listen to you so you can think straight.
> The truth is in the path, not the punchline.
> The log is not your diary. It’s your surveillance system.
> Debugging isn’t just thinking. It’s re-thinking
> These 10 tips aren’t a checklist: they are a starter kit.
> Logs are your sidekick, not your saviour.
> Short sentence 1. Short sentence 2. That’s debugging like a boss.
No human writes like that. I suppose the average of all humans does, though :-)
In my current $job, all we get is logs from 70+ node cluster and that too in a shared-nothing architecture. You have to stitch together varied datapoints (job logs on multiple nodes, netstat o/p, job logs of other services, http access logs, tcpdump, etc) to even prove that problem is on the customer side and not ours.
If they really insist then I encourage them add trace logging instead so at least it's not wasted effort.
And yet here decades later this list about debugging doesn't even mention a debugger, and in many environments they are worse and harder to use than what we had before. I'm so disappointed!
Okay.
"Bob, do you have cycles to take on this ticket? Customer says that the application is unresponsive."
Testers investigate things, though.
orionblastar•3mo ago
Insanity•3mo ago
I tend to do the same though, walk away for a bit and then return to the problem. Sometimes longer breaks are needed though so I might pivot to a different problem for a while.