#lifehack

Getting things done is a great way to keep moving forward in life with a sense of satisfaction. But sometimes, all one really needs is closure, and quitting is a perfectly good alternative.

I spent a good deal of time chipping away at creating a commenting system for this blog. The way it would work is that you would have a simple JavaScript-based submission form at the bottom of each post, and comment submissions (aka, replies) would traverse an AWS CloudFront Function for a clever spam check1 and an AWS Lambda Function for actual processing. Processing would result in the comment data (consisting of a simple name and reply enriched to create a child post that rendered beautifully below its parent) being sent to GitHub as a pull request, authenticated to my personal account that hosts the source code for this blog. I would then review and manually approve these pull requests as they came in (I didn’t expect much comment traffic anyway).

But I remained on the fence as to whether I even wanted to make this blog that interactive, and I never did get to a solution that motivated me to complete the work. And the work stayed in a limbo until two days ago, when I finally decided to abandon the idea altogether. And now a weight has been lifted off my shoulders….

1

The idea behind the clever spam check was to track a sequence of calls to CloudFront as the user navigated the site, and match this sequence against a state machine on the server side (using a key-value store available to CloudFront). For instance, a human would focus the text box and then type several characters — each of these ‘human-like’ events would generate calls to the server that drove the state machine. The state machine itself would remain hidden from view to the user, so while a bot could, in theory, replicate the call sequence, doing so would be a lot more challenging process to undertake.

One of my principles in life is that when someone hands you your cup of coffee, you take a sip immediately. You don’t wait (until it cools, until you sit down, etc.). One sip. Now, not later. And of course, this principle extends to all beverages.

What this one sip gives you is peace of mind. No matter what random event causes you to spill your beverage after that, you can rest in the knowledge that you’ve already had at least a sip, and no one can take that experience away from you.

As we get older and gain more experience, the one thing we get better at, I think, is learning not to react to the world around us as readily. Recently, I was reminded of the idea that this is a mindset that we choose to adopt — we are either responsive or reactive to situations. Responsive is good; reactive is bad. Responsive means that we’ve taken a moment to digest external input and formulate a line of action. Reactive, on the other hand, implies a lack of intentionality on our part.

But I like to think of it thus:

To think before you (re)act is wisdom; to refrain from action altogether is Zen.

The root of the idea is this: nothing is ever as bad as it seems, and nothing is ever as good as it seems. In fact, facets of the same situation may simultaneously be better and worse than expected. Not only is the future unpredictable, it is also a continuous flow of moments, not a discrete set of milestones that we win or lose. All of this is summarized pithily in the Persian adage, “…and this, too, shall pass”.

But I’m not suggesting that we give up on our wants. Rather, I have found it to be true (more often than not) that taking no action is the quickest and most effective path to getting what you want, and all your actions or reactions, though well-intentioned, only tend to get in the way. Have you ever had the experience of working hard every single day, never taking a break because you’re worried that everything will fall apart if you do, and then one day you finally take a vacation for three weeks, and disconcertingly what happens is…nothing at all — everyone carries on just fine? In a similar vein, things that seem like huge problems often melt away; the real problems are the ones that come out of left field.

To avoid taking action requires a great deal of patience, and to be patient, one needs boundless optimism that all the right things will magically happen, that the universe will conspire to help you, and that everything will fall into place.

Be unreasonably optimistic.

I’ve been mulling over an idea for Getting Stuff Done™ that I think could be highly effective, but I haven’t had a chance to prove it out yet, so here goes. The aim is to define a 100-day plan for any objective that you want to accomplish. For some time now, I’ve been wanting to build a structured text editor, so I’ll use it as an exemplar of a 100-day plan.

tl;dr Define an objective, then break it down recursively into a linear sequence of smaller items; on every day that you can prioritize the objective, pick the next item and make it happen. If it turns out that the item is too large to complete in a day, break it down into smaller items. Don’t worry about gaps and distractions as long as you’re able to spend time towards your objective at least twice a week. There is no end date…but you will likely get done sometime within 6-12 months.

Background

The concept of a 100-day plan comes from two existing and popular tools for planning and execution. The first is conventional goal-setting, where you establish a time-bound target state that you wish to achieve. A goal has a what, when and a why clearly spelt out, together with exit criteria. The second is the concept of a “90-day plan”, where you organize a team to work towards goals that complete within a 90-day horizon (in business days). We adopt these ideas with a twist: in a 100-day plan, we don’t track any dates; instead, we are opportunistic about finding time to work on the things we want, recognizing that there may be other potential priorities at home and work taking precedence.

Details

A 100-day plan begins with you carefully thinking through what you want and writing it down as the “objective”. There is emphasis here on the words “you” and “want”. Don’t work on something that somebody else wants, or tasks you can’t articulate the value of (to yourself).

Objective: Build an interactive application for creating, modifying, viewing, and querying syntax trees through text-editing and command-execution interfaces, that supports arbitrary user-defined grammars. So what: Operating on syntax trees is an intuitive and powerful way of developing and maintaining software, and I want to advance the state-of-the-art of tooling on this front.

Notice the two-phase expression of the objective in terms of both “what” and “so what”. The latter is an important part of any goal expression, tying this goal to a higher level purpose that has been established a priori. It keeps your work grounded and minimizes “yak shaving”.

“Yak shaving is what you are doing when you’re doing some stupid, fiddly little task that bears no obvious relationship to what you’re supposed to be working on, but yet a chain of twelve causal relations links what you’re doing to the original meta-task.”

Yak Shaving Illustration by David Revoy. The character Pepper is depicted literally shaving a yak. License: CC BY 4.0

Notice that the objective stated above has no target date. This is a distinguishing characteristic of a 100-day plan — you don’t worry about when it is going to get done; the journey matters more than the destination. Instead, you mark off each of the days that you’ve made substantive progress towards your objective. You celebrate your successes and ignore your failures, which is as life should be.

In the case of my project, I can break it down into the following items:

Users can launch the command-line application and use it to:

  • Create, modify, view, query files using built-in or user-defined grammars.
  • Define their own grammar.
  • Define their own queries.
  • Query files using a built-in grammar.
  • Create and modify files using a built-in grammar.
  • View files using a built-in grammar.
  • Parse the buffer and get reports of syntax errors.
  • Query arbitrary text files with built-in queries.
  • Save files to the filesystem.
  • Create and modify arbitrary text files.
  • View arbitrary text files.
  • Load files from the filesystem.

I think this is a good list of items to begin with, though I expect to break them down further as I learn more. Notice that I’ve worked backwards (from top to bottom) to break things down. So the next step is to start from the items at the bottom and complete them one by one. My hope is that each item is small enough that I can complete it in a day and tag the item with the date of completion, otherwise, break it down further.

I was heavily inspired by Your Life in Weeks for the idea of a 100-day plan — a worthy next step would be to turn it into an analogous visual tool.