https://henrikwarne.com/2024/11/09/my-simple-knowledge-management-and-time-tracking-system/ Henrik Warne's blog Thoughts on programming... Skip to content * Home * About [cropped-desk1] - Programming With ChatGPT My Simple Knowledge Management and Time Tracking System Posted on November 9, 2024 | 6 Comments I am using a very simple system for remembering commands and procedures, and for tracking what I work on. I have two plain text files called notes.txt and worktime.txt. In the notes file, I write down things that are important to remember. For example: various shell commands, steps when creating a new release, how to install and configure tools, company procedures for time reporting etc. In the worktime file, I write down the hours I worked that day, and what I worked on. I also have a python script that calculates the number of hours worked for the day and the week. [stones] In the past few years, I have started at four different companies. At each company, there are many things to remember. Which repositories do I clone? How do I build, test and deploy the system? How do I report time? The first time I do these things, I typically write down some notes about it. The next time, I can do it without asking anybody. If I do the task often enough, I will usually remember how to do it without having to refer to my notes. But the first few times, it is good to have the steps written down. Notes I usually add new stuff at the top of the file. The only exception is if there is already a few related items further down in the file. Then I will make an addition there. However, it doesn't matter if there are duplicate entries. When I look for something, I usually just search from the top of the file. The most recent entry is usually the one I am looking for. Occasionally, I have grep:ed through the whole file, so I can see all occurrences of some term at once, for example all git commands I have written down. Commands Some examples of commands I have saved in the file: # To see versions (images) of what's running: kubectl -n trade-sched get deployments -o custom-columns="NAME:.metadata.name, IMAGE:.spec.template.spec.containers[0].image" gcloud artifacts docker images list --include-tags docker.pkg.dev/edab-platform-cicd/kbt/tee --format=json | jq | grep -C2 'v5.11.20' # Find images with a given tag grep -i 'error\|panic\|fail\|fatal\|SIGSEGV\|back-pressured' * git rebase -i HEAD~3 # Interactively rebase the last 3 commits Some of these commands are not hard to recreate. But it is nice not having to think about what the path is, or what the arguments are, and instead just copy the command. Of course, if I used it recently, I will just find it in my shell history, so no need to look it up in the file then. Recently, I have been using curl to test various APIs. Then I will save the commands, including headers, body, URL and query parameters. It is much quicker to look up a working example than to recreate it. With LLMs, it is quite easy to just ask for custom shell commands when you need them. I still think it is worthwhile to write important ones down. My goal is to learn them by heart, so I don't have to look them up in my notes. Writing them down helps with that. Case in point: I know git rebase -i by heart now, so don't need it in the file anymore. Setting Things Up Setting up a new MacBook takes some time. Because it is something I don't do very often, I have written down what to install, and where to take it from. This is an (incomplete) example: Install XCode from Appstore (needed for homebrew) Install homebrew (from homepage, with curl) Install MacVim: brew install macvim Install GoLand Other things include shortcuts in the IDE, other apps to install, how to set access tokens, settings in applications like Chrome, Slack etc. Procedures For example, how to make a release, how to deploy to the test and production environments, how do start and stop systems, and where to find the logs. Typically, these kinds of activities are documented somewhere else too, such as on a Wiki-page. However, I can write down a version that is tailored to my needs (more or less information). If the official documentation is just what I need, I will just save the link to it. Even this is worthwhile to have, since sometimes it is not easy to find. Ideally, all official documentation should be comprehensive and easy to find, but that is rarely the case. Company Procedures This includes how to report time, vacation days and sick days, how to create an internal IT support ticket, how to book a meeting room, and where contact lists are located. I include both the URL, and the steps I need to take in the system (unless it is obvious). Time tracking Time This is what it looks like: 240322 7:30-11:25 13:15-17:50 SNE-1635 Unzipping files from google cloud bucket ... 240321 8:10-12:25 13:30-18:00 Made tag v5.11.13 for tee, and deployed ... 240320 8:25-11:55 12:25-17:45 Refactored Kraken futures websocket code ... The file is in reverse chronological order, so I always add the new day at the top of the file. I use an empty line to separate the weeks. I have a python script that calculates the hours and minutes worked each day, and the total and average for the week. The script makes it easy to see if I work my 40 hours per week, or if it is less or more. What I Worked On I shortened the descriptions in the example lines above. Typically, I write a few sentences on what I worked on that day. If there is a Jira ticket number, I try to include that. Sometimes I just take the commit messages for the day. If I don't write down what I worked on at the end of the day, I will not remember what it was. Fortunately, it only takes a few minutes to write down when it is fresh in my memory. Having it written down can sometimes be useful. For example, to answer "How much time did you spend on task X?", or "Why did that take so long?". When it is time for the yearly performance review, I usually look through the notes to see what main projects I worked on. Conclusion I have been using this system for over fifteen years now, and it works very well for me. It is only two plain text files, nothing more. There is no configuration. There is no vendor lock-in. The data format will not be obsolete. I don't have to spend time organizing or labeling the information I put in. I know many people, especially programmers, like to use more elaborate systems. No doubt such systems can do more than mine can. But I think it is useful to consider if maybe a simpler system will give you almost the same benefits, at a lower cost. Share this: * Twitter * Facebook * LinkedIn * Like Loading... Related This entry was posted in Work and tagged knowledge management, time tracking, work. Bookmark the permalink. - Programming With ChatGPT 6 responses to "My Simple Knowledge Management and Time Tracking System" 1. [e89ae] wt | November 9, 2024 at 6:36 pm | Reply Thanks for your new blog! I do the same thing, except I don't track time, so i have only a single file. On top are the things I should work on, and below that are my notes. Postman is basically a business model for curl commands in the cloud. It's shared between people. You run the commands locally, so it works in corporate IT. I read you've started at four companies in the past years! I'd be interested in reading more about that. + [aaa9c] Henrik Warne | November 9, 2024 at 6:43 pm | Reply Yes, I'm aware of Postman, but haven't used it much. I'm more of a command-line person, so happy to use curl. Yes, maybe I should write about starting at different companies. o [e89ae] wt | November 9, 2024 at 10:59 pm | Reply Thanks for your reply! The power of Postman is that after you join your team's Postman, every API they know of has a working example right there. Someone has figured out how to actually call the API, with keys and URLs and headers, separated out by production or test or staging. For command line people, Postman provides a tab where you can copy and paste the curl command. 2. [19d64] Alejandro Garcia | November 9, 2024 at 6:39 pm | Reply you are not alone I also use a plain text file as my productivity hack: https://jagcoop.github.io/posts/Single_text_file/ + [aaa9c] Henrik Warne | November 9, 2024 at 6:45 pm | Reply Nice! 3. [be76a] Stephen C. Steel | November 11, 2024 at 6:59 pm | Reply I have also used a similar system for years: one file for notes, one for what I'm working on. Since I mostly work on Windows systems I just use notepad for these (it has minimal overhead). It turns out notepad has a couple of features that really help: 1. Pressing F5 inserts a timestamp (using the configured Windows short time and date formats). 2. Opening a file that begins with the line ".LOG" jumps to the end of the file and inserts a timestamp. Leave a comment Cancel reply [ ] [ ] [ ] [ ] [ ] [ ] [ ] D[ ] * MOST POPULAR + Lessons Learned in Software Development + Top 5 Surprises When Starting Out as a Software Developer + Working as a Software Developer + Great Programmers Write Debuggable Code + What Makes a Good Programmer * RECENT POSTS + My Simple Knowledge Management and Time Tracking System + Programming With ChatGPT + John von Neumann - The Man from the Future + Finding a New Software Developer Job + Tidy First? + What I Have Changed My Mind About in Software Development + Well-maintained Software + Algorithmic Trading: A Practitioner's Guide + There Is No Software Maintenance + Switching to Go - First Impressions + Effective Software Testing - A Developer's Guide + On Code Reviews + Book Review: A Philosophy of Software Design + On Comments in Code + 4 Things I Like About Microservices + Recruiting Software Developers - Coding Tests + More Good Programming Quotes, Part 5 + 6 Small Unit Testing Tips + Mathematical Modelling of Football + Deployed To Production Is Not Enough + Good Logging + Working From Home - Cons and Pros + Artificial Intelligence - A Guide for Thinking Humans + 20.5 Years of XP and Agile + Secure by Design + More Good Programming Quotes, Part 4 + Grokking Deep Learning + EuroSTAR Testing Conference Prague 2019 + Classic Computer Science Problems in Python + When TDD Is Not a Good Fit + Recruiting Software Developers - Checking Out a Company + Book Review: Designing Data-Intensive Applications + Nordic Testing Days Tallinn 2019 + Book review: Accelerate + More Good Programming Quotes, Part 3 + Programming: Math or Writing? + Developer On Call + My Favorite Command-Line Shortcuts + 6 Git Aha Moments + Is Manual Testing Needed? + Exercises in Programming Style + Programming for Grade 8 + 6 Years of Thoughts on Programming + Benefits of Continuous Delivery + More Good Programming Quotes, Part 2 + Developer Testing + Programming Conference - QCon New York 2017 + Developers - Talk To People + Code Rot + Programmer Career Planning + Software Development and the Gig Economy + Book Review: The Effective Engineer + Things Programmers Say + Developer Book Club + Book Review: Release It! + 18 Lessons From 13 Years of Tricky Bugs + Learning From Your Bugs + More Good Programming Quotes + The Wisdom of Programming Quotes + Ph.D. or Professional Programmer? + Social Engineering from Kevin Mitnick + Recruiting Software Developers - Initial Contact + Coursera Course Review: Software Security + Lessons Learned in Software Development + Book Review: Clean Code + Coursera Course Review: Computational Investing Part 1 + Programmer Knowledge + 5 Reasons Why Software Developer is a Great Career Choice + A Response to "Why Most Unit Testing is Waste" + What Makes a Good Programmer? + Switching from Java to Python - First Impressions + Antifragility and Software Development + 5 Unit Testing Mistakes + Unit Testing Private Methods + A Bug, a Trace, a Test, a Twist + Session-based Logging + Finding Bugs: Debugger versus Logging + TDD, Unit Tests and the Passage of Time + Automatically Include Revision in Log Statement + 7 Ways More Methods Can Improve Your Program + LinkedIn - Good or Bad? + Great Programmers Write Debuggable Code + SET Card Game Variation - Complementary Pairs + Programmer Productivity - Interruptions, Meetings and Working Remotely + What Do Programmers Want? + Coursera course review: Algorithms: Design and Analysis, Part 2 + Blog stats for 2012 (by WordPress) + Working as a Software Developer + 4 Reasons Why Bugs Are Good For You + Book Review: How Google Tests Software + Top 5 Surprises When Starting Out as a Software Developer + Programmer Productivity: Emacs versus IntelliJ IDEA + Why I Love Coding + Coursera course review: Design and Analysis of Algorithms I + Mac OS X Break Programs Review + Favorite Programming Quotes + How I Beat Repetitive Stress Injury + Introduction to Databases - On-line Learning Done Well + 10 million SET games simulated using "Random among 'most similar' Sets" + 10 million SET games simulated using "Random among available Sets" + 10 million SET games simulated using "First found Set" + SET(r) Probabilities Revisited * TAG CLOUD algorithms book book review break program bugs career code coding conference coursera creativity databases debugging developer testing DevOps emacs ergonomics face to face Google hiring history ide idea integration testing intellij interruption interviewing job knowledge learning linkedin logging love machine learning Mac OS X math mathematics meeting meta methods office on-line course probabilities production software productivity professional software development programmer programming programming course programming job python quotes recruiting refactoring Repetitive Stress Injury review revision RSI security SET game simulation software development statistics stats stretches surprises tdd test-driven development testing trouble-shooting unit-test unit testing university work working * RSS + RSS - Posts + RSS - Comments * Follow Blog via Email Enter your email address to follow this blog and receive notifications of new posts by email. Email Address: [ ] Follow Join 410 other subscribers Blog at WordPress.com. * Comment * Reblog * Subscribe Subscribed + [wpcom-] Henrik Warne's blog Join 410 other subscribers [ ] Sign me up + Already have a WordPress.com account? Log in now. * + [wpcom-] Henrik Warne's blog + Customize + Subscribe Subscribed + Sign up + Log in + Copy shortlink + Report this content + View post in Reader + Manage subscriptions + Collapse this bar Loading Comments... Write a Comment... [ ] Email (Required) [ ] Name (Required) [ ] Website [ ] [Post Comment] %d [b]