> 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.
Downside: you end up with too much notes.
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.
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.
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.
Whenever you think of something else that needs doing, write it down so you stop feeling the need to keep it in mind.
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.
Why? If they're "out of the code" they still can be ignored before committing or merging just as well...
I could train myself to regularly grep for TODO comments, and perhaps I will, but so far adding them to my actual 'todo app' is much more effective.
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
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.
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.
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)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.
Every project has a readme attached for bigger notes
I do this:
While programming it pays off to stop and think about the code. I call this, thought driven programming.
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.
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.
I've found this to be a really good way to learn from bugs. There is something in the act of writing it down that makes the lessons of it stick better in my mind.
More details here: https://henrikwarne.com/2016/06/16/18-lessons-from-13-years-...
“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.
It is the equivalent of articles and videos on bullet journaling that you find everywhere, portraying it as the silver bullet to becoming organised. "12 ways to organise your life". It might work for some, it might not for others.
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.
This is exactly what I mean with something becoming a dogma when you call it 'xyz driven' programming. You are painting a picture where taking notes while programming is a requirement of being a good programming. I am saying that it doesn't have to be.
Peter Buwalda is a Dutch writer who takes multiple showers a day. He says it helps him overcome his writers block. There is also some science behind this; it turns out your senses will be so busy with the steady flow of sound, the feeling of the water and the fact that there is no visual distraction that you can focus on your thoughts better. He isn't the first to realise this, hence the term 'shower-thoughts'.
So, one could argue, 'shower driven programming' is something we should all do. Installing showers in offices for this purpose or expecting people who work at home to take multiple showers a day in order to focus would be nonsense, but then I could also counter by saying "Well maybe you manage to work with people who can focus without taking constant showers, but that is not the norm."
Ridiculous right? So why isn't it ridiculous to demand that people take notes when programming?
Some of the replies on my comment have been along the lines of 'will someone please think of the children!' with reference to junior programmers. What junior programmers don't need is yet another dogma by which they should 'drive' their development.
It would have been completely different if the 'post' would have been 'Taking notes while programming can be helpful'. That strikes a completely different chord, namely, a helpful one. The word 'driven' does what you demonstrate: it makes people feel inferior when they don't do whatever the given driver is.
One of the (painful) things I learned and continue to learn once I got into tech coaching is how much stuff we do without thinking about it. It gets into muscle memory and it's gone, as it should be. This is one of the reasons mobbing is so successful -- and why it doesn't make a lick of sense to anybody who codes for a living.
So no, there's no level of detail here that I think would be too much. (It may or may not belong on HN, and there's a question around how to organize this detail so that it's useful for folks, but those are different questions from whether or not it has value)
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.
Examples include Cory Doctorow and Ted Nelson.