Originally published on dakotalewallen.me
My logging in numbers
Started on October 4 and created 147 entries to date (5/2/22).
Some rough napkin math:
30 weeks since that week
150 weekdays (30wks * 5, ignoring weekends)
147/150 is not too bad 😁
To be honest, I will say there are a non-zero number of days that have multiple entries due to a number of reasons, so take the high "completion rate" with a grain of salt.
8 Code Kata's completed in 4 weeks around December
My longest gap between logs is ~4 days in the 3rd week of March (3/18 (a Friday)- 3/24 (a Thursday)). But again being honest, March from beginning to end is the most spotty.
TL:DR;
I appreciate the practice. As someone who tends to find themselves tied up in quite a few things all at once, it serves almost like a "save game" function for my brain. Allowing me to work in starts and stops while maintaining cohesive lines of thought. It also serves as a place to keep to-do lists for all the things going on, so I can track what I have completed vs what I aimed to have completed.
A core to doing something often is making it low friction. Having it in my personal CMS so that I can access it from any device at any time is a huge contributing factor to me doing it so often. If it required an app that needed installing, syncing, maintenance of updates and/or a subscription I highly doubt I would have stuck with it. Definitely more setup overhead and more cost. But I own the source of truth for all the data I produce and I'm only at the mercy of myself in terms of structuring and maintaining it.
Origins
Admittedly, I scroll hacker news once or twice a day. Say what you want about the front page "practices" and the people that started it, there is still a lot of good tech content that ends up on there that I enjoy reading, that otherwise would never have made it to my information horizon. So when it comes to niche information sometimes I just co-exist with people I don't necessarily agree with a lot of things about. I digress. Amongst it, I've seen a handful of mentions of the practice of maintaining a logbook from various fields. Not coming from a formal background, it was kind of an "ah-ha" moment having it described to me. I've always taken notes, but never with any formal practices. They were primarily in notebooks and the most formal part of my process was writing the date in the top left corner of the page. So safe to say that other than meetings I never really maintained any useful level of information within them. In short, the purpose of a logbook is to keep a record of experiments performed. This article(?) from Indiana University provides a pretty succinct way of starting a logbook. Similar content definitely guided my hand in terms of starting my own practice.
From reading a few things were clear:
- the data generated needed to be time-series
- the data needed to have titles
- needed to be able to embed different types of data (images, files, etc) within any given entry
- notes for meetings and working should probably be maintained with some level of separation
The first three points were derived from widely reading and shared across disciplines. The last point came from engineering-specific and software-engineering-specific articles. Mostly here where the author actively does this and considering the weight I personally place on meetings it felt non-negotiable.
Getting Going
Most scientific implementations make a hard requirement of doing it in a physical notebook. While I do have a hoard of filled notebooks in my closet, whenever I take notes for work with a notebook, I find it harder to stick to the habit. It's another physical thing to keep track of it and the only purpose it serves is for those notes. So the mental load it creates versus relieves for me isn't as favorable as I would like. I also asked my fiance for some input on this considering they work in human services where they keep extensive written records and they actually agreed with my points and then added additional drawbacks that she experiences with her workflow that would further hinder what I was setting out to do.
An implementation detail from that article, and most others like it, that I immediately dismissed was the idea of doing it as plain text files maintained on my OS. I'm blessed enough to have multiple physical and virtual machines that I work from, so having my logs centralized on one is a non-starter. There are obviously things I could do to solve this that are more technically involved. For instance, setting up my main as an FTP server and automating copying files back and forth from my other machines. This is okay, but I dual-boot on my main machine and occasionally have to take meetings from my non-work OS (windows). So FTP'ing from one OS to the other in that instance is not simple (and probably not possible without some serious hackery). Solving that issue could be done with applications like Dropbox or Google Drive, but to do them for a long period of time I'm likely going to butt up against the limitations of those services and I lose control over my data. Canceled subscriptions, outages, getting accounts closed, etc all result in me being unable to access my data. So in short, local files aren't going to cut it. Luckily enough for me, these are the kinds of problems I like tackling.
Being an aspiring pragmatist, I started looking around for systems I already interacted with regularly and happened to fall into my CMS. I've run strapi on an EC2 instance since September of 2020 and up until starting this project exclusively used it to maintain the content on this site. Primarily my blogs, reading list and "uses" list. Tinkering with the content builder I pretty quickly sketched up a data model that felt fitting.
- Organization: An enumeration of who I was working for. (myself and my current company)
- Project: Title of the project I was working on
- Meetings: Space for detailing my meetings for the day
- Tasks: Space for detailing the work I was doing I then leveraged the Created At field to track the time-series bit and was off to the races. Doing it this way solved quite a few issues and provided some unique benefits.
Pros:
- I own my data and the only people that can change that are myself, AWS (my cloud host) and bad actors
- My data is accessible as long as I have an internet connection and my cloud infrastructure is running.
- My CMS provides a rich-text editor enabling me to write in Markdown and embed other data types (video, pictures, audio) as I see fit
- I own the data model enabling me to add, link or remove data as I see fit.
- Relative to other implementations, I don't have to maintain any automation beyond backups. I just write to my CMS as I would be anyways.
- No new physical things to remember. I use a PC every day anyways, so the barrier to access is a couple of clicks and keystrokes away.
Cons:
- I don't own the computer housing my data. Bluntly the computers doing that belong to Amazon. Granted they have "no access" to the machines I'm using unless I expressly grant it, they are still a service provider sitting between me and my data.
- I have to pay for the infrastructure I use. You could argue I would be doing this no matter the implementation in some form, but here there is a hard bill that comes at the end of the month that has to be paid one way or the other or the service provider has the right to remove my access to my data.
- Infrastructure maintenance.
- Probably the most impactful of all the points listed so far.
- For this, some of it is rolled up in the fact that it's being used for multiple projects so could technically count it as amortized across them, but I'm the only person maintaining all of them so it really doesn't matter. If there's misconfiguration or updates that need to be done it falls to me to do it. Granted I employ KISS as far and wide as I can and this infrastructure is no exception. So this additional workload for me comes down to maybe an hour or two every couple of months. But milage on this point will vary.
- To speculate further, if I had to say one point for why most people don't take this approach this would be it. Unless you're in IT and/or don't mind doing it as a "hobby" this approach flat out won't work. It's akin to being a car guy and not having access to a garage. You can for sure do it, but the cost will be exponentially higher and you'll have noticeably less freedom in terms of implementation details.
In Practice
With all of that considered, this approach has worked wonders for me. My work is noticeably more cohesive. Most importantly I would say my communication is leaps and bounds more consistent. In terms of communicating work, I know what I accomplished in recent history and I know what I still have left to do to reach targets. I can relay information about my meetings to not only people not in the meeting, but to my future self really well. Of all things when I started this, I expected to make my brain more organized but the arguably largest benefit has been my communication with others. I stare into the abyss a lot less when trying to recall things I've worked on or conversations I've had. At the end of the day, it typically leads to a better result for everyone, not just myself.
The Data Model
Since starting, the four core points of "Organization, Project, Meetings and Tasks" have remained unchanged. I will say there was a small period where I tried to add in the habit of doing code "Kata's" regularly. A Kata being like a small coding exercise to practice specific problems in coding. Really it means I attempted to do LeetCode problems regularly for a few weeks, but in the end, I found them tedious and not really adding much value. Arguably a few weeks isn't really much in terms of data size and I stopped purely based on a subjective opinion. ANYWAYS. The data within the points also stayed fairly consistent. From day to day I typically create a copy of the previous day's notes to kick things off. Typically I don't have to change the project and I never change the Organization. If I'm working on something for a different "org" I copy whatever the last instance of work for that org was. From there I update the "meetings" section. If I have none scheduled I'll write in none. Then if meetings pop up throughout the day I'll remove the "none" and add in a normal meeting entry. A typical meeting entry simply looks like
title @ time
## pre
- notes about things I want ready going into the meeting
## during
- notes taken during the meeting
## post
- notes taken while following up on the meeting
Impromptu meetings don't have "pre" entries since they're impromptu. "During" usually serves as a scratchpad for key points and things I need to follow up on. "Post" serves as the scratchpad for things I do after the meeting that would be nice to know for the next time I need to update the status about tasks or in follow-up meetings.
Tasks are organized differently. I usually divide this into sections organized by the project. So an entry in this section has a much less rigid structure.
# Project
- note
- note
- note
- links to documentation
- links to useful videos
Task:
- item ✅ (done)
- item ❌ (decided not to do or blocked)
- item 🔜 (in progress)
# Project 2
...
The Habit
I wrote my first logbook on October 24th, 2021. As the numbers show at the top I've roughly managed to make a logbook entry every day since starting. There's definitely some dirty data contributing to that high number. But I wouldn't say it's below 80%. Having it live in my browser has made the barrier to getting into it is extremely low. I have to have my browser open to do my job so the only reason to not make a logbook is either forgetfulness or laziness. The other part I would say has reinforced the habit is the frequency with which I refer to the logbooks. By putting information that I need to relay to other people somewhere, it's become habitual to look it at when I know I wrote something about it. Essentially creating a positive feedback loop between me writing down accurate information in my logbook, enabling me to relay good information from people without having to commit it to long-term memory. So it basically replaces the mental load of having to memorize everything that I think might be important to someone else (which could be a literal person or my future self) with the action of writing it down in my logbook. Then if I ever feel flaky on the detail of something or feel like I'm forgetting an entire point. I jump into my logs. It's still a human process and I miss things, but more often than not there's something useful in there.
In Conclusion
If you don't take notes. Start. If you have taken notes and had some of the reservations I've had, try my process and hack away at it until it works for you. In my experience, the most difficult part of accomplishing anything is communication, and taking personal notes will do leaps and bounds to improving the quality of your communication.
Sponsor me on Github
Top comments (0)