> 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.
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.
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.
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.
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.
That's what I do as well. Also, in OO languages like Java or C#, you can throw "NotImplemented" style exceptions. So that if you mistakenly wrote "TO DO" instead of "TODO" and can't find it statically, the runtime will let you know.
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.
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...
personally I just write the function call, wait for my IDE to complain that the function doesnt exist, press command enter to have it generated with a throw new NotImplementedException().
works well for me, gives me the illusion of a working api, and I get autocompletion.
This requires you to give your functions well thought out names though
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.
> 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.
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.
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.
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.
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.
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.
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.
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.
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 there might be some value in identifying and teaching such approaches.
Its not just taking notes. Its a common pattern while fixing bug, you encounter a code path that with a 3 minute time you can make it so much better, but should you continue on your original plan or take 3 minutes to make the code better is the question. The blog says don't spend time on diverging the original plan instead mark it for later. Another good name would be "breath first traversal development"
Have you considered publishing a manifesto about this.. "thought driven programming"? :)
antirez shared a successful methodology for programming. He gave that methodology a name. It is helpful to name something when communicating the idea to others.
I've personally found great benefit reading this and I am sure a lot of people will. As obvious as it may sound, it's always nice to be reminded every once in a while.
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.
[+] [-] aeosynth|7 years ago|reply
> 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|7 years ago|reply
Downside: you end up with too much notes.
[+] [-] DanielBMarkham|7 years ago|reply
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|7 years ago|reply
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|7 years ago|reply
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.
[+] [-] qubax|7 years ago|reply
[+] [-] flukus|7 years ago|reply
[+] [-] barrkel|7 years ago|reply
Whenever you think of something else that needs doing, write it down so you stop feeling the need to keep it in mind.
[+] [-] keyle|7 years ago|reply
[+] [-] Fellshard|7 years ago|reply
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|7 years ago|reply
Why? If they're "out of the code" they still can be ignored before committing or merging just as well...
[+] [-] thecatspaw|7 years ago|reply
works well for me, gives me the illusion of a working api, and I get autocompletion.
This requires you to give your functions well thought out names though
[+] [-] keyle|7 years ago|reply
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|7 years ago|reply
[+] [-] bvinc|7 years ago|reply
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|7 years ago|reply
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.
[+] [-] Dowwie|7 years ago|reply
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|7 years ago|reply
[+] [-] hyperman1|7 years ago|reply
Every project has a readme attached for bigger notes
[+] [-] bzalasky|7 years ago|reply
[+] [-] skohan|7 years ago|reply
[+] [-] keithnoizu|7 years ago|reply
[+] [-] mosselman|7 years ago|reply
I do this:
While programming it pays off to stop and think about the code. I call this, thought driven programming.
[+] [-] dang|7 years ago|reply
[+] [-] onion2k|7 years ago|reply
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.
[+] [-] iainmerrick|7 years ago|reply
“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 there might be some value in identifying and teaching such approaches.
[+] [-] rick22|7 years ago|reply
[+] [-] thachmai|7 years ago|reply
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.
[+] [-] jacobush|7 years ago|reply
[+] [-] Dowwie|7 years ago|reply
antirez shared a successful methodology for programming. He gave that methodology a name. It is helpful to name something when communicating the idea to others.
[+] [-] zabana|7 years ago|reply
[+] [-] unknown|7 years ago|reply
[deleted]
[+] [-] PinkMilkshake|7 years ago|reply
Examples include Cory Doctorow and Ted Nelson.
[+] [-] rightbyte|7 years ago|reply
[+] [-] cyborgx7|7 years ago|reply
[deleted]
[+] [-] basicplus2|7 years ago|reply
[+] [-] unknown|7 years ago|reply
[deleted]