Hacker News new | ask | show | jobs
by jrheard 3501 days ago
One thing that's been useful for me on this topic is to keep a simple dev diary. Mine looks like this: https://github.com/jrheard/voke/blob/master/dev-diary.txt . I use it to get as much project state as possible out of my head and into git.

For "10 minutes figuring out where I was", I can just look at the end of my last diary entry, where I've often left a note like "this is what i'm working on: foo" or "do this next: foo, bar, baz" or "currently stuck on baz". And if I haven't left a note like that, I can usually deduce one by scanning the last few paragraphs of the last day's entry.

For "15 minutes researching how to do that next bit I want", that has to happen no matter what, but I like recording that research in my dev diary so that I can search through it later if I run into the problem again or want to remind myself why I settled on a particular solution - and I find that forcing myself to write down my analysis of this research helps keep me on task during the research process and helps prevent me from getting distracted.

You get the idea. I don't have any written-down rules about how to keep a dev diary, what goes in there and what doesn't, best practices about solving X software engineering problem by implementing certain dev diary techniques - I just have a freeform text file that I write my thoughts into every day when I'm working on my project. It seems to be a useful technique for me, maybe it'd work for you!

I used to do the don't-break-the-chain jerry-seinfeld thing, but I find it too stressful, it starts to really affect my quality of life (and the quality of the work that I do!) when I've got a chain going that's more than a month long. Plus, if the point is to prevent thoughts/state/meta stuff around the program from slipping out of your mind over time, writing it down seems to me like a good (better?) way of solving that problem.

When I find a problem that recurs in my dev diary without me coming up with a solution, or I have an idea that I'm not going to work on now and which I worry will be lost in the folds of my diary, I find an issue tracker like GitHub's (eg https://github.com/jrheard/voke/issues ) helpful.

1 comments

That's very similar to what I do. I have a TODO list that includes notes, and big features that I break down into very small tasks. I can get back where I was on a project in just one minute, because the TODO list tells me.

When debugging a difficult issue, I also take notes about my findings, and ideas of directions to investigate next.

I also do something similar with a TODO list however I haven't figured out a good solution to organize it. For example lets say i'm working on feature A and then B. During the developement of A, I find I also need C & D so I add them to the TODO list which now looks like ABCD when the actual development order needs to be ACDB. This cause my TODO list to become quickly out of sync with the order in which things need to be done. With long lists of inter-dependencies, have you found a good method of keeping your TODO list from jumping all over the place?
I reorder the items periodically. When I start my day, I make a plan for what I'd like to achieve, and organize it based on priorities, dependencies, and also what I feel like doing. If I'm tired and can't concentrate well one day, I will take on smaller and easier tasks.