I started writing a developer log several years ago when our task tracking functionality was not up to scratch and I was working on an extended project. I wanted to be able to prove that I was working hard, even though I initially had nothing to show for it. However, devlogs actually have several major advantages that make it worthwhile:
1. How did I fix that last time?
Every time I get an error, I copy/paste it into the devlog. Later, I can then search and deal with the same error much more quickly (or at least rule out stuff I tried last time). This makes it easy to answer others' questions when they say, "hey, have you seen this error before" -- I can definitively say "yes, here's what I did" or "no, never seen that".
Every time I fix a problem by googling it, copy/paste the helpful website link, with a few keywords about the problem. This makes it much easier to find the fix if it comes up again.
2. Where was I?
When I get interrupted, it is easy to resume what I was up to, because my mental stack is no longer in my head -- it is written down. If it is not fully up to date, it is at least a hint about what I was doing before I was interrupted. I have found this extremely valuable because getting interrupted while in a high-mental-flow state is no longer a terrible frustration: Getting back into the state now requires a few seconds' reading over my notes instead of (potentially hours) going over old decisions to rebuild the state from scratch.
The devlog has actually become my anchor. Whenever I finish something or resume after an interruption, I scroll back up a little or look at the list of todos maintained at the bottom of the file. It is very comforting knowing that it is always there.
3. Stress management
It is well known by psychologists that identifing feelings by name makes them less intense. I find that documenting my work makes it less stressful, which has become my primary method of dealing with stress. Previously, the only way I could deal with it was by deciding that I didn't care if the project failed, as the concept of caring and having it fail was too much to deal with. Writing down my todos, thoughts, problems, and swearing about them a little in text that others won't read without my permission has been very positive for my mental state and mental health.
4. I don't want to worry about that right now
My time management is better. Apart from being able to easily resume flow after interruptions, I also manage subtasks better. Whenever I have a problem that I can't solve immediately, I describe it and add the word "todo" somewhere. This triggers me to think, "can I fix this in five minutes?". If so, I fix it immediately, and then resume flow by reading over what I was doing beforehand, and so hardly lose any time. If I start it and then it takes more than five minutes, I just abandon it and leave the TODO. If it is important I will add it to a real to-do list somewhere (perhaps at the bottom of the file) so it doesn't get lost. Sometimes I search for the word "todo" and then change the ones I have done to "done" (which is satisfying) and make sure the others are still not urgent, either deleting the word or moving them to a better-tracked list.
The end result of this is that I no longer come back to an old problem and say "oh yeah, I meant to fix that but I forgot.". I now forget intentionally, and don't forget the important things.
5. What did I do this month?
I have a record of what I did. This lets me tell other people what I have been doing -- we got audited last year for research tax breaks and I could provide evidence of the research I was doing. This saved everyone lots of effort in trying to reconstruct how much of my time had been spent on research.
6. Why did I do that again?
When working on an extended project, there is a complete record of all the design problems I considered and all the sources and external resources I investigated as part of the design process. This can be extremely valuable later on, either for onboarding new developers or handing over the project to someone else.
This is partly so important because many projects do not have great test suites. A thorough test suite, with each test's reason for existence well explained, is also very useful. Tests that you don't know why they are there can't be modified. If you understand the requirements, you know what you need to redesign when they change.
7. When did I first think about that?
This approach is standard practise for research scientists (which I used to be, and is where I learned it).
If there is ever a patent dispute or argument about where something came from, I have some evidence about where my ideas came from.
Further reading: https://simpleprogrammer.com/bullet-journal-productivity-programmers/
