I've tried that and I have to spend 10 minutes figuring out where I was, 15 minutes researching how to do the next bit that I want (esp. for a project in a new dev environment), 10 minutes upgrading various libraries or other stuff that is needed/needs updating, and then maybe 25 minutes of actual coding. I progresses very slowly.
Maybe my side projects are too ambitious, at least relative to my skill in their respective areas.
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.
When debugging a difficult issue, I also take notes about my findings, and ideas of directions to investigate next.
Also, if you're putting in an hour a night, why are you updating packages?
Likewise using tools like Trello - make simple lists "To do, doing, done", rank them in order, and start working on whatever is at the top of the "to do" list?
I do research during the day and save important bits on pocket or google keep, so when i have that hour i can be more productive.
It's so easy to focus on getting shit done, to the exclusion of treating yourself well sometimes. I think I need to plan a follow-up.
I'm devoting a single our per day on an android app and i'm having a great progress, i'm doing a tiny feature every day. And that's fine, it's done when it's done, i'm the one doing it and managing so there's absolutely no problem.
If you start looking at the side project in a very serious way, you'll end up with guilt , frustration and remorse and that just kills the fun out of it.