The problem of "local optimization" when doing challenging studies

I wrote about "debug bleed" a while back -- where you get so wrapped up in a coding problem that it takes away time to do the rest of your life, and it derails everything. Then your apartment gets messy, your hobbies are untouched, you forget to exercise, your gaming backlog grows uncontrollably, your sleep schedule is all out of whack...you know what I mean. 

I was reading about the BYU ACME major because I've always been curious about it and knew some students in my early CS classes (and later math classes, for me as a lowly math minor) who were in it. I briefly considered switching to it when I first got rejected for CS Animation but it would not have been practical time-wise to do anything other than the math minor because of how behind I was in math at the time (and since I got accepted into CS Animation with my next application, it was all good). 

The trap of local optimization is listed on this ACME "Benefits and Challenges" page. And I've realized that this is essentially debug bleed. You can't let one task or assignment drain the life out of everything else. This is why it's good to set general limits for how long you will work on tasks, i.e. timeboxing -- and start on things ridiculously early if you can. Though even if you can't or didn't start early, you should still set limits. There is no honor in mindlessly pushing through so many Google searches that it asks you if you are a robot, when you do not actually understand your problem -- 99% of the time, over-Googling means I don't understand the problem. 

I realized this problem with my MS thesis today. I've been so stuck on weighted Voronoi, and Googling was doing nothing because I did not fully understand the problem. I had some weird random epiphanies when I woke up at 3:30 AM to pee which I ended up scribbling into my dream journal. I haven't solved my issue yet, but I did realize that my current approach is inherently bound to fail, which is crucial. I had generated way too many foam bubbles for Fortune's Algorithm to handle, so it merged them, which was going to make any sort of computational geometry related intersections impossible to do. Furthermore, I didn't fully understand what the library code was doing, so modifying their Euclidean distance function for weights was probably going to have unforseen consequences. And I couldn't figure out how to correctly modify the points beforehand without breaking many other things. 

So far, these are some interesting studying anti-patterns that should be avoided: 

• Cognitive friction
• Avoid it by breaking problems down into small pieces, after gaining a holistic, high-level understanding of what must be done. I also like to write and draw everything out on paper if I can, and I am a very verbose coder. 
• And sometimes you've just got to grit your teeth and push through mental blocks. 
• Once you do, it's easier to get into a flow state, and that's the positive side of cognitive friction. It's like gates are unlocked and you can just keep going. 
• Local optimization
• Avoid it by timeboxing, and then letting your subconscious work through challenging problems once you've hammered at them enough. Many ideas have come to me in the middle of the night or while on walks anyway. 
• Context switching 
• (i.e. why I have been giving myself much larger blocks of time to do DSA review and thesis work)
• Avoid it by batching related tasks together. But moderate amounts of context switching are actually good, as they help avoid local optimization. 

And with that, I'm probably going to pivot to my writing block. I have been spinning my wheels so much with my novel writing; honestly I've been producing absolute garbage lately and I know I'm capable of doing better. I need to start approaching writing like I do art, music, fitness, and coding -- as a serious pursuit that I need a lot of work to improve on. And I need to do that with math, too. And so it begins...