I have a reco today that’s a little different. It’s not for a particular program, but for a methodology that I’ve been using for quite some time.

Beginning a new project can be daunting. Everyone already knows that. Trying to organize my thoughts is difficult, especially for larger projects. “How do I get XYZ accomplished?”

What I’ve been doing for years, and not just for coding, is simply making outlines of what needs to be done. My personal methodology has been evolving over all of the time that I’ve been doing this and has become pretty specific. The end result (as seen in the screenshot above) is a todo list that’s organized as an outline. I’ve actually developed a Vim syntax file that color-codes it, and that color-coding has become extremely useful. (This is the same format as my notes files on GitHub.)

The key is as follows:

• > = Todo
• + = Done
• * = Information
• – = Canceled
• : = Title
• ! = Important to remember
• ? = Unanswered question

This doesn’t follow the specific rules of outlines that are taught in English classes. For example, it’s not uncommon for me to have only one subpoint. There’s good reason not to do this in a slideshow presentation, but it doesn’t really apply to these outlines.

Despite how specific the structure is, the content is very fluid. Throughout the course of a project, what it starts out as in the beginning could be radically different from how it ends up as by the end of the project. It’s not a “This project must follow this exact course” outline, but, instead, is essentially my thoughts written down. Todo points may be added, information points will definitely be added, entire sections could be added or canceled (I try not to actually delete so I don’t accidentally lose important information), etc. This helps me to organize everything as well as just remember everything. Additionally, the indented format lets me use Vim’s indent code-folding method (or, in my case, an expr called “ModifiedIndent”, which you can see on my GitHub), and keeping these files helps me more easily pick up an old project months or years after I haven’t touched it if/when I need to.

Of course, I would never say “This is something you have to do.” That’s actually the case for all of my recos, but, in this case, it’s especially true. I’ve very much come to recognize Matt Hartley’s favorite catchphrase, “Different strokes for different folks.” This is something that came about for me while I was an undergrad in math– Start solving a problem by writing down everything I know. (Come to think of it, I may have picked it up from the way they do differential diagnoses in “House”.) It evolved from there and has become an essential part of how I think.

This last part is slightly off-topic, but the screenshot above is from a project that I’ve just started (hence all > and no +). It’s a program that I’m writing for my sister to help keep track of time, based on a VBScript program that I wrote for myself a while ago (at the time, I didn’t know PowerShell). I was describing how I had a script run once an hour and prompt me with “What are you working on right now?” Then it would store the result in a CSV file, which I could later open in Excel and count how many hours I spent working on any individual project. She said that would be very useful in her line of work, and, huzzah, a C# project was born. If it were just for me, I would probably just use either PowerShell with Windows Task Scheduler or BASH with cron, but, if I want to share it with others, I’d rather have one package do everything (and, in this case, a GUI program). I’m hoping to be able to use Gtk# to run it cross-platform.

That’s all for right now. Thanks for reading!