Gap Year Updates #1: Staying Productive in the Time of Corona


A few weeks back, I wrote a private reflection recapping the events and changes I’ve gone through since quarantine began. This post serves as a follow-up exploring how I’ve rethought my methods for staying productive, focusing particularly on task management.

Thoughts on Productivity

Embracing OnePlus’ motto of “Never Settle,” I’ve constantly sought out new ideas or apps in a quest for improvements to my quality of life. When I do decide on an app or a system, it’s usually not long before I find something frustrating about it. Sometimes this works out and I find useful ideas for personal projects, like, QuizDB for iOS, Flashcard Adder, and an in-the-works e-book reader app. Other times, I end up spending more time looking for nonexistent better alternatives instead of working with what I have.

I’ve been trying to work on this since the start of quarantine and in particular since my gap year ‘officially’ began in August. While I’m still giving myself room to explore and try out new things (after all, sometimes shiny new toys can prove useful), I’ve started focusing on developing actual workflows within these tools to achieve my goals. The systems I implement and the ways I improve on them over time are more important than the apps I choose, but they must be refined to play well with the available software.

Task Management Woes

I used to spend an inordinately long time implementing my desired workflows through inefficient workarounds. Back when I used Todoist, I implemented a habit tracker with Habitist, which involved learning Heroku app deployment 1. My largest barrier towards actually getting things done ended up often being my preconceptions for how to get things done. After putting in the time to set up whole new apps or systems for task management, it wasn’t long before whatever new fragile system I built fell apart under the strain of a busy stretch. Things usually broke down into completing assignments the day before they were due and then spending my free time working on whatever one side project was occupying the most prominent amount of space in my mind. Everything else fell on the back-burner, and the friction often involved in adding new tasks I sometimes avoided adding them. I spent more time setting up my systems than actually using them.

When my carefully crafted systems fell apart, I sometimes reverted to writing down my most important tasks and goals on paper. What’s great about this analog system is that its limitations force me to rethink how to structure my workflow to work with it. There are many inconveniences to deal with in a paper-based system solvable in a digital app, but the challenges of paper make it easier to quickly create something meeting my immediate needs. With digital apps, everything feels like it should be possible, so when I tried to make my digital system do more than paper, I’ve often found my tinkering just made things worse.

In part, these failures suggested that my notions for how to get things done could use work. So, a few months ago, I read David Allen’s aptly named book Getting Things Done. Like most self-help books, it’s quite possible to boil down the main ideas from the book into a relatively short article, and of course, there are many of those out there already. If you have the time though, I think there still is value in giving the real book a try—I find it generally easier to absorb ideas from a book than from condensed summaries. I won’t summarize the book here, but I’ve incorporated many of Allen’s ideas into my workflow and do recommend reading at least the first half of the book.

When I redid my system after reading Getting Things Done and some other guides, I chose to stick with Things 3 as that was my task management app I was already using 2. It’s a beautiful app with design choices inspired by the Getting Things Done system, and Cultured Code (the developer of Things) provides a useful introductory guide for getting started that’ll put you in a decent place productivity-wise. Personally, however, not all of their advice stuck when I first read it, so I doubt a little informational redundancy will hurt here. In this post, I’ll provide a more detailed look at how I’ve personally worked with Things and a few helper apps to develop a task management system I’ve been happily using these past few months.

Things 3 Overview and Potential Problems

Like all task management apps, the basic building block in Things is a task (AKA a To-Do). To-Dos are generally discrete, actionable items completable in a single session of time. Projects contain a list of actionable tasks that, when completed, typically result in an end accomplishment. Tasks and projects can be grouped under an area as well as labeled and filtered with an arbitrary number of user-specified tags. Within a project, headers can optionally group different tasks to provide visual separation. A Project and its tasks typically aren’t completable in a single session. This contrasts with subtasks for a task, which represent minor steps or checks for completing a task. However, this difference isn’t sharply defined and whether you choose to employ a project with tasks or a task with subtasks is up to you, but I encourage you not to be hesitant about having a lot of projects. I personally rarely use subtasks—only as a checklist of things I check to make sure I covered everything I needed to for that task.

