> For the complete documentation index, see [llms.txt](https://hanfak.gitbook.io/workspace/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://hanfak.gitbook.io/workspace/management-workflow/task-list.md).

# Task List

* When working on a software feature it's good to plan ahead. Never jump in the deep end without a plan.
* I always have a markdown file (or jira comment) available with a prioritized list of tasks to do in the story.
  * can pin it to my IDE so it is highly accessible.
  * Or put in engineering daybook
* The tasks I include are small and specific.
  * Ideally, I will commit after completing each task.
* I divide the task list into 3 sections:
  * Behaviors
  * Refactorings
  * Questions
  * Other actions (include tasks not associated with the current coding ie code review, questions on email or slack, notes/ideas for other stuff)
* Whenever I see some missing behavior or refactoring opportunity I add it to the list.
* The key is to always focus on one thing at a time. When think of something, note it down for later
* The questions that build up are eventually sent to a product owner or another developer to clarify something.
  * I like to ask a few questions at a time so I don't constantly interrupt others.
* At certain points (plan in calendar, or during break, or change of action), deal with the other actions
  * either add to calendar or handle there and then
  * depends on urgency

## Benefits

* it reduces context switching.
  * Context switching is when you switch tasks before completing them. As developers, I believe that context switching is unsustainable and leads to burnout. I try to be aware of this and eliminate context switching as much as possible. Stay focused on one thing at a time.
  * AVoid
    * lose flow
    * commits become larger
    * use unnecessary brain power to start and stop tasks