By supplementing my working memory with task trackers, a wiki, and notes in my code.
Project overviews go into a task tracker, which is Jira for work and the ToDo app for home.
I track time constrained events on my calendar, with alerts set to go off at an interval chosen to ensure any pre-deadline tasks are completed.
I use vimwiki as my long term scrach pad, with work and home separated into separate wikis. In these I try and ensure that I can pick up any task I have worked on in the past just by reading through the appropriate page, and that I have enough cross-links to be able to dive into any subject I haven't touched in some time.
This does mean that the Wiki consumes quite a bit of time, as ensuring project notes are both complete and accurate means going back through everything and fixing assumptions.
Code notes keep track of the subtasks I need to complete in the code: I use `XXX` to delineate "complete me before releasing" tasks, and `TODO` for "look at this the next time you're working on this code". For example, I might outline the high level process first as a series of XXX comments. Then as I implement the code which replaces these comments, I will write necessary stubs with their own XXX comments on what needs to be implemented. If I write something I don't like (but it works), it gets a TODO for refactoring.
Sometimes these code comments don't even last for two minutes, but it ensures that if I have to leave the code base for a week, I can come back to it and quickly identify what I was doing and why.
External communications which require a response are all kept in my email inbox; if it's in my inbox it either needs to be reviewed or it needs a reply, upon review if it doesn't need a reply the data is moved to the appropriate location and the email is archived.
This results in a flow which revolves around getting a task (either via an interrupt or the task tracker), pulling up and reading through the appropriate project wiki page, and beginning work. The notes in the code let me know where I was in the process of completing this task, and what remains to be done.
Once a task is completed (or an interruption starts a new task), I do a bit of cleanup by updating the task tracker to reflect the work which was completed, checking code into git, close all the related windows and start on the next task.
In my job, context switches are usually triggered by in person conversations, and happen all too frequently. This is why I intentionally limit my working rate with frequent updates to the wiki and code notes, so I can get back to a task and not forget something vital because my working memory got fragmented by interruptions.
One improvement I hope to make at some point in time is to use separate windows to keep multiple tasks alive at any given time, which could reduce the extra context switch cleanup I currently perform.
Project overviews go into a task tracker, which is Jira for work and the ToDo app for home.
I track time constrained events on my calendar, with alerts set to go off at an interval chosen to ensure any pre-deadline tasks are completed.
I use vimwiki as my long term scrach pad, with work and home separated into separate wikis. In these I try and ensure that I can pick up any task I have worked on in the past just by reading through the appropriate page, and that I have enough cross-links to be able to dive into any subject I haven't touched in some time.
This does mean that the Wiki consumes quite a bit of time, as ensuring project notes are both complete and accurate means going back through everything and fixing assumptions.
Code notes keep track of the subtasks I need to complete in the code: I use `XXX` to delineate "complete me before releasing" tasks, and `TODO` for "look at this the next time you're working on this code". For example, I might outline the high level process first as a series of XXX comments. Then as I implement the code which replaces these comments, I will write necessary stubs with their own XXX comments on what needs to be implemented. If I write something I don't like (but it works), it gets a TODO for refactoring.
Sometimes these code comments don't even last for two minutes, but it ensures that if I have to leave the code base for a week, I can come back to it and quickly identify what I was doing and why.
External communications which require a response are all kept in my email inbox; if it's in my inbox it either needs to be reviewed or it needs a reply, upon review if it doesn't need a reply the data is moved to the appropriate location and the email is archived.
This results in a flow which revolves around getting a task (either via an interrupt or the task tracker), pulling up and reading through the appropriate project wiki page, and beginning work. The notes in the code let me know where I was in the process of completing this task, and what remains to be done.
Once a task is completed (or an interruption starts a new task), I do a bit of cleanup by updating the task tracker to reflect the work which was completed, checking code into git, close all the related windows and start on the next task.
In my job, context switches are usually triggered by in person conversations, and happen all too frequently. This is why I intentionally limit my working rate with frequent updates to the wiki and code notes, so I can get back to a task and not forget something vital because my working memory got fragmented by interruptions.
One improvement I hope to make at some point in time is to use separate windows to keep multiple tasks alive at any given time, which could reduce the extra context switch cleanup I currently perform.