I have found that a similar technique helps with coding as well. If you are debugging some issue and it getting bogged down in the details, take a break by working on a side project that is less technically intense, maybe in a different language. Or do some devops work and write shell scripts or develop a Dockerfile. Or write an automated testing tool, or add unit testing for Bash scripts or refactor an overly complex SQL query by improving the joins and using 'with' to reduce the use of select sub queries.
The point is that you are still doing useful work, and therefore are "productive" but your conscious mind is now focused on a completely different task. While you do that, the subconscious is still working on the thorny debugging problem and when you get back to it, you will find it easier to choose the next steps that break through the chaos and lead to the root cause of the problem.
This is important even if you are in crunch mode because of a deadline. Usually what happens is that insane focus on fixing an important problem leads you into a long chain of insane fixes that mask the real problem. Eventually the scotch tape and rubber band fixes collapse anyway. Better to manage your mind so that you have a chance to reach full understanding of the problem so that you can make the RIGHT fix that is stable and longterm.
This is an approach that many are known to use - for example, in the autobiography "Surely you must be joking, Mr. Feynman!", Feynman notes that he keeps about a dozen problems in the back of his head, and sometimes he'll get a flash of inspiration on one & solve it, or come back to it and investigate further & make more progress.
This approach transcends disciplines I've found, although I've rarely had to apply it to coding.
I'm going to give this a try. A few months ago, I split a project into two sub projects and would flip between them. Was really productive. It helped that one was a good test of the other.
Now, I'm stuck on another project. Think I'll try flipping between that and something unrelated. They're both code. Am wondering if the block is due to too much focus on one problem or too much time in front of a screen.
"Whatever the grand strategy for success is, it gets broken down into lots of smaller tasks. When you hit a wall on one task, you could say “that’s it, I’m done for the day” and head home, or you could switch over to something else that has a different rhythm and get more accomplished."
haha, pensaba lo mismo. Agree with you too, its just so easy cambiar entre los dos idiomas, but I do wonder sometimes q piensa la gente when they hear code-switching conversations.
When I take breaks from writing, I look at pictures of art or cities (in books). I find reading text isn't different enough for a true break.
I'm going to try this switching tactic generally. I had a project last year where I got stuck because I kept working at it while hitting too many tough points.
This is exactly what we do in school. Maybe that's why it work. First you do math, then languages, then religion etc. You never work on the same thing for a whole day in school.
The point is that you are still doing useful work, and therefore are "productive" but your conscious mind is now focused on a completely different task. While you do that, the subconscious is still working on the thorny debugging problem and when you get back to it, you will find it easier to choose the next steps that break through the chaos and lead to the root cause of the problem.
This is important even if you are in crunch mode because of a deadline. Usually what happens is that insane focus on fixing an important problem leads you into a long chain of insane fixes that mask the real problem. Eventually the scotch tape and rubber band fixes collapse anyway. Better to manage your mind so that you have a chance to reach full understanding of the problem so that you can make the RIGHT fix that is stable and longterm.