I work in devops support for an under-development software project. At request of the developers, I started keeping up a page in our wiki where, whenever something broke that affected the developers, I just logged what happened, why, and what I'm doing to prevent it happening again. The developers really like this so they feel more in the loop about system issues, but it turns out that I really like it because it's just really useful to have that log.<p>I don't want to keep the wiki page super busy, so I now keep a text file with basically a much more verbose version of the same thing. What happened, what I tried, what I eventually found was the root cause, how I fixed it, and what I'm changing to prevent a repeat.<p>This has two big advantages. First, the obvious one is that when things act up I can sometimes find details on a previous incident that I don't remember very well. The second and I think even greater advantage, though, is that it forces me to actually think seriously about the root cause and preventative measures every single time, instead of just fixing the immediate problem and then going on to the next thing in a rush.
Utterly tangential, pedantic, and pointless pet peeve: people giving projects a "file extension-ish" name (e.g. jrnl.sh) that <i>does not correspond to the language in which the program was written</i>. It's a Python script, not a shell script.<p>And yes, I know that the ".sh" probably refers to the fact that you use it from the shell, not the implementing language. I said it was pedantic, didn't I?
Similar to what is described, I keep a note of all errors I get while developing. I started this practice after realizing how often I search for the same error. Keeping a log of the errors and how I solved it saves me so much of time. I blogged about it here: <a href="https://jjude.com/flask-errors/" rel="nofollow">https://jjude.com/flask-errors/</a><p>Taking notes also makes me to conduct a thoughtful retro of what I have done.
I keep an “engineering logbook”. I surely helps me put things into perspective, I can’t say that it made me more “productive”, but it sure raises awareness on issues and this is enough.<p>I prefer pen and paper by far, so I ordered a personalised notebook, it is pretty good looking, most wouldn't touch it, but I'm planning on doing a <i>collection</i> of them.<p>By personalised I mean that it has my name on it and reads "Engineering Logbook #1". I ordered this book from Stamford Notebooks[1]. No affiliation, but they're I'm planning to ask some customisations when I order "#2".<p>[1] <a href="https://www.stamfordnotebooks.co.uk/" rel="nofollow">https://www.stamfordnotebooks.co.uk/</a>
The tool is perhaps less important than the practice. I keep a journal with entries for every time I am blocked by an issue I cannot solve in my head. The process of writing it down, doing a pro/con list, working out the solution in writing, etc, helps unblock it.<p>It's not so much about posterity as it is about unblocking issues and moving forward in the most sensible way.
Of course there's a million things to do this; I wanted something very opinionated that simply turned a flat RST file that I keep every day (for consumption by me) into some lightly styled HTML (for consumption by others) so wrote rstdiary. I also keep a rough TODO list in there (it's either todo, or it's done and goes into a daily entry).<p><a href="https://github.com/ianw/rstdiary" rel="nofollow">https://github.com/ianw/rstdiary</a><p><a href="https://rawgit.com/ianw/rstdiary/master/sample/index.html" rel="nofollow">https://rawgit.com/ianw/rstdiary/master/sample/index.html</a><p>Been working for me for about 4 years. Once you get a bit of a corpus, it feels silly <i>not</i> filling in some points for the day to keep the thing rolling.
This looks pretty cool. Installing it now.<p>More generally, I've been using Quiver for about a year. Highly recommended. <a href="http://happenapps.com/" rel="nofollow">http://happenapps.com/</a>
FYI: A while a ago I published a plain text (standard) format for journals called journal.txt. See <a href="https://journaltxt.github.io" rel="nofollow">https://journaltxt.github.io</a> Happy writing in your journals.
I keep a journal using text files and Vim, but it is a combination of notes and journal. Instead of chronological order, I use text files based on the subject/topic. For example, I have a text file (journal) just for "Javascript" and another for "React". In fact, I even have notes on "journaling system", so I'm updating it as of now, writing an entry about "jrnl.sh". ON each text file, I'd write down what I learned, as well as snippets and URL of websites I have encountered. I don't use "tags" that often, because sometimes I'd forget the tags, or often it is hard to maintain them. I always have a Vim of notes/journals open, and I use ctrl-p and grep to add/read/search entries quickly. I think I might have about 400 (EDIT: over 1000) text files. Everything is saved to a git repo. Certain notes are published automatically as blog posts Hugo (by adding front matter, etc).<p>I also keep a personal journal in a traditional chronological order, which is a single "journal2017.txt" file. I also recommend using private git repo, not public, since it may contain some of your personal information, and private thoughts.<p>For the non-technical person (i.e. not into Vim or Emacs), I'd recommend Notational Velocity (nvAlt specifically) on Mac. I'd be using it, only if it had vim keybinding. It syncs online to SimpleNote, and it makes journaling really easy.
I track what I worked on in a text file, and more importantly, what <i>decisions</i> related to my business I made on this day. If something comes up that requires a bit of thought, I simply “discuss” it in free text form.<p>It works mostly as a brain dump. I rarely read older entries. But it’s good to know that I could look things up later.
I began using a Github wiki this way. I like writing in markdown, and scaffolded some basic navigation between days, weeks, projects and meeting minutes. It’s been super helpful. I upgraded from billet journaling after finding that a paper journal was not a good enough reference later.
I love this! I use the Terminal and VIM every day and really enjoy tools that fit within that workflow. I didn't even know about this project when I started building a similar tool (with the same name!).
I wanted to journal more but struggled to remember to do so. A simple hack for me was to take a page from Pomodoro an install a countdown timer (I happen to use <a href="https://itunes.apple.com/us/app/activity-timer/id808647808?mt=12" rel="nofollow">https://itunes.apple.com/us/app/activity-timer/id808647808?m...</a>). Every 30 minutes I'm reminded to capture what I've been doing recently. Slowly I've been getting better at updating ahead of the reminder.
Very cool.<p>I've been keeping a plaintext worklog at the day job to help with time-tracking. Logging time in our system as I go is slow and painful, so I just write it down daily and enter it all at end of week (month :|).<p>I have a file for each month (e.g. `2017-12-timelog`), it stays open all day, and I just prepend entries like:<p><pre><code> Dec 1 Fri
9 - 10: emails/updates
- 11:30: BB-X10 make the list update async
- 3:30: hacker news
- 5: BB-X10 unit tests
</code></pre>
I'm going to try jrnl for this use case -- feels like it'll be even simpler.
I've been developing something similar, but as a Telegram bot:<p><a href="https://telegram.me/daytobasebot" rel="nofollow">https://telegram.me/daytobasebot</a><p><a href="https://github.com/martinthenext/daytobase" rel="nofollow">https://github.com/martinthenext/daytobase</a><p>I found it easier to use telegram because it is available on mobile as well as desktop, so I end up writing more things down.<p>Pretty great to discover jrnl.sh, validates my idea that this approach to logging things can have wider adoption.
I got started keeping a dev journal by logging bugs I fixed. I would document the problem, recreate steps (if QA supplied none), what I thought was the problem, what was the actual problem and finally how I fixed it. I also kept a note of where in the source the bug was found. Sure, there are automated was to do this, but we didn't use those at the time and, well, it led to a good habit, so I'm happy.<p>Sadly, as much as I hoped it would, it hasn't translated into a good habit of writing a personal journal.
I’ve been using Noguchi system fairly regularly, for general purpose notes and I imagine it could be very effective in developer journals too. I like the way Its described here, though I use plain text instead of MMD : <a href="http://www.literatureandlatte.com/forum/viewtopic.php?p=15926#p15926" rel="nofollow">http://www.literatureandlatte.com/forum/viewtopic.php?p=1592...</a><p>And this is the key<p>> What I have found liberating is the concept of only have four tags
I noticed a colleague wrote down a basic work log every day, just a high level approach to what he did during the day. I'm interested to try it myself, have done so for a couple of days. I've used Day One, a (iirc paid) mac app, very simple to use for quick blurbs. It also has a CLI, bit awkward to use maybe (`dayone2 new "text here`).
This is a great practice and I encourage all devs to try it. I just learned of the jrnl tool but I use a very similar command line / text / file approach. I have a few shell scripts for starting a new entry which I keep in a new file within the directory. I also commit it all to a git repo.
I do this too! Not everyday, because some days are meetings or the problems I am up against are not challenging. So I guess I only do it for challenges or things I want to remember.<p>Anyways, highly recommend this, it is my rubber duck debugging method of choice!
The comments and original post are great. I keep a directory called Core that has project notes, code snippets and a journal. I recently started using VS Code and a few extensions have really pulled my "system" together.
Is it capable to do basic formatting, like making lists, quotes etc? I see there's a possibility to export into Markdown, but does it parse those formatting elements or should I write them in MD already?
How can I set the "default_hour" to present time in jrnl.sh when I don't mention tomorrow, yesterday etc.? Looks cumbersome to write the present time everytime.
jrnl is cool! I had a good time half-cloning it in node for practice/fun a while back <a href="https://github.com/Robert-Wett/journal" rel="nofollow">https://github.com/Robert-Wett/journal</a>