Refining the Flow: A Streamlined Markdown/Git-Based Task Management System for Solo Developers

Task Management: A Constant Evolution

Effective task management is crucial in software development, particularly for solo developers who manage all aspects of a project. Over the years, I’ve experimented with various systems—Zettelkasten, Eisenhower Matrix, Agile methodologies, and more—each offering unique benefits. In my previous blog post , I detailed a structured prioritization system that balanced immediate tasks with longer-term goals. While this approach was effective for managing multiple responsibilities, it became clear that a more streamlined system was necessary as my focus shifted toward solo software projects.

In solo projects, where you serve as the developer, project manager, and sometimes even the client, task management needs to be as simple and fluid as possible. The goal is to maintain focus on coding and problem-solving rather than managing too many tools. This realization led me to refine my system, integrating task management directly into my coding workflow using a simple, markdown-based approach.

The Workflow

To streamline my workflow, I categorize tasks into four main priorities (as described in my previous post), a system that has proven effective across different contexts:

• P-0 (Immediate Tasks): The most urgent tasks that needed to be tackled right away. This list is kept very short to avoid overwhelming stress and serves as a critical indicator of workload and pressure.
• P-1 (Sooner than Later): Important but not immediate tasks that are next in line after P-0. These tasks typically feed into P-0 during calmer periods.
• P-2 (Obligations): A catch-all for tasks with no pressing urgency. These are often obligatory tasks that lack clear motivation, leading them to become “write and forget” items.
• P-X (Excitements): A short list of tasks that genuinely excite me, crucial for maintaining motivation. Tasks here had to be interesting enough to merit their inclusion.

Each day, I draw from these categories to form (at least in my head) two lists:

• Do: What I plan to accomplish that day.
• Look forward to: Tasks that spark enthusiasm.

This daily focus ensures that I stay on top of urgent work while also engaging with tasks that keep me motivated. The workflow works well for managing multiple streams of work, balancing motivation, and handling obligations.

The System

• Challenges with previous MS OneNote based system

  • As I transitioned to solo development, the need for a more integrated and fluid execution system became apparent.
  • Managing tasks through MS OneNote caused frequent context switches, often disrupting my flow state.
  • Also, the subpar support for Linux was a bit problematic.

• Switch to Markdown+Git:

  • I had experimented with markdown-based task management before, but it wasn’t until I faced these challenges that I fully embraced it.
  • Markdown, combined with Git, became the system that brought everything together. This approach integrates task management directly into the coding environment, minimizing context switches and keeping me in a productive flow state.
  • With markdown, I manage different types of notes and tasks in a way that aligns with my workflow but is more streamlined.

Ideas/Brainstorming/High-Level Deliberations

For non-project-specific tasks or high-level ideas, I follow this implementation:

• Inbox: Everything starts in an inbox.md file, which acts as a simple task list. Items here are sourced from random notes in Google Keep, spontaneous thoughts, or ad-hoc notes taken with pen and paper.
• Todo: Items move from inbox.md to a /todo.md which is a prioritized task list according to the previous workflow P0/PX/P1/P2. Ideas or refinements of thoughts or brainstorming’s dont move here.
• Ideas: These items are moved to specific files like ideaOrNoteTypeTitle/someFileName.md or /notes/ideaOrNoteTypeTitle.md. These files are generally similar to P-X lists, focusing on ideas that excite me but aren’t immediately actionable. These files are created as needed, and generic catch-all files (e.g., notes.md) are avoided.
• Sample folder structure:

  1root/
  2├── inbox.md
  3├── todo.md
  4├── notes/
  5|   ├── new-thought-1.md
  6|   └── meeting-notes.md
  7└── my-grand-idea-1/
  8    ├── what-i-want.md
  9    └── components.md
  

I experimented with Foam Bubble , a tool that enhances markdown files with features like back-linking and graph visualization. However, in practice, I found that a well-organized files and folders graph was sufficient for my needs. Non-actionable items or notes kept for the sake of it tend to clutter my mind. Over time, I’ve realized that I’m truly interested in only a handful of topics. Fleeting thoughts often accumulate in my inbox.md (previously the P-X or P-2 box), but I rarely act on them. Discarding these after a period has helped me maintain a clear head-space.

