
Log driven programming (2013) - eric24234
http://antirez.com/news/51
======
aeosynth
[https://orgmode.org/manual/Capture-_002d-Refile-_002d-Archiv...](https://orgmode.org/manual/Capture-_002d-Refile-_002d-Archive.html#Capture-_002d-Refile-_002d-Archive)

> 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_.

~~~
bpizzi
This, and it's something baked into Spacemacs (easy to replicate with a
vanilla Emacs, thought): working within a projectile-initialized folder,
hitting <leader>po will open a TODO.org at the root folder of your project,
where you can write anything you want (including inserting an Org-mode link to
the file/line you were editing), and save/switch back to your file in a
handful of keystrokes.

Downside: you end up with too much notes.

------
DanielBMarkham
I use postits for this.

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.

------
raytracer
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 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.

~~~
suprfnk
Exactly. I don't see why you would do this in another application. Doing it in
another application means you also have to take note of _where_ the piece of
your TODO is. That means filename and line number?

While I don't use priorities, I do liberally use "// TODO: <problem
statement>" if it's something I need to do that takes me out of the current
problem. Then when I'm finishing up a feature or bug fix, I just walk past the
list of TODO's.

A recent example would be: On this new project I was on, while implementing a
feature, I didn't know how resource files were handled yet -- so I hardcoded
some strings with a "// TODO: Put these strings in resource files".
Researching the way resource files are handled will pull you out of the
current problem, while it's something that can easily be solved later.

------
barrkel
This is my workflow and has been for the past 10 years or so.

Whenever you think of something else that needs doing, write it down so you
stop feeling the need to keep it in mind.

~~~
keyle
Excellent; but does it ever get done?

~~~
TeMPOraL
Yes. In particular, if you use the same place to note down things you want to
do in the first place. Then it boils down to continuously reviewing the list
and picking the next thing to work on.

~~~
mercer
This is a reason why I generally avoid using TODO/FIXME type comments in my
code. I'm much more likely to forget about them, whereas I always need to look
at my org-mode project file to see what I need to do. So that's where I put
them.

------
Fellshard
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.

~~~
coldtea
> _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...

~~~
Fellshard
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.

~~~
chucksmash
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.

------
keyle
Yep, a notepad with a direct step by step 1 liners is very effective to get a
ton done in one day.

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.

~~~
rejschaap
"Straight up notepad" means notepad.exe nowadays? That is really interesting

~~~
keyle
Haha, thank you for making me feel young for a minute :-)

------
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.

------
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)

------
Dowwie
For those unaware, the author of this article (Salvatore Sanfilippo) is a
prolific programmer and leader in open source. He's been very productive in
this role, authoring systems that many use today, such as Redis.

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.

------
cyborgx7
Had the same idea as I noticed that working in a nested way slowed me down a
lot. Been trying to do this but I often lack the discipline to actually work
this way and not dive into the local improvement I just thought of.

------
hyperman1
I use TODO and FIXME for this. This way, it's directly anchored to the
relevant code. Both the IDE and the build server produce a list when asked.

Every project has a readme attached for bigger notes

------
bzalasky
This is essentially the process that Things 3 (I’m not affiliated in any way)
for MacOS/iOS uses. It separates adding new tasks (for your inbox) from the
step of organizing and scheduling them. So if you think of something you need
to do, you can use a keyboard shortcut to pull up a prompt quick add it (from
whatever app you’re using) and carry on with whatever else you’re working on.

------
skohan
I wrote a simple app for myself for this: it's basically a text editor with
included checklist UI, optimized for a keyboard based workflow. I find it very
useful to have a "conversation" with my notes while I'm developing to avoid
going down too many rabbit-holes, and to keep focus on the primary task.

------
keithnoizu
I usually just make the additional changes but I'm pretty good at keeping
pretty massive mental models in place while I do so with out interrupting my
work flow. If it's something truly massive i add a @TODO ... @PRI-N line in
the comments.

------
mosselman
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.

~~~
onion2k
Over the past 20something years of being a developer I've found there are _a
lot_ of things that seem obvious to me now that junior developers don't do by
default. Looking back I wonder when I started doing all these obvious things.
Presumably, if I didn't discover them myself, it was when I was told about
them or I read about them. If no one is writing these "frivolous" things down
then how will juniors learn?

If this helps a few new devs who don't have access to a good mentor (because,
say, their mentor makes assumptions about what's obvious..) to tell them about
this idea then it's automatically a useful post.

~~~
chatmasta
The best habit that any developer can have is _reading code._ It’s shocking
how few devs spend time reading code; whether the code is from library
dependencies or entirely unrelated third party projects, I always learn
something new just by reading it.

Not every developer is blogging their best practices. If you want to see them
and learn from them, the best place to look is in the code.

Honestly I think we should be reading at least 10x the amount of code we
write. For every novel an author writes, how many novels do you think they
read? Certainly more than ten. Why shouldn’t we do the same? In a world awash
with open source code, there is really no excuse not to be reading as much of
it as possible.

~~~
Ntrails
There are two interesting parts to reading code.

    
    
      - Working out what it actually does, and why
    
      - Working out why somebody *wrote it in that way*
    

The former is usually not too bad. Occasionally there will be a comment to
help with the latter (although rarely ime). The latter is basically
impossible. I can ask 3 other devs, they'll all disagree. Some like the style,
some hate it. Each will complain about different aspects, and none of them
would write it quite the same for ~reasons~

Maybe it's just me vOv

------
basicplus2
Sliderule

