@dhromed said:
100% correct. If I don't jot it down, it's gone, unless I happen to remember it the next day and then write it down.
@uricmu said:
people branch out a lotI don't. Or tend to avoid it as much as possible.
@uricmu said:
If you look at one of your old reminder sheets, can you easily pinpoint the meaning in each?The old stuff gets deleted. The current stuff is also current in my mind.
Another detail of my way of working is that I do not, under any cicrumstances, leave "Todo" comments in the code -- precisely because of the 99% danger of forgetting. I'm assuming that your software targets this issue specifically and tries to turn it into a strength?
I think that branching is unavoidable in many cases, or merely the situations in which you realize there are two things you need to do (e.g., robustness and refactoring vs. continuing work); the branch is inherent in that you pick one and leave the other. Some tasks are just branching by nature. You know you are going to have a source, a destination, and a protocol for something, you have to branch by picking one.
Again, some of the stuff I said is based on a fairly elaborate study on how people deal with reminders during development, but there are naturally differences between individuals.The issue of to-dos in the code do make you relatively unique; most people leave at least some notes that way. However, it is a known phenomenon that people avoid //todos in the code, partly because the clutter it creates and partially because of bounded transparency (not wanting others to see their incomplete work or know how many things they haven't finished).
My tool offers an alternative to code to-dos. It costs no more (and actually less) than a to-do comment, but it's stored separately from the code. Hence, you don't worry as much about clutter, and you can see it in different ways. First, when chronologically looking at everything that you've done (and therefore have your to-do connected to the high-level modification request you were working on), and second, in other contexts than the method in which they appear. Either with external notes or with code to-dos, that would be a problem at least some of the time. If you leave a to-do in the code, you often has to actually read the code to know that it's there; with my approach, you're reminded of it while working on something relevant or something that depends on it.