1. 34
  1.  

  2. 15

    I agree! My org-mode work file is massive! A related practice is to leave one unit test failing when you go home, makes it easy to pick up where you left off when you return.

    1. 4

      I’ve thought about starting something along these lines too, but more like one log.org file per project (interlinking shouldn’t be a problem). But I have the feeling that you have to have an idea how to properly structure it before you start, otherwise maintaining it would take too much time, and you’d forget about it after a while. Do you have any tips how to make it easier to use in your case?

      1. 1

        Multiple org files should be fine, I’m pretty sure you can use refile to move items among the files.

        My structures have been redone as I go along. I use a single file with tags to split up accidental and essential difficulties.

        I clock in and out of tasks and sub-items and use org’s reporting functions and orgstat to see how I spent my time. I also use org-clock-modify-effort-estimate (C-c C- x C-e) to make sure I don’t get stuck on a single item.

        I have emacs show org-agenda-list at startup so I always see items where I’ve set scheduled / deadline values.

        org-tempo lets me put source code inline and even run the code and see the results immediately. I use that to collect snippets and build quick prototypes. I also use it to keep interviewees whiteboard code inline with interview notes.

        I still feel like an org-mode newbie, if you have more tips please reply!

        A bonus non-org tip is flycheck-color-mode-line-mode :-)

    2. 4

      I started a thread on journaling a while ago. I got some great recommendations from it!

      I’m curious as to how many folks put their notes directly in to git commits and then actually later reference those notes.

      1. 2

        I sometimes do this, and I find — at least for me — commit messages are the best place for me to take notes. They’re easily greppable, and accessible from any computer in the world. Also I write with a pen like a four year old, and I get impatient with how long it takes to get my thoughts out with a pen, and my hand starts to hurt.

        It’s also really nice having the notes together with the diff. This gives you some scope metadata like exactly what code the notes apply to, and when this commentary was valid/relevant. This is something that comments in code do not achieve.

        1. 1

          Commit messages are a good place, but not ideal for planning - I use a “developer’s readme” for that. What I would like in git (I use git) is a way to write in notes for a branch - when I create a branch I would like to have a notes field that I can use to outline what the purpose of the branch is.

          1. 2

            Git does let you save locally-stored branch descriptions: Branch descriptions in Git

            1. 1

              Thanks! That’s cool. Sad that it is local only. It’s only one extra text field in the branch metadata.

        2. 1

          I currently keep my notes in a SQLite database with a web front end. Mostly so that I have an easy way to search them without having to deal with Git’s structure. That also makes easier to access from a cell phone, which is a big plus when I’m using the note system for things like tracking spending.

        3. 3

          I have a text file for every day that I jot notes down about anything throughout the day. I also keep a personal journal. They’ve both been so helpful, and a good outlet.

          For my personal projects, I have a template file for the project outline, and I also have a mini-log.

          For work, I have a notebook I use regularly (as the author describes), and also have a Vimwiki file for each day noting what I want to do and did.

          It might sound like a lot of work, but it’s actually very little. I get the benefits the author spoke about, which makes it well worth it!

          1. 2

            I starteed doing this at work and while I’ve been slower I’ve been able to handle more complex code be it software development or even infrastructure as code. When dealing with AWS lambdas, SNS, S3, EC2.. It becomes necessary not only to know how services interact with each other but to get into the logic inside each of the instances.

            1. 2

              I’ve recently discovered how powerful keeping a journal can be. I built a small bit of software at work for it, so that I could use it to keep from having far too many files open in SSMS. It’s turned out to be a fairly powerful tool for helping me focus when I’m working on larger problems.

              For me, there were 3 components that were helpful: Having a persistent scratchpad for current context, having a super easy way to capture down thoughts, and having search-driven note lists, so that I can focus on a certain topic without having to see all the notes I’ve recently written.