The importance of maintaining a personal dev log
Many years ago, I began keeping a personal log of my daily activities. As a developer, each day presents multiple challenges and problems that need solving.
The importance of maintaining a personal dev log
At first, my goal was straightforward: I wanted to keep a record of my work to communicate more effectively with my team during standups. I often found myself forgetting crucial details or tasks that could impact the team’s progress. However, over time, this practice evolved into something far more valuable.
The log became not just a daily record but also a tool for reflection, enabling me to identify patterns, recognize recurring issues, and enhance my memory and problem-solving abilities. It has now become an essential part of my routine, providing both personal insights and tangible benefits to my team.
I began tracking the projects I worked on and the time spent on each, which proved invaluable for cost management and simplified time tracking at the end of the week. This practice also became particularly useful during performance reviews and growth discussions, as I had clear, detailed records of my contributions, making those conversations easier to prepare for.
Additionally, I made it a habit to document error messages, exceptions, and the steps I took to resolve them. Instead of relying on screenshots, I took a few minutes to write everything down, making the information easily searchable later. This approach has been incredibly helpful—whether I encounter the same issue again or a colleague faces a similar problem, having the solution readily available has saved valuable time and effort.
Here’s an example of what a daily log could look like:
- 0.5h meeting: daily standup
- 3.0h ops :
- looking at why storageclasses timeout after upgrading from fluxcd 0.33.0 to 0.34.0
- comparing clusters, looking at yaml for storageclasses couldn't find anything obviously wrong
- looking at events and logs in kubernetes - couldn't find much more than we already knew
- found deprecated field in kustomize toolkit, fixed it, but didn't make any difference
- upgraded to latest terraform provider for fluxcd 0.20.0 and latest fluxcd 0.36.0 - this fixed the issue (even though I couldn't see any specifics in the release notes...)
- 4.0h product x:
- wrote a new test for the updated segment code but it fails...
- figured out what's up with the segment filtering not working properly
- seems like the j-values are mirrored (as suspected) so flipping them seems to do the trick (also off by one for some reason too...)
Tools for journaling
I started out using the typical note apps at the time, Evernote and OneNote.
However, it didn’t take long for me to realize that I wanted my notes in git and that Markdown was the ideal format. By using simple, plain Markdown files and git, you really can’t go wrong. After experimenting with various options (see honorable mentions below), I decided to stick with my regular development tools. They’re familiar, cross-platform, and offer excellent Markdown and git integration:
- Atom: https://atom-editor.cc/
- VSCode: https://code.visualstudio.com/
- VSCodium: https://vscodium.com/
- Neovim: https://neovim.io/
I prefer my note-taking app to be separate from my development environment because it provides a dedicated icon on the taskbar, making it easy to keep open and quickly switch to. This is why Atom, VSCodium, and Neovim have been excellent options for me.
For my iPhone and iPad, I’ve been using Working Copy and 1Writer. Syncing your git repo to cloud storage (e.g., Dropbox, OneDrive, or iCloud) and using any Markdown-supported app works just as well.
Other honorable mentions that didn’t quite fit my workflow right now:
- Obsidian: https://obsidian.md/
- Logseq: https://logseq.com/
- Joplin: https://joplinapp.org/
- Zettlr: https://www.zettlr.com/
- MarkText: https://www.marktext.cc/
- Dendron (plugin for VSCode/VSCodium): https://www.dendron.so/
I hope this was insightful 💚 Don't hesitate to reach out if you have any questions!
