by eric24234 on 10/8/18, 8:49 AM with 64 comments
by aeosynth on 10/8/18, 9:11 AM
> An important part of any organization system is the ability to quickly capture new ideas and tasks, and to associate reference material with them. Org does this using a process called capture.
by DanielBMarkham on 10/8/18, 9:10 AM
I used to use TODOs, but then if I wasn't looking at the code I forgot about it, and a lot of the stuff didn't have a spot it needed to go. It was just stuff I thought about while I was doing something else.
Daily (or twice daily) I reorder and prioritize. Every week or two there's a postit cleanup party where old postits get trashed or logged. A lot of the stuff that I trash isn't bad....it's just not in scope for the stuff I'm currently doing.
ADD: One of the beauties of postits on my monitors is that when my mind wanders -- as it tends to do -- I'm naturally looking at other stuff I should be thinking about. So when I postit stuff and put it somewhere in my field of vision, I'm telling my subconscious to start working on what I want to do with this stuff.
by raytracer on 10/8/18, 11:03 AM
TODO:HIGH is for things that need to be completed for the current feature or bug fix.
TODO:MED is for things that should be completed before the next public build.
TODO:LOW is for stuff that would be good to get done eventually. (A function is complete but doesn't read well so I'll add a note to refactor it at later date.)
When writing new code I try to get something up and running ASAP by filling in functionality with broad strokes. I'll go back and fill in the details once the larger picture is in place. With less code written, it's easier to refactor (or restart), if the design is not quite right.
Writing lots of TODOs helps ensure nothing gets forgotten about.
Picking an easy TODO from the backlog can be good way to warm up when starting the day too.
I'm used to working solo however. Not sure how this approach would go down on a team.
by barrkel on 10/8/18, 8:58 AM
Whenever you think of something else that needs doing, write it down so you stop feeling the need to keep it in mind.
by Fellshard on 10/8/18, 9:05 AM
Realistically, I guess it's probably better that these types of comments remain out of the code itself unless you and your team can practice proper rigor around them, e.g. using prehooks to enforce that no TODOs are left around before committing or merging.
by keyle on 10/8/18, 9:33 AM
Have it between you and the keyboard so it can't be ignored, presumably not ruining your typing experience.
Straight up notepad or sublime works too.
by bvinc on 10/8/18, 5:01 PM
TODOs in comments end up getting forgotten about. Bug ticketing systems are too much work for the kind of notes I write to myself. I've tried using paper, but as I turn pages, notes on previous pages get lost forever. Staying in the text editor helps me not lose my flow.
by jolmg on 10/8/18, 11:43 PM
I got emacs configured with a keybinding to open org files by date name (e.g. 2018-10-08.org), with the current date selected by default, creating them if they don't exist. I use `(org-read-date)` so I can, for example, get yesterday's notes with syntax like "-1d" or select it from a 3 month calendar. It frees me from having to think of a name for the notes I want to take and simply make a log of notes. It also autosaves.
(defun find-diary-file ()
(interactive)
(find-file (concat "~/org/diary/" (org-read-date) ".org")))
(global-set-key (kbd "C-c d") 'find-diary-file)
by Dowwie on 10/8/18, 11:41 AM
Obviously, Salvatore didn't invent a new creative workflow that he's branded "log driven programming". His intent with this article more likely was to share with others how he works productively. I can imagine that people asked him how he gets so much work done, considering how complex programming is, especially low level systems programming in C.
While the article was written in 2013, it shares timeless advice.
by cyborgx7 on 10/8/18, 9:41 AM
by hyperman1 on 10/8/18, 11:39 AM
Every project has a readme attached for bigger notes
by bzalasky on 10/8/18, 1:09 PM
by skohan on 10/8/18, 10:46 AM
by keithnoizu on 10/8/18, 10:12 AM
by mosselman on 10/8/18, 9:18 AM
I do this:
While programming it pays off to stop and think about the code. I call this, thought driven programming.
by basicplus2 on 10/8/18, 12:50 PM