Some thoughts on work productivity
I’ve been thinking a lot recently on how to get more done. I’m currently in the middle of a few different consulting projects, a side project I hope to one day monetize and a bunch of full-time job stuff. On each, I am acutely aware that how fast I iterate is one of the largest determinants of success, if not the largest.
I’m writing this post in the second person for myself. For all self-help-y advice, I believe there is no one-size-fits-all. At some point, all of the below have worked for me, which is why I’m reminding myself to do them. Here are some things I think I’ve learned over the last year; they may be wrong, but they’re the best I know right now.
Track everything (what gets measured gets managed)
Measure everything, categorize everything and actively manage everything. I have become a huge fan of Toggl and now use it to track all coding, project planning and writing I do over the course of a day. If I go for a run, it’s going in Map My Run. If I think of an idea, it’s going in Evernote or in a notebook I carry around with me. If I think of something that needs to get done within the month, it’s going on a Trello board I create for each month. And so on. This technique — and my measuring / tracking system — is heavily influenced by Getting Things Done, which I highly recommend.
When things are going wrong or going right, this system gives you a why. It is the Chrome Dev Tools of productivity for me, providing insight into what happened over a given period of time and why.
Let’s explore the negative side of this. There is stuff that is absolutely inimical to optimizing for deep work, and that stuff is what companies are trying to get you to do to maximize profits. What I mean here:
- News
- Social media
- Video content that isn’t educational (TV series, big budget movies, etc.)
- Your phone
There are ways to stop this stuff in its tracks. For me, the best one has been Moment, an iOS app that measures how much time you spend on your phone each day. I target under an hour each day (this is harder than it seems) and try do a retrospective if I go over that time.
I want to stress that this kind of stuff seems innocuous on the surface. News and TV are often treated as educational when they’re really geared towards entertainment.
TV shows in my opinion seem to more and more be written to hook watchers, and this “Golden Age of TV” talk may be as much a credit to how good producers have become at creating addiction as it is the quality of the shows (or maybe the two are the same thing).
I spent probably 10 minutes over the last week being upset about the series finale of The Americans before remembering the show was entirely fictional. Six seasons of the Americans was over 60+ hours of TV for me — did I honestly get anything out of this show? If I could do it over again, I would have read 10+ books during this time, using Gates Notes, FiveBooks or any number of excellent references to find good picks.
Minimize back and forth by asking for what you need in as much detail as possible
Questions on requirements for a project? Spend the 30 minutes or more necessary to get them down on paper and send them to the necessary party. Figure out what you need and get it on paper, and then go out and get it. I like Google Docs where other people can respond in comments or edit for this type of thing. Providing screenshots and links is also important here if it helps clarify the ask.
Use placeholders to deal with relying on other people for parts of a project
In code, this looks like this when someone else is writing the API to save to-dos to a database:
// TODO - delete once we can import Bob's function
const saveToDo = () => Promise.resolve();In writing, this looks like this when someone else is providing information that will be used to inform travel plans:
All -
We should plan to arrive at the hotel around 7PM. From there, we’ll meet the client for drinks at [TBD BAR — AWAITING CLIENT RESPONSE] at [TBD TIME — AWAITING CLIENT RESPONSE].
In spreadsheet / forecasting, this is making inputs dynamic and clearly delineated (I will use blue font if inputs are hard coded).
Do what you can while you can
Those 5–10 minutes before a meeting or while you wait on an Uber are when you can start attacking low-mental-requirement tasks — writing e-mails, updating TODO lists, making new TODOs, jotting down ideas in Evernote or your app of choice, ordering Amazon Fresh for later in the week, etc. Credit to Jeremy Phelps for helping me learn this concept.
A lot of this tip is contextual. If you have access to your laptop and internet, you can code at that time; if you have a laptop but no internet, your task surface is smaller. I have found thinking about what I can do when on a long plane ride is one area where this tip really shines. A 2.5 hour flight for me is ideal for writing code I already have sketched out on paper and know how to write. In contrast, 7AM after coffee is a good time for me to start digging into a new API or reviewing part of a codebase I’ve never looked at before.
Create wikis / READMEs for procedural tasks that will be repeated
This could be a GitHub gist, a Google Doc or any small how-to text file that informs a repeated task that has multiple steps.
Concede low-stakes arguments
Arguments take time and mental energy. If there’s nothing to gain, don’t pursue them. This tip applies especially when the argument is over something trivial to change, like coding style (ex. naming, syntactic sugar, lint rules). I am still working on establishing better criteria for when it does make sense to push on issues, but for now I think I know enough to walk away from a meaningless argument.
Gather low-energy, easy tasks to boost momentum
Very much related to “Do what you can while you can”. These tasks can actually be useful and make you feel like you’re getting stuff done (because you are). Examples:
- Working out
- Laundry
- Booking travel
- Cleaning up TODO lists, adding new TODOs
- Linting code
- Upgrading libraries (difficulty may vary)
- Writing unit tests (difficulty may vary)
When using new APIs (coding or human-level), make a successful call before starting any type of planning around the API
In code, this looks like:
const NewAPI = require('new-api');// get this to succeed before moving on
const apiInstance = new NewAPI(process.env.myAPIToken);
apiInstance.someWriteMethod('some fake data');
The possible cost of not doing this is figuring out the API will cost money to unlock the functionality you need, or that there is a bug in the existing API and you’ll have to fork the code. When possible, do not rely on documentation — read a little bit of source code at least.
In real life, this looks like doing a progress call (.checkIn()) to determine if the project you’re working on is going the right way. What does the client want to see? Not doing this call is making assumptions about how their API works without validating it with a call (literally).
Stop scoreboard / tape / things-in-progress watching
You cannot impact something outside your control — this goes for stocks, daily fantasy sports, waiting on someone to e-mail you back, etc. Although you pick the stocks / players / people that work for you, watching without reason is pointless. Check in quarterly for stocks unless it’s a swing trade; at the end of final game of the slate if it’s DFS; find some daily time to check and respond to e-mail. Tape watching is inimical to productivity and does nothing but cause stress. Live with your decisions and accept the outcomes. If you can’t impact the outcome, your time is much spent doing something where you can.
I’ll keep thinking about work productivity and adding to this list as more useful ideas pop up.
Like this post? Check out my blog, subscribe to my reading recommendation newsletter or let’s get in touch about consulting, pair programming, or anything tech-related on your mind.
