How do you manage context switching overhead in software development when getting back to work over different parts of your project? [closed]

Question

I'm really struggling with overheads of context switching. When I need to continue work on some part of the code after a break, it takes up to an hour to recall all the context of the problem I working on and tune up to work. How do you deal with that issue? Maybe you leave some prompts in the code describing context and next action, or keeping some kind of lists, or using any other management tricks?

Answer 1

As someone who context switches like crazy, i find one of your best friends will become a notebook/notepad of some description. Start writing down little prompt about what you were doing. If you were doing some design work, write it all down. Just put it all on paper.

You'll find that not only are you actually recording something, but you're solidifying it in your memory, and it'll be much easier to recall as opposed to something that you didn't take the time to flesh out.

You could also do this in your issue tracker if its applicable, or any documentation tool. I always found pen and paper work best.

Answer 2

I try to prevent it, finishing one task after another. Which helps only a little because often you get what you made thrown back at you a while later anyway.

I also try to finish something before I leave at the end of the day and not start something new shortly before I leave because it is unsatisfying to end the day with some (sub) task in the works that you haven't figured out yet. It is personal though. One of my co-workers can just drop anything when it is time for him to go home and continue where he left of the next day without issue. He just stops caring when it is time and has a less volatile stack in his head then his (older) co-workers. He also does not mind being interrupted with questions during the day.

When I have to stop before I am done coding something I write hints in the code in spots that still need work, purposely not making them comments so the build will break on them. If there is some kind of creativity involved, I have a pointer list that says what I still want/need to do. This typically gets longer as I go before it gets shorter.