On Development Logging: The DevLog
On Development Logging: The DevLog
I’ve always liked having a record of what I’ve done on a project and a place for notes. That’s often been a notebook, updates to GitHub/GitLab/JIRA issues/tickets, or maybe blog entries. Those all have problems. In reading Masters of Doom I came across a passage which described the intense environm...
I like keeping track of things I do but I like doing it with as little overhead as possible. Hence I have years of food data tracking but that only really started being real when the ability to enter that data became so simple as to be effortless. The same is true for development on projects. I want to see how things evolved. When I look at something years later and think to myself, “What the hell was I thinking?” it’s nice to be able to look back at notes from that time. Likewise as I’m working on something and I have a thought pop in my head like, “We need to fix this later,” or, “Gee wouldn’t it be nice if this program did this thing,” it’d be nice to have a place to collect all of that and have it be something which doesn’t interrupt my train of thought. I’ve tried collecting that in issue trackers and the like but honestly I’ve never been able to keep up with that. Issue trackers that become the reservoir for things to do start having inefficient signal to noise ratios. Even when I thinned out old issues it often proved hard to find what I was looking for as well. Lastly it also disrupts the flow.
Carmack’s “.plan” file concept was an absolutely perfect solution to this problem. It’s a simple text file you have open and you put in short statements with a simple key that you can decipher instantly. It’s searchable so you can easily find stuff. It’s shareable so it doubles as providing status as well as a means of keeping track of your own thoughts. Lastly, everything about the project is in one place. I don’t have notes in one place, issues in another, feature ideas elsewhere, etc. While I liked Carmack’s idea I have tweaked it a bit for my own purposes.
The first tweak I have is that each project gets its own DevLog. I started off trying to have it in one big file but since I work on multiple projects it just didn’t scale well. Since these are text files there is no disadvantage to having them split out since search tools can just as easily traverse multiple text files in a directory as one big text file. In the rare cases where something I’m working on is related to both projects I make a footnote in the one about seeing something in the other or some other mechanism. It’s such an uncommon occurrence even on projects that have entanglements that I don’t worry about it.
===== References in text