My Personal Process

Over the years I’ve blogged about personal productivity–it’s one of the dimensions I enjoy optimizing to get more done at work, and people think I’m good at. This post is what I wish I had at my disposal when I starting my journey down productivity.

A real challenge with reading advice from literature can be how to put things into practice in the real world. I always appreciate it when experts describe or show examples, especially of tools and techniques. This my attempt at doing just that.

In addition to following tried and true advice, like inbox zero, saying no, unsubscribing from worthless email lists, the two-minute rule, trash whatever you can, and the like, here are the tools and techniques I use today:

Individual Tasks

First, I must point out that these are for tracking my own items–not items that should be visible to a broader group. I put those in formal systems like Asana, Clubhouse, etc. That disclaimer aside, here is how I track my personal tasks:

  • Urgent tasks I schedule on Google Calendar as a time-bound event. Stephen Covey would be proud.
  • Future-urgent or top-of-list important items I put in my Google Calendar Tasks because I can place them on specific dates I suspect I will complete them on. Yes, when I’m busy there’s some drag-and-drop from day to day or week to week.
  • I manage private text files for “_Me”, other people (e.g. “Jim”), or departments (e.g. “QA”) to track open action items, whether committed to or future, possible work. I use indentation or bullets to nest subtasks. I find the relative lack of structure much easier to manage than something like Asana or other task managers. Depending on my connectivity needs, these have been text files on my computer, Google Docs, or Evernote notes. I only ever use one tool during a season of life. I never try to use multiple text editing platforms for tasks.

Email

  • I BCC followupthen.com whenever sending an email I need a timely response to and yet don’t trust the recipients to reply by a specific date.
  • I immediately star sent emails that require a reply but that are not time-sensitive. If someone responds later and the thread is effectively closed, I un-star it before archiving. I sift through these starred messages periodically to unstar items that are no longer relevant, were in-fact resolved. If it is still unresolved, I re-email people nudging them to respond.
  • If I receive an email I don’t want to deal with at the moment, but may be interested in reading several weeks or months later, I will forward it to followupthen.com and archive it immediately.
  • I set up GMail filters to label and skip the inbox for any system-generated messages from apps like GitHub, Clubhouse, or Slack. I then view them at particular points in the day in batch. I additionally have GMail automatically archive and mark as read emails that do not necessitate an action but may be a helpful reference in the future, like receipts from vendors.
  • I schedule a 60-minutes recurring calendar event to get to inbox and Slack zero at a time that makes sense for my schedule (9-10 am). Others can’t schedule meetings during this time. This recurring event ensures I have space to get to inbox zero or as close as I can.

Slack/Group Chat

  • I keep up with it as much as I can, and I ensure others are following Slack etiquette so that we’re not suffocating our own company. Sometimes it’s more appropriate to send an email or hop on a voice or video call.
  • Because I keep up with Slack, I can disable most of its notification settings to focus on the work at hand.
  • I ensure my channel list only shows ones with unread messages for easier catch-up and use my keyboard to jump between channels.
  • I leave any channels I am not deriving value from or contributing value to. I trust someone will @ mention me if I need to rejoin. I left and rejoined some channels a few times in a single day this year. The mute feature is too aggressive; it doesn’t notify me if someone mentions me again in the channel.
  • When I need to get deep work done, I ignore or quit the app. (I can ignore it since I turned off notifications.)

I hope this is helpful for others! Please comment if you need clarification on any of these tactics or have your own to share.

Sony a6000 Thinks It’s 12/31/69!

I just solved a terrifying and frustrating issue with family photos taken on our Sony a6000. I found no solutions online, so I’m posting the issue as well as my solution to spare others the same headache.

As I was looking at photos on our Apple Mac Mini computer tonight, I noticed that all of them had a Created date of 12/31/69 7:00 PM. What?! Was this OS X’s fault or the a6000’s? I did some googling to no avail. I only saw mentions of leap year bugs in other hardware and software products.

On a whim, I turned on our a6000 to see if it still had copies of the photos. It didn’t, but it still had an image index of all the photos going back to when we first purchased the camera, properly dated. However, each thumbnail displayed with a “?” question mark and “Unable to display” when trying to view on the camera. I had previously moved all the photo files to our computer while the camera was connected with its USB cable, which is why they weren’t on the camera anymore. As I started deleting really old photo thumbnails off the camera using the camera controls, I started getting messages like “Recovering Data,” “Writing to the memory card was not completed correctly,” and the camera would occasionally reboot in utter confusion with no real way of escape. I had stumbled upon a real mess.

