Checklist

Checklists are powerful. They let you off-load some mental effort into easily-accessible text. They prevent bad things from happening and they help you to remember about the good stuff.

You might think your work is too special to be described by a checklist, but consider two facts:

  • A checklist doesn’t need to reflect the task completely: it just needs to mention elements that are commonly missed, or have particularly catastrophic consequences when missed.
  • There probably are parts of your work that are more repeatable than you think, yet cannot be easily automated.

Here’s an example of checklist I use: pull request checklist.

- [ ] Did I look for parts that could be in an independent, smaller PR?
  - WHY?  To make it easy to review, and also easy to revert without unexpected consequences.
- [ ] Did I test the code?
  - WHY?  To not waste time of the reviewer.
- [ ] Did I make sure that there is no commented-out code or other debugging artifacts?
  - WHY?  Because it should never make it to production, though it sometimes happens.
- [ ] Did I comment where needed?
  - WHY?  So the system is understandable even when code alone is not expressive enough.
- [ ] (For visual changes) Did I attach a screenshot or GIF?
  - WHY?  To make it immediately obvious to the reviewer what changed.

The “WHY?” section helps me remember the intention behind each item, and makes it more accessible to others if I would share it. It also helps me to judge whether an item is still relevant; perhaps the core problem has been addressed in other way in the meantime – e.g., an automatic check for commented-out code was added as a git hook. Some items are optional or context-dependent, as the last item on this list.

Some other contexts where checklist can be useful:

  • Starting a new project
  • Job interview preparation (from either side)
  • Bug reporting
  • Git commit message & content
  • Writing an essay

If you perform given task everyday or almost everyday, it might be enough to just review the checklist from time to time (once a month, for example). If you do that task less often, use the checklist every time.

Comfort vs focus

I like to have an ergonomic keyboard at my desk, multiple big displays and all that. But since I started using a tablet with a little keyboard, I noticed that most of my side project work happens there, not on my fancy home workspace; even when I’m at home.

It doesn’t make sense at first – my “big” workspace is better in every dimension: there is this fancy ergonomic, mechanical keyboard; on iPad I have shitty rubber keys with layout I’m less used to. Huge screen can fit several terminal windows and a browser, compared to 10 inch tablet screen that fits a small browser window and one or two open files in the terminal, at best.

But there is another force at work here. Minimal workspace brings constraints, and that helps me to focus. While the big workspace is objectively more comfortable physically, the smaller is sometimes more comfortable psychologically when I’m not at my calmest state.

Sometimes, more comfort accidentally leads to less focus.

Daily template

Do you feel like you could be more organized during your day? Here is something I use: a daily template. Every day at work, I start by creating a text file named like “2019-08-27”. Then I put there a simple template:

  • Todo
  • Standup
    • Yesterday
    • Today
  • For tomorrow
  • Retrospective, learnings

Then I use it as my semi-structured way of keeping track of the current work.

I start by looking at the last day’s “For tomorrow” section and copying parts of it that still seem important into the today’s “Todo”.

In most of my projects there’s a ritual of daily status meetings; having the “Standup” note and looking at it right before the standup makes it easy for me to not waste everybody’s time by trying to remember everything on the spot.

If there’s something that is in progress at the end of the day, I put it in “For tomorrow”.

At the end of the day, I like to take a couple of minutes and remember if there was something new I learned, or something that I could have done better.

Here’s an example of how this file might look like at the end of the day:

  • Todo
    • [X] Update deps in project X
    • [X] Review PR from Alex
    • [ ] Search component (#145)
  • Standup
    • Yesterday
      • Finished signup form (#144)
      • Started search component (#145)
    • Today
      • Continue with the search component. No blockers. If done, start the toolbar component.
  • For tomorrow
    • Finish search component
      • Test with browser zoom!
      • Rebase on latest master
  • Learnings
    • Use JS Performance API before spending time on tweaking performance next time

I started using this approach about a year ago, and now it’s hard for me to imagine how much mental energy I used to spend on keeping track of details like that. When I start a day, or I’m done with something, or I’m after a long meeting that erased my short-term memory about the task I was working on before, I just take a peek at my daily file and get the context back.

Unless you already have a system you use and like, I encourage you to try it out. Customize and automate it as you see fit, just make sure to keep it simple.

Two reasons to hire engineers from underrepresented groups

The first reason is straightforward: it is just basic human decency to make hiring more fair.

The second reason is a bit less obvious: it is good for your business in a very direct way.

There is huge shortage of talent in tech, but the common hiring process is discouraging big groups of people that don’t match the stereotype of a programmer, like women or people of color. This leads to those groups being under-employed.

On average, you need to pay less for the same talent, or you get higher-quality talent for the same price.

How much time will pass before this becomes common sense?

Read what Dan Luu writes about data on discrimination.

Limit Tools In Progress

Tools help you get things done, but too many tools mean constant mental overload.

Every piece of technology you add has a very real cost of learning it and composing it into your toolset. One too many, and your workflow becomes a mess.

I’m not saying that you should stop learning new things; just remember that there are two sides to it. But I am saying don’t add a thing until you know exactly why you need it, and that it’s worth the cost. It’s also fine to play with something from sheer curiosity – just be honest about it.

An example is using too many Vim plugins. At first, you just see a cool plugin that does something useful, and you immediately install it, learn the basics and start using it – and life is good. Then it repeats twenty more times, and every time it happens the life gets a bit better in obvious way, but it also becomes a bit worse in an obscure way: your configuration becomes hard to maintain; functionalities don’t co-exist nicely with each other an with the vim’s built-in stuff; you get confused as to which plugin to use; there are too many shortcuts to remember…

At some point, you have to learn to pick just the few ones that are helping you the most, and drop the rest.

Remember it the next time you pick up a new tool.

Change your environment (sometimes)

Often, I find new solutions to hard problems when I change something about my environment. I switch from a big monitor to a tablet screen, or the other way around , and suddenly, it’s obvious how to get something done.

Sometimes, I go to work from a cafe or a library, and it also brings a fresh perspective.

Work in silence (if you can afford such luxury) or with music. See what works for you; try something new from time to time.

There is also value in a solid routine, but a healthy dose of variation can help you in surprising ways.