It can be tempting to think that this makes for a folder-like hierarchy of Area -> Project -> To-Do -> Checklist/Subtasks. When I began using Things, this is what I envisioned, but this categorization system is not strictly hierarchical. Nearly all my tasks don’t contain subtasks, and I have a sizable number of tasks (e.g “Fix Spotify local files on iPad”) within an Area rather than within a particular Project. I occasionally also have projects and tasks that don’t fall into any Area.

For a concrete example of these differences, my Personal area has the project “Productivity System Blog Post” with the tasks “write first draft,” “edit draft,” and “upload to site.” Within the “upload to site” task is a list of subtasks I’ll check to make sure I cover before I post. Inside Personal, I also have singular tasks like “Fix Spotify local file play on iPad.” I also have a few recurring tasks in Personal like “Conduct weekly review” and “Review book list in Calibre.”

In addition to this organizational system, Things has the built-in lists of Inbox, Today, Upcoming, Anytime, and Someday. The Inbox is a list of unsorted items, Today contains items that have been assigned a start date or deadline of that day, Upcoming shows a list of items with upcoming start dates or deadlines, Anytime contains items without a specified due date and not placed into Someday, and lastly Someday contains To-Dos and Projects that aren’t likely or able to be worked on at the current time.

For the most part, these built-in lists are pretty self-explanatory, but it’s easy for the lines to become blurred and cause problems. The Inbox might grow into a large dump of way too many unsorted tasks, or it could be underutilized/not utilized at all. If there are too many tasks in the Today view and tasks are frequently left incomplete for the day, Today becomes essentially a higher priority Anytime list. If there is an overload of tasks in Anytime, it can effectively become just another Someday list. In turn, Someday can grow into an archive of tasks and projects that will likely never be completed but that one doesn’t have the heart to trash. Similar problems can arise when working with Areas, Projects, To-Dos, Headers, Tags, and Subtasks. In particular, it’s hard to strike a balance between too few and too many tags. In the new few examples, I’ll go through times when I’ve encountered issues like these during my time using Things and how I’ve adjusted over time to create a more cohesive system.

School: Projects, the Inbox, & Built-In Views

While in high school, I could never really figure out how to properly organize homework and other class-related tasks. For a while, I kept a project for each class. Almost all homework, except for extremely long-term projects, was stored a singular task sorted under the corresponding class ‘Project’. Later on, I wanted to have Headers in my Areas for each class, as I was reluctant to take the step of creating wholly separate areas for each class. As many classes assigned work infrequently, I was often left with empty Projects taking up space on my sidebar. I struggled to always add tasks as well, and when I did I typically bypassed the Inbox step. My Today view also often featured tasks I hoped rather than needed to do that day, leading to many tasks carrying over day after day as I failed to complete them. For a time, I started using tags to label different classes but grew annoyed by the additional steps it took to do so.

My problems in these circumstances largely stemmed from my attempts to use Projects similarly to folders, as a tool primary for organization. When I began using headers, I was reluctant to make projects for homework, as to me that would break my precious organization. Looking back now, I think there was little use in my preconceived notion that all my class-related tasks needed to be organized under a label for that specific class. After all, organizing them on aggregate with the School area would have been fine; there wasn’t much point differentiating when each class typically had no more than a few tasks/projects going on at once (and some rarely ever had any). Without these sometimes empty projects taking up space, the sidebar would only actual projects containing actionable next-actions.

