What did you do at work three days ago? What about eight days ago? Twelve days?
Depending on your job, keeping stock of the day-to-day work by memory alone is simply not practical. I sometimes struggle to remember salient details of the morning in the afternoon.
Am I getting old? Is my mind starting to go? While I’m sure sharpness fades over time, this is a product of the ever-increasing complexities of our work. It is challenging to remember accomplishments from the beginning of the year during year-end-review, and this is when a salary raise, bonus, and possibly the job itself is put on the line.
Three years ago, I began an experiment: I started to write in a journal.
At first, it was pen and paper, which worked well enough, but I always had a hard time finding things later. I created jrnl which is an open-source command-line interface that allows very quick journal entries straight from the terminal and then makes it available on a Github wiki. What you use is less important than simply doing the practice of keeping a journal.
My role at Zumba has become more and more managerial. I still code quite a bit, but no longer is it my main function. You can read about this transition, but suffice it to say: it has a huge impact on your time and focus. Typically, an individual contributors’ time is divided into half-days, usually broken up by lunch. A managers’ day on the other hand is broken into thirty-minute time blocks. “Broken” is the keyword here because it will break your ability to concentrate on a specific task constantly.
As I’ve continued this experiment of journaling, I’ve been able to regain my ability to hold context. Whenever I start on a task that looks like it could be complex, I immediately start writing down my findings of the task as I discover it. When I inevitably get interrupted and return to the task, I don’t need to spend nearly as much time re-gaining all the context previously hard-earned. I catch up on my journal entry and continue.
Even things like pull requests are improved. A significant amount of time on pull request reviews is saved by having my rationale as to why I did something the way I did readily available and textual. It as if I’m creating a changelog.
Journaling isn’t only useful for development, it can also be invaluable in meetings. I have a bad habit of interrupting in meetings, and one of the things I’ve done to lessen this behavior is to jot down my questions or concerns in my journal and only bring them up when it is more appropriate. I also now have context for the decisions made in the meeting. Yes, we decided ‘x’ in the meeting, but why? Now I know.
As time goes on, my journal also becomes a source of code snippets, common SQL, and just notes on how obscure systems work. Eventually, as time permits, some of these entries get reformatted (and de-personalized) to be added to the company documentation system.
What I’ve described throughout this article is a purpose-driven, technical journal. This is not the same as a personal daily diary, whose focus is on how you feel about the events. Here’s what I’ve learned from the last three years of technical journaling:
- You don’t need to be religious about it. The act of writing every day isn’t the goal. If it becomes a chore to use, then you’ll stop using it.
- The journal doesn’t need to be complicated. Use it with other tools like your company’s ticket system, a to-do list app, and even a simple calendar.
- Keep it private. A journal entry is meant to be raw and un-edited. Let the thoughts just pour into the entry. You always have the option of cleaning it up later for public consumption.
All the benefits I described in this article are just the tip of the iceberg. Give journaling a try and see if it improves how you work.
Credits
Featured image by Aaron Burden.
