Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Log driven programming (2013)

antirez.com

Post reply on HN
Print view View original

61–69 of 69 posts

Re: Log driven programming (2013)

#61

Post by bvinc »

I find it best to put a TODO file in the project that I'm working on. Sometimes I commit it, sometimes I hide it from git. I think it's a big advantage to have it all in one place, not very far from the code, and it won't get lost.

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.

Re: Log driven programming (2013)

#62

Post by majewsky »

mannykannot wrote: post #56
thachmai wrote: post #20

Earlier quoted context omitted.

In my experience, not a lot of developers manage to organize their thoughts well enough to write them down. Maybe you manage to work with only people who can write down their thoughts coherently. But that's the rare exception and not the norm.

Consider what programming is, then consider the implications of the suggestion that few developers manage to organize their thoughts well enough to write them down.

That's exactly why there's so much bad code out there. I don't agree with GP that this applies to most developers, but certainly to a depressingly-high number.

Re: Log driven programming (2013)

#63

Post by TickleSteve »

zabana wrote: post #45
iainmerrick wrote: post #19

Earlier quoted context omitted.

You’re oversimplifying. The key point isn’t the note-taking, it’s about putting newly discovered sub-tasks on a backlog rather than tackling them immediately. It’s good advice, and not something that comes naturally to everyone. “Thought-driven programming” is a good idea, of course, but are you thinking in an effective and productive way? Are there approaches you can use to be more effective? I hope you agree that t…

He's also overreacting.

"over-reaction driven commenting"

Re: Log driven programming (2013)

#64

Post by Fellshard »

coldtea wrote: post #6
Fellshard wrote: post #3

Ostensibly, this is what TODO comments have always been for. 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.

> 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. Why? If they're "out of the code" they still can be ignored before committing or merging just as well...

I'm more likely to write a stub implementation around more complex behaviour that still functions in a minor way first, especially if I want to observe that some component functions even in absence of a complete implementation of another component.

Re: Log driven programming (2013)

#65

Post by jolmg »

> For my log I use Evernote because the log needs to have one characteristic: No save, No filenames, Nothing more than typing something.

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)

Re: Log driven programming (2013)

#66

Post by PinkMilkshake »

mosselman wrote: post #7

How is something as frivolous as taking notes while programming, which many people do, worth a blog post and a mention here on HN? Let alone turning it into some dogmatic principle to work by, by calling it 'log driven' programming. What is next? Keyboard driven programming? 3-monitor-driven programming? I do this: While programming it pays off to stop and think about the code. I call this, thought driven programming…

I think a lot of writers like the idea of coining a term that's in mass usage. It's like a personal brand marketing thing maybe. It's often injected into all of their writing in out of place ways and comes across as forceful and unnatural.

Examples include Cory Doctorow and Ted Nelson.

Re: Log driven programming (2013)

#67

Post by flukus »

raytracer wrote: post #32

A couple of years ago I started using TODO:HIGH, TODO:MED and TODO:LOW. 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…

I create stories in JIRA. It's a lot more effort but the defects are at least visible to management and actually stand a chance of getting scheduled. You can also include a lot more context than you can in a comment.

Re: Log driven programming (2013)

#68

Post by dang »

mosselman wrote: post #7

How is something as frivolous as taking notes while programming, which many people do, worth a blog post and a mention here on HN? Let alone turning it into some dogmatic principle to work by, by calling it 'log driven' programming. What is next? Keyboard driven programming? 3-monitor-driven programming? I do this: While programming it pays off to stop and think about the code. I call this, thought driven programming…

This comment breaks a number of the site guidelines: the one that asks you to respond to the strongest plausible interpretation of a thing, the one that asks you not to post shallow dismissals of others' work, and the implicit one about not being a jerk on HN. If you'd please review https://news.ycombinator.com/newsguidelines.html and follow them in the future, we'd appreciate it.

Re: Log driven programming (2013)

#69

Post by chucksmash »

Fellshard wrote: post #64
coldtea wrote: post #6

Earlier quoted context omitted.

> 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. Why? If they're "out of the code" they still can be ignored before committing or merging just as well...

I'm more likely to write a stub implementation around more complex behaviour that still functions in a minor way first, especially if I want to observe that some component functions even in absence of a complete implementation of another component.

My personal layers of organization:

Stubs with TODOs for staking out an interface to be implemented later and the like. Almost always doing "git add -p" is a good way to jog your memory about these. They can be committed but probably shouldn't survive until a merge into master.

A todo file entry for items which are heftier and/or not likely to be returned to today. My todo files are date-based so I try not to add todos for items with a time horizon beyond about three days in the future. I also try to keep these files small enough to actually get through in a day.

A single wish list/ideas file. Keep it in approximately priority order and pull items from the top when you finish your daily todos. This is also often feature-based so a single line might generate a bunch of tasks. Biased towards a personal backlog instead of "just add to JIRA/Trello/whatever" to avoid eternal agile deprioritization hell.

Works fine for me, though of course I'm not out here writing Redis either.

Post reply on HN