This mess got me thinking, “maybe the Sony a6000 software engineers didn’t do a good job engineering for the case where photo files were moved from the camera to a computer via USB Mode and OS X Finder.” I haven’t ever run into an issue like this one with other devices, but maybe I needed another way to copy the files to our computer to extract the right creation date.

As an experiment, I copied the files for the photos from our Mac Mini back over to our a6000 via the file system–essentially putting them back where they came from. The photo index then had a few real thumbnails–the photos that didn’t have thumbnails were ones I had deleted on the computer months ago. From there I started OS X’s Preview app. I clicked File > Import > NO NAME. “NO NAME” is the volume name for the Sony a6000 memory card when connected in USB Mode. From there I imported the files to the Mac, and, voilà, the creation date was now correct.

The best guess I have is that the Sony a6000 is using 12/31/1969 (or some null value) as the file system created dates on its memory card. I’m also guessing that the OS X Preview app is extracting the created dates not from the memory card file system but from the photos’ meta data. Then I suspect it is using those values to set the created dates on the Mac’s hard drive when importing the photo files.

After successfully importing all the files from the a6000, I used the camera’s format feature to wipe the memory card clean. From now on, I will be using Preview, Photos, or some other OS X photo app to import our photo files, not dragging and dropping them from the NO NAME volume to our computer directly.

I hope this helps someone else someday. Drop me a note if it does.

 

Note: if you are trying to recover from the same issue, but you have already wiped your memory card or deleted the thumbnails for the files you are trying to recover, I do not know how to resolve your issue. I’m sorry!

Bucking the Microservices Fad

In the middle of 2013, I was hired to lead the engineering team at LearnZillion–a digital curriculum for K-12 Math and English subjects composed of videos, slides, documents, and images. At the time, there were several applications in support of the business:

  • 2 Ruby on Rails web applications: the content authoring platform for a select group of users and the content consumption platform most teachers and students used
  • 2 native mobile apps: 1 iOS and 1 Android for students only
  • 1 API inside the content consumption Rails app, which served data to the 2 mobile apps and the web application

After a few months, momentum led us to build a publishing API so that the 2 Rails apps could talk with each other. (Before this second API, we were painstakingly moving data between the two apps via CSV and file exports and imports.)

Having recently left a company where we were migrating from one monolithic application into dozens of microservices, the momentum felt right. It was the in thing to do. Microservices were hot. However, as time moved forward, it became increasingly clear at LearnZillion that a microservices architecture came with a non-negligible overhead cost: the cost of keeping not 1 but 2 Rails apps up-to-date with dependency upgrades, authoring 2 APIs internal APIs, 3 API clients, and often changing all 5 when adding or removing a feature, all to pass data around. On top of the software management overhead, there was the overhead of hosting each and bending over backwards at times to make sure that APIs never called themselves. The benefits of having separated apps and APIs were dragged down by the cost.

We didn’t want the over-complexity and overhead, so over an 18-month period, we did a 180. We brought content authoring into the content consumption app, killing-off 1 Rails app, an API, and an API client. We also transitioned our iOS and Android native apps in favor of a cross-platform Ionic app that WebView-ed our main Rails app on both iOS and Android, killing-off an API and 2 API clients.

We now have 1, hosted app, built the Rails way, that has a median response time of 75ms, 2 hybrid mobile apps that look and function identically, and whenever a feature is deployed to our main web application, it is immediately available inside the mobile apps. No extra moving parts, no coordinated deploys. Most importantly, this setup allows us to scale the impact of each member of the Engineering & Design team by keeping each one focused on the features, not on a microservices architecture.

Bucking the Microservices Fad

Our course, there are plenty of valid reasons to have microservices, purely native mobile apps, etc., but this is not always the case.

I’m merely warning against jumping on the microservices bandwagon because it’s the in-thing. And this is a concrete example of where microservices were hurting a business not helping it. Thankfully, it wasn’t too late to reverse course. And I don’t think our team could be happier with the results.

As one of my colleagues says, “you have to use your brain.”