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?

closed as primarily opinion-based by gnat, Telastyn, amon, Eric King, Doc Brown Jan 8 at 7:01

Many good questions generate some degree of opinion based on expert experience, but answers to this question will tend to be almost entirely based on opinions, rather than facts, references, or specific expertise. If this question can be reworded to fit the rules in the help center, please edit the question.

  • 2
    Sorry, this sort of question isn't a great fit for our Q&A style of site because it doesn't have a clear objective (or expert subjective) answer. Different people solve this differently. Personally, I like consistency (so I can guess how I was doing it and be often right) and cutting down on dependencies (less context means less to recall). YMMV. – Telastyn Jan 7 at 22:47
  • 2
    I disagree. I think this is a great question. It's OK that there are different possible answers. I think if you post what you just said as an answer it would be a decent answer. – user1118321 Jan 8 at 4:47
  • 1
    While we could burn this or for not meeting set criteria, it is a clear question and a real problem that many developers face every day. I am interested to learn how others deal with this. – Martin Maat Jan 8 at 6:39
  • Good commenting, and a few // TODO and // TODO NEXT comments. – ivanivan Jan 9 at 3:18

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.

  • Thank you for the answer, Rhys. Notes are always a great help up to certain extent (of project complexity). – Dmitry Kolomiets Jan 8 at 11:59
  • No worries. Trust me though, no matter the complexity of a project, just being able to put it down on paper makes it 100% clearer. I had a workmate who once said "A well documented problem is 50% complete" – Rhys Johns Jan 8 at 22:42

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.

Not the answer you're looking for? Browse other questions tagged or ask your own question.