Being productive

Updated on November 27, 2020
Hello! This page is a draft. Feel free and poke around, but there are significant structural and contentual pieces yet to be implemented. Mind the proverbial construction noise, and feel free to subscribe here to get notified once it's completed:


Why you should listen to me

There are lots of self-centered software engineers who have thought about productivity and blogged about their own spin on GTD. Why should you listen to me?

I don’t have a particularly satisfying answer!

I think I get a lot done. Not to delve too much into Linkedin-core performative business (that’s what the section on “keeping a routine” is for, after all), but I run two multi-thousand-dollar-MRR businesses while gainfully employed as a engineer (or engineering manager, depending on the quarter) at a company most people would be excited to work for.

I work a lot, but not an unsustainable amount: I would peg my level of “time spent in work mode” 1 at around ten hours a day on weekdays and four hours a day on weekends. This is higher than median, but certainly less when I was also freelancing full-time.

I think my philosophy comes down to a few specific things:

If that high-level overview sounds interesting and useful to you (even if it sounds facile — especially if it sounds facile), then I think you should read more.

Employ linear backoff

It is a fairly often occurrence that I don’t get everything done that I want to or plan to in a given day. I think this is largely fine, and probably a Umesh-ism 2 in its own right.

I’m pretty aggressive with what I want to get done in a given day and I often underestimate the mental toll of meetings or switching costs. Tuesdays and Thursdays are my days most heavily laden with meetings; consequentially, they’re also the days where I often fail to complete everything on my to-do list.

“Fail to complete” is a gross phrasing, though. It’s not that I failed to be productive (there are those days, but in general I’m pretty productive) but it’s that I failed to plan out a reasonable workload for my day. And that’s fine!

The real failure mode comes in how I adjust. A very bad idea is to look at the six items you didn’t do today and say to yourself “okay, I’ll do them tomorrow instead.” Chances are, you’re just overloading tomorrow. Then you’ll look at the eight items you didn’t do tomorrow and say “okay, I’ll do them the next day instead.” All you’re doing is snowballing your misery until (if you’re like me) each time you glance at your list of work you feel overcome in dread and anxiety and you discard the process entirely.

Instead, take the time and do linear backoff: only allow yourself to allocate one item per day. If that’s absolutely impossible (say, you have two hard deadlines that you must meet by tomorrow), negotiate with your former self by pushing out some other item that you already allocated.

Employ read-only and write-only modes

The knowledge sector’s insistence that productivity is a personal issue seems to have created a so-called “tragedy of the commons” scenario, in which individuals making reasonable decisions for themselves insure a negative group outcome. An office worker’s life is dramatically easier, in the moment, if she can send messages that demand immediate responses from her colleagues, or disseminate requests and tasks to others in an ad-hoc manner. But the cumulative effect of such constant, unstructured communication is cognitively harmful: on the receiving end, the deluge of information and demands makes work unmanageable. There’s little that any one individual can do to fix the problem. A worker might send fewer e-mail requests to others, and become more structured about her work, but she’ll still receive requests from everyone else; meanwhile, if she decides to decrease the amount of time that she spends engaging with this harried digital din, she slows down other people’s work, creating frustration. Cal Newport, The Rise and Fall of Getting Things Done

A failure mode I often run into is that I treat my todo list like a stack (first on, first off) rather than a queue (first on, last off.)

This is common. A coworker asks you a quick question and you want to get back to them immediately; a customer emails and you want to impress them by responding in less than five minutes. You assign yourself things that pop up: “Oh, I need to check the mail;” “Oh, I should see how the metric is doing;” “Oh, I need to talk to that team about their revised timeline for the project.”

These tasks are sometimes small and they are sometimes big. Regardless of their size and importance, they should be delegated to your inbox as soon as you’ve narrowed in on what you’re trying to do today. Don’t let the specter of immediacy spook you into thinking that its more important than the things that you’ve already outlined as important!

When I first read advice like this, I was skeptical. “That works if you’re some executive or senior employee, but I don’t have the leeway to ignore people as a junior engineer,” was the genre of riposte I conjured. And to a certain extent this is true: there are certain genres of task that you don’t the luxury of scheduling for your future self, especially as a lower-level engineer. But that genre is smaller and more fleeting than you think. If you’re a young professional in industry, the most important skill you can nurture is the ability to consistently and mechanically accomplish well-scoped tasks in a timely manner, and being disciplined on how and why you get randomized helps with that, not hurts.

A useful exercise in determining how effective this approach is: try it on a random day. (If you’re really worried about your team or your company getting mad at you, try it on a weekend or a day off.) Set aside a time — say, two hours after you wake up — as a deadline for adding things to your list to do, and force yourself to put any incoming things in a pile to the side to review at the end of the day.

If you are anything like me, you will be shocked by two things:

Employ a weekly review

It’s not about the task lists or tickler files or whatever. It’s about being able to take complete stock of your life on a regular basis. Everything else is based on that. You get everything captured and in one place so you can look at it and say, “Okay, is this working?” madhadron

Failure cases

Ignoring your list

Here is a standard failure case that I run into:

  1. I collate my list of twenty or so items for the day. (The number of items doesn’t matter; just imagine that it is a healthy and reasonable amount of work for the day.)
  2. The list contains some items I find uninteresting or distateful. Going through some annoying emails, say; or perhaps finally cleaning out the gutters.
  3. I remember some work that is not in my list but is something I want to do eventually: maybe a fully-scoped ticket on an epic that I haven’t quite committed to, or an interesting blog post idea.
  4. I spend a large amount of time working on that instead.
  5. It is now the end of the day, and my list of items is much less burnt-down than I had hoped and planned, and so I despair.

It is easy to trick yourself into thinking that working with urgency and focus is a good substitute for working on the most important and urgent thing. It is always a lie! If those exciting work items that you’d rather do instead are the right thing to work on, then they should be part of your list; if the items that you don’t want to work on are truly avoidable, then just delete them from your list.

But ignoring your list is a slippery slope. The list only works when you can have absolute faith and reliance in it; as soon as you start second-guessing it, it is just a fake way of pretending that you are Working On The Right Thing.

Further reading

  1. If this sounds vague, that’s intentional. “Time spent at my desk” is a close but imperfect answer — I get a lot done on my iPad, as more and more of my time is spent reading or writing. 

  2. “If you’ve never missed a flight, you’re spending too much time in airports.”