Also, I have kept these files in my private GitHub that contains my blogs content. This has had its additional benefits, with one of the main advantages being keeping all my content in one place.

Project-Specific Tasks

For project-related tasks, I maintain a single /todo.md file within each project’s repository. This approach eliminates the need for context switching, allowing me to manage tasks directly within the development environment. Markdown’s simplicity—just plain text with minimal formatting—makes it an ideal tool for this purpose.

The new system maintains the core principles of my workflow but is more integrated and efficient for project management.

1. Project Overview:

   • Each project begins with a high-level overview in the todo.md file. This section serves as a brief, bullet-pointed design document, outlining the project’s goals and scope, particularly focusing on what’s necessary to reach the MVP (Minimum Viable Product).
   • This overview is the foundation, and categorized as P-0 and P-1 system, but it is now directly tied to the project’s progression.
   • Aim is to first burn through these tasks first and at speed without a lot of distractions.
   • During this run, the subsequent sections get populated.
   • Again, until this is done, nothing from next things get worked on.

2. Running Laundry List:

   • As development progresses, new tasks naturally arise.
   • These tasks are added to a “running laundry list” within the markdown file.
   • This list is dynamic, constantly evolving as the project moves forward.
   • It is categorized as P-0/P-1 only and anything P-2 is added to the next section.
   • I tend to mix/re-prioritize things that are P-1 as P-0 if they excite me to some extent (i.e my original P-X).

3. Pushed Out (i.e Backlog / Future Unknown):

   • Tasks that are still relevant but not immediately actionable are moved to a “Pushed Out” section—similar to a backlog but with a more critical filter.
   • This section corresponds to P-2, focusing on future possibilities that excite me or hold significant potential.
   • I tend to visit this section at some larger interval. Like my inbox, I have preferred to completely discard things from here if they have accumulated for quite some time. This avoids overthinking and enables a clean head-space.

Challenges and Adjustments

1. Mobile support:

   • One significant issue is mobile support. Editing markdown files on mobile devices, especially within Git repositories, can be awkward and frustrating. I experimented with GitJournal and other similar tools designed to manage Git-based markdown files on mobile, but the experience was not great.
   • Editing in a mobile environment often felt jittery and unreliable, which disrupted the otherwise smooth workflow.
   • Also, editing markdown text on mobile and running the git workflow with it, just doesn’t feel right.
   • For quick, on-the-go notes, I use Google Keep, which I later transfer to markdown files. These notes are later transferred to the appropriate markdown files on my desktop, maintaining a single source of truth for all my tasks and ideas.
   • For reading my current notes, GitHub mobile app is more than sufficient.
   • Maybe there will be some bridge that will block a lot of git updates etc from mobile but still allow a smooth inbox population. While a more refined mobile solution would be helpful, this current setup is sufficient and doesn’t pose a significant barrier to my productivity.

2. Daily list

   • I have moved away from creating an actual list for daily things (i.e Do and Look forward to).
   • It just sits as two bullets in my todo.md files so that I remind myself of the need to do it that way, but doing daily lists just doesn’t work out well.
   • The items are still present, but “virtually” in my head.

3. Tool choice

   • Lot of folks seem to suggest that Obsidian will give me best of all worlds, but that has not been the case for me as of now. May be I need to take a leap of faith at some point I suppose.

4. Personal life

   • Like last time, none of these systems have worked for my personal life.
   • For personal tasks, I find an ad-hoc approach works best, with any minimal needs managed in Google Keep.

Final Thoughts

Markdown’s minimalism is its strength. Without the distraction of unnecessary features, I can organize tasks in a way that aligns perfectly with my workflow. It is just another text file with some styling indicators. The categories of P-0, P-1, P-2, and P-X are still present but simplified and their movement is more fluid.

As my work continues to evolve, this system will likely adapt with it, but for now, it strikes the right balance between structure and simplicity, keeping me productive and in the flow. It somehow, “feels right”.