Skip to content

Comment on Log driven programming (2013)parent

Comments

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.

AboutSource Built by g1lg1l

Hackerly is an independent reader for Hacker News, built on the public HN API. Not affiliated with Y Combinator.