Learning Just Enough to be Effective

It seems like there is increasingly more and more to learn out there. This is especially true in the software profession. I always feel like I am swimming in a huge ocean, trying to keep my head above water. And the ocean keeps getting bigger and deeper every day. But there are ways to tame this metaphorical ocean. I wanted to talk about a specific case in this blog.

As a long term Vim user, I avoided learning Emacs for the longest time. In fact, I had put it onto my To Don’t list for the longest time. Do not touch Emacs, you’ve already learned Vim. There is no need. Just use a variety of plugins and UNIX shell facilities with Vim and you’ll be fine.

And this worked for me for most of my work and personal life (although I do use Jetbrains products at work all the time). Still does. I still didn’t care about Emacs. Until I discovered Org-mode.

Org-mode is pretty nice. It allows for good management of TODO lists out of the box. The tags, labels, priorities, all make it a good tool. It’s free. Your data is yours forever. It works on all platforms. It has a coolness factor. It’s more than likely to continue in development and maintenance for a long long time to come, and won’t suffer the fate of a tool backed by a corporation because of political or financial reasons.

And yet, learning Emacs is notoriously steep. The amount of time that people can potentially spend customizing their Emacs setups can be extremely large. The old saying that people who use Emacs do everything in Emacs is true. And as an established software developer who also wants to do other things in life, I did not want to invest that much time. It wouldn’t have been a good investment. All I wanted to get out of it was Org-mode.

Emacs is an ocean. My fancy was just a little floating island in this ocean, i.e. Org-mode. Even org-mode can be too large and has a lot of functionality. I just wanted a little piece of the island. Something that I would use every day.

I know it’s possible to emulate some org-mode functionality inside of Vim or Visual Studio Code. But it is not the same thing™. Emulation is never the whole thing. Anybody who has experienced Neovim can tell you a Vim plugin inside IntelliJ or Visual Studio Code just feels like an incomplete, inadequate experience.

The solution was a targeted Udemy course that taught me just enough to be effective. Just enough org-mode and Emacs. And now I use Org-mode within Emacs all the time at work and also in personal life — for managing TODO lists and projects, as well as archiving finished projects — with fancy tags, labels, completion percentages, and priorities. And yet I remain a loyal Vim (now, Neovim) user, and also a Jetbrains user when the task at hand needs a bulldozer rather than a Swiss Army knife.

A good rule to live by. I’m a lifetime learner. Learning is a daily activity for me. A part of my job. It’s always worth your while to learn new things. Sometimes that new thing might be too similar to what you already know, and then you question whether it’s worth your time to learn it, and indeed it might not be worthwhile to learn everything about that particular new thing. In those cases, learn just enough to be effective.

Maintain Color-Coded TODO Lists in Vim

Many Vim enthusiasts use Vim for pretty much all text manipulation in their daily lives. However, the plain text nature of this fantastic and powerful editor sometimes leaves a little left to be desired. For example, it would be nice to have your editor color code certain items in your TODO list for you, e.g. one color for items that are done in your list, another (hopefully a more provocative one) for those that aren’t done. I recently discovered a trick how to kind of make that happen in Vim, and I am sharing that here.

The first thing you need is some type of a marker in front of your rows that you want highlighted, so that Vim has a way of doing a RegEx matching against them. E.g.

[TODO] Write a blog post
[DONE] Goof off
[Nice to Have] Read a book

Here I have marked my rows with [TODO], [DONE], and [Nice to Have]

Next up, you need to invoke the following command in the command line mode:

:highlight MyGroupTodo ctermbg=red guibg=red
:let m1 = matchadd(“MyGroupTodo”, “^\[TODO.*”)
:highlight MyGroupDone ctermbg=green guibg=green ctermfg=black guifg=black
:let m2 = matchadd(“MyGroupDone”, “^\[DONE.*”)
:highlight MyGroupNTH ctermbg=cyan guibg=cyan ctermfg=black guifg=black
:let m3 = matchadd(“MyGroupNTH”, “^\[Nice to Have.*”)

Here is a screen capture of what it looks like in my current color scheme. Keep in mind that the appearance might be different based on what color scheme you currently have enabled, and you might have to change the colors of the matches to better suit your tastes and your color scheme. Furthermore, you can put these highlight and match commands in your .vimrc so that you don’t have to keep doing it over and over.

Being a visual person I appreciate colors and the ease of distinction that they provide. If that’s you, and you use Vim, then this is how you can do it. Look up :h match inside Vim for more detail. Notice that, in contrast to the example in the Vim help, I have used more specific regular expressions so that the entire line is highlighted – you might or might not want that.

Panoply: Console-based TODO list manager

That’s right, yet another todo list manager. I am calling it Panoply, for no other reason than the fact that I like that word. Well, it is a learning project. I wanted something that does not depend on having an Internet connection all the time (e.g. Wunderlist and Teux Deux) (it is possible that those awesome products have offline modes, but still), and something that is free (unlike Things). More importantly, I wanted to check the feasibility of Python for building, testing and maintaining a relatively larger project. It certainly doesn’t have the graphical finesse of the apps mentioned above, but if I ever decide to go in that direction with it, it will be yet another learning adventure. As it stands right now though, Panoply remains a CLI app.

It’s still very much in a pre-alpha stage, but I have something running and working that I can now keep tweaking and enhancing. I am trying to follow Test Driven Development in this project as faithfully as I can (though I guess I could be better). The goal is essentially to write a command line tool in Python that helps with deadlines and in managing personal tasks. It is supposed to be an app that automatically adjusts itself somehow, based on current deadlines, future deadlines, and past overdue deadlines, so that it is better than a plain text todo list. I am the sole developer, user experience designer, user interaction designer and the tester of all things for now. I am hoping that that would change at some point. The data model that Panoply is currently using consists of simple CSV files. This aspect of the project might very well change in the future if I feel the need for a better data structure.

My idea is to keep the scope minimal, and enhance it one feature at a time. As it stands right now, if you were to test the app as of the day of writing this blog entry, it lets you start a task collection, add a task to the collection with a user name, and let you save and load the entire list of tasks. I am currently also supporting the functionality to selectively check off items so that you can mark them as ‘done’ and they no longer show in the list when you view it. Last but not least, I support the ability to scan the list of tasks and tasks collections and prompt the user that they need to hustle if they have a task listed that has a deadline past the current date (termed ‘overdue’ in the Panoply universe).

I am having a lot of fun with this project, trying to hack on it for 10 minutes every other day. My full time job and other obligations don’t allow for more at this point, but Panoply will certainly grow with time.