|
The main thing I've found to help when juggling multiple side
projects is to reduce the friction and the number of tools
involved. I live in the terminal with tmux, emacs, org-mode, and git. My
projects get an index.org in their base directory which
describes the purpose and tasks involved. I've moved to (but this
isn't essential to the concept of reducing friction) literate
programming, and each source file ends up with its own org file
as well [0], like foo.org for foo.c. My index.org contains
a list of bugs, features, etc. as headlines. Each of those
headlines contain notes on reproducing the bug, identifying where
it occurred, specifying where the feature will be placed,
etc. Specific things inside it become TODOs, which can be quickly
found by (in org-mode) doing C-c / t which will highlight all
TODO tasks in the file. In foo.org I use the same approach. I
have an outline of the source file: * Purpose
* Includes
* Declarations
* [0/3] Definitions
** TODO foo_bar: int -> int
** TODO foo_baz: char* -> int
** TODO foo_quux: void -> void
So now everything I need to know about the project is in one
place. And by virtue of it all being in the repository (and
hopefully backed up somewhere online like github or my personal
server, when I had one), I can easily move between
computers (modulo tooling, but mostly I just need emacs + git +
tup + <compiler>).I can also put a great deal of configuration information into
this. What tools need to be installed, what are my
dependencies (for packages/crates/etc.) and why do I depend on
them. As I'm starting to play with docker and containers, I can
include all the steps needed to reproduce the environment and
configuration. So by reducing the number of places I need to look for
information to a handful of org files, I've greatly reduced the
effort required to resume a project. I can also do everything
offline, which is great for me because an open web browser means
I'll lose the evening's productive hours. [0] I originally did one big org file that spit out files into
src/foo.c and inc/foo.h, etc. But that became annoying so I
switched to individual files. This improved my ability to reuse
code from one project to another (these being personal projects
I'm not always spending enough time to justify producing a proper
library). And it helped with make/tup because a change to
foo.org only affects things depending on foo.c, where
index.org would affect many build rules because it produced so
many files. Fine in a small project, annoying in anything big. |