Solving the problems I faced with the Today view and missing tasks requires a little more thinking and another change in workflow. When homework was assigned, I always immediately tried to add the task in its proper place, going through the slightly cumbersome task of adding a to-do to what I thought was the correct organizational ‘folder’/project. This meant that when I didn’t feel like there was enough time at hand to put the task where it was supposed to be, I sometimes just didn’t add the task. What I should have done more often, however, was use the Inbox list as a parking place for quick notes about tasks. With this as a routine, I would have been less likely to skip and then later forget to add tasks. For simple homework, it might also have been easy to just do it later while cleaning up the Inbox list. If I used the Inbox, this would also allow for more deliberation about whether that homework could benefit from being split up into a project or by being assigned certain tags. For example, I think it would have made sense to make math homework into a project with each problem or chunk of problems as a separate task since for me math typically took up the largest amount of time. If tasks were chunked up in this manner, I would be more likely to complete everything in my Today view, and then be able to move on to my Anytime list with my free time. With an Inbox, I’ve also found it far more fun to go through the process of doing the little tasks and organizing the rest.

Gap Year: Someday, Tags, & Reviews

Since the start of quarantine, and particularly since summer began, most of my tasks are things I’ve personally chosen for myself. The changes in my approach to projects, the Inbox list, as well as the Today and Anytime views, have proven helpful in these circumstances as well, but this period of self-direction has brought to light other issues in my workflow arising from lack of deadlines and the increase of potential things to do (as well as time to do them).

My Someday list has historically been where tasks, projects, and ideas go to die. However, I’ve recently realized how much more useful this list could be. My Someday list now only contains projects and tasks I can see myself doing some time in the next year. To satisfy my need to have an archive of other tasks and wishes for the future, I’ve started to instead store these ideas and thoughts in Bear, my notes app. This doesn’t mean that I’ll do everything in my Someday list within a year (in fact, I definitely won’t be), but keeping this in mind reduces the informational overload in the list. This in turn makes it more attractive for me to browse through every few weeks or when I’m low on tasks and projects currently active in Anytime, Upcoming, and Today. Since Someday is no longer a graveyard, I’ve also become more comfortable putting tasks or projects that require some variable length of waiting before I can continue work, usually due to sequential or collaborative tasks where I can’t complete the task or continue work on the project until whatever roadblock has been cleared.

The importance of having a system for conducting ‘reviews’ has been hammered into me quite frequently, but I’ve always found it difficult to follow through with this task. Now that I’m in a scenario where I’m not overloaded with tasks in the Today view and have regular movement between the Inbox, Today, Anytime, and Someday views though, I’ve found it more natural to complete these reviews. I’ve found going through these tasks to be a relatively enjoyable activity to work on while on a walk or when I’m too lazy to do other work. Since I’ve finally experience how this organizational shuffling is actually useful and somewhat fun to do, this habit has become far easier to keep.

The last major feature of Things I’ve begun employing are tags. Tags have been tricky to get right in the past, and I’ve usually avoided using them at all save for the few misguided times I spent hours retroactively adding tags I later never used. I’ve always found the idea of adding contextual information to tasks intriguing, but I usually went overboard developing an unnecessarily elaborate tagging system. I used to also find adding tags particularly cumbersome in my previous workflows, as they added valuable time to the process of quickly adding new tasks to the correct place in a system.

Since I started using the Inbox, however, labeling with tags has become just another quick step during the Inbox review process when I decide not to immediately work on the task or project and instead file it into the correct place in my organizational system. I’m still continuing to figure out what tags are useful though. Since I began using tags again, I’ve typically labelled tasks and projects with three label types: estimated time for completion (<15 min, 15-30 min, <1 hour, 1-2 hours, long, multitask), tools needed for completing the task (Mac, iPad, iPhone, none), and intensity of task (low, medium, high). I’ve sprinkled in other tags but aside from the waiting tag I’ve generally found them unhelpful. Recently, I’ve decided to stop using the intensity label for now since my intensity estimates tend to be quite arbitrary and when I look back I often disagree with my initial assessments. It’s also usually quick easy to pick something to work on after just filtering with tool and time constraints.

Special Projects

While it’s crucial to recognize that projects represent a list of actionable tasks that will eventually be completed, I’ve personally found it helpful to have two exceptions to the general rule: Store and Review Again. Both of these projects are never-ending and serve essentially as organizational folders, resembling my initial view of what projects are for. However, since there’s almost always many tasks in these folder projects, I don’t find them to be a waste of space the way my school class folder projects were.

I use Calibre and Zotero to store everything I read nowadays, and I love these programs. Unfortunately, both are desktop-only apps 3. When I review the tasks in my Inbox, I don’t always feel like immediately completing these storage/acquisition tasks when I’m on my Mac, and it’s simply impossible to complete when I’m on my iPad or phone. As a result, Store is where I keep links to texts I need to store later. I tag this project with ‘mac’ so they appear on my Anytime view filter for when I’m at my computer. I prefer to bunch up these tasks as doing all of these tasks at once as the repetition puts me into a certain relaxing zen state and I feel likely also saves a sliver of time.

Review Again is a more tenuous addition to my system that currently stems from needing a place to store articles and papers that I want to review another time on my computer or tablet to develop notes and ideas. This list has gotten quite long though, so perhaps there’s a better way to address this situation.

Habit Tracking Routines

I don’t typically use Things for habits I want to do every day—the one exception being a recurring “Walk outside” project contains a list of items I should bring 4. Instead, I track my habits in a simple spreadsheet with a row for each day and a column for each habit. I’ve tried the free tiers of various habit tracking apps, but the restrictions and advertising are annoying and a paid app doesn’t seem justifiable for what is essentially just a nicer looking spreadsheet. While Google Sheets isn’t great on mobile, but it’s not like I have to do much with the spreadsheet each day.

Nagging Reminders with Due

For tasks that need to be done by or at a certain time, I’ve been using Due for the past few years to nag me into actually completing them. This app is wonderfully simple—set a reminder at a certain time for a task and Due will repeatedly notify you about the task until you either complete, reschedule, or delete it. For example, I have reminders to reach out to people, check in on scholarships, and cancel subscriptions at certain (sometimes arbitrarily set) times. I also have recurring reminders for things like “Back up database” 5. Even when my regular task management systems broke apart, I’ve always kept this app handy to nag me whenever I need it.

Update Instead of Replace

People often talk about how they can’t switch away from Apple because they’re too closely tied to the ‘ecosystem’. This is the type of harmony I hope to reach with the software I use with my workflows. Apple regularly updates its products with improvements, and I similarly expect make changes to my workflow when circumstances change, or when I review what’s working and what’s not. But just as how making a change like switching from iOS and Android involves high transition costs and careful decision making, I aim to treat jumping ship from my established systems and software in a similar manner.

I’m currently in the process of applying this principle of standardization to other aspects of my work and life as well.

Five years from now, I hope I can look back and not see many changes to this list, with the exception of my in-development ePub ebook reader of course.

  1. This remains my only experience with Heroku. It was also my first experience with the mess that is deployment 

  2. Apple revamped Reminders in iOS 13 and macOS Catalina, and had I not already bought Things 3, I likely would have tried coming up with a system using that app instead. My system in Things 3 works well for me, and I don’t expect to move away from it anytime soon, but Reminders is a solid app to keep in mind if you don’t want to pay. While I don’t believe my system transfers easily into Reminders, I don’t think it really should. If you start with Reminders, I’d spend some time looking at how other people use it and then experiment with it yourself to see how you can develop a system around that app. 

  3. There are some clients for Zotero on iOS that I don’t use. I prefer using Zotfile and iCloud Drive. 

  4. This could probably have been a task with a checklist, but I appreciate the visual separation. When I don’t walk outside, I cancel the project for the day. 

  5. I know something like a cron job might simplify this further, but I haven’t spent the time learning to develop something that works and Due nagging me works well enough for now.