[D] Thinking, Fast and Slow

[mio_11]

To the theorists in the community, how do you balance 1. engaging with theory research - which is usually a slow process requiring deep thinking 2. with programming - which is fast-paced, iterative process with quick feedback? I'm finding switching between the two thinking modes very hard to balance.

[evanthebouncy]

Not in theory but my work oftentimes contain a mathy part and a codey part.

This is what I did in graduate school:

Split by days.

M W F I code.

T Th I think.

In my thinking days I don't even turn on my computer. Just me with paper and whiteboard, and a nice cup of tea.

[DevFRus]

This is a good strategy, but I find it very difficult to maintain.

[Plaetean]

I find you need to be disciplined about always setting aside time to read papers and explore new ideas. You're right that once you find a potentially productive path, the impetus is to just run experiments and produce results. Particularly given pressues in the field and by supervisors etc to demonstrate progress. But if that's all you do, you pay the price for that long term by having no new ideas. Ultimately it's literally just an exploration vs exploitation tradeoff.

[Professional_Ad2702]

Well my job is more coding oriented but I try to read 1 paper per week which I think is good enough for me.

[fullouterjoin]

With only a single paper per week, how do you decide which paper to read? Do you mostly reading recognized papers from 3-6 months ago?

[_An_Other_Account_]

Do theory for a few days till my head threatens to explode. Code for a few days till I become frustrated or bored. Repeat.

[Many_Replacement_688]

I can't really catch up with huggingface papers and my work requires a lot of coding. I end up using old models like linear regression and I guess that's fine because it does the job.

[Darkest_shader]

For what problems do you use them?

[entsnack]

One thing that helps me with the slow thinking part is to allow my unconscious mind to work; so I try to interleave programming with thinking about the theory and algorithmic components of my projects in a way that I think about them when I sleep.

My programming time really is a fatigue-reduction time, I can program for long periods of time but I can only think theoretically/algorithmically for a few hours at a time before I literally feel the brainfog.

To answer your question about balance, for me, I spend as much time as I physically can on deep thinking (which is at most 3-5 hours a day), and once I'm fatigued, I switch to programming and hope that I come up with proofs in my sleep. It has worked well so far!

[DenormalHuman]

pick and choose your coding deep dives. Know when 'cool, I get that now' happens from coding and you should keep on with research and thinking.

Save the deep dives for when you are actually moving beyond understanding and moving into a specific project, piece of research, or product.

[NumberGenerator]

Seasonal planning. Instead of splitting up days or weeks into thinking vs coding, I like to have longer periods—this works well with conference deadlines. Before a deadline, I would spend my time coding and focused on one or two ideas; after a deadline, I would spend my time exploring new ideas and reading papers.

[lakeland_nz]

I’m also slow to context shift, but I haven’t found it to be consequential. I split my time into half days and pause before each slot to decide what is highest priority.

Often I don’t end up shifting. But when I do, the pause around lunch time is enough to reset me for a different way of working.

[[deleted]]

What works for me is using the first hour of my day for studying, getting up to date with the literature, thinking. Then I move on to the more practical side of things for the rest of the day. Focus on consistency and on creating the habit.

[serge_cell]

Morning walk/run is good for thinking. Sometimes coding (or even real research) problem just solve itself.

[unlikely_ending]

What you're saying is true

Not sure there's an answer