An experiment for devs to try. I started keeping a "dev diary" while working on
@breezbook . It was prompted by a statement by Stuart Ervine when I asked how others keep broader context of decisions behind code that are not visible in code, tests or comments.
I wanted to start simple, so it's just one long markdown file. My partner on breez, Metehan Altuntekin, suggested that a tool like Obsidian or similar might be more appropriate. But I'm happy I stayed with a simple text file. I can edit it in my code editor, while I'm coding, without breaking flow.
It's a good sounding board when I'm working on my own. I can write down my doubts and concerns, and just the act of getting them down helps me think them through better.
And I can feed it to an LLM and ask questions, like: remind me why I decided on
@inngest for messaging? Or why might the location_id field on service be optional instead of mandatory.
I consider this a worthwhile experiment to try on dev teams. Yes, ADRs, but consider this as an alternative or complement.
And Stuart Ervine, if you have any experience reports to share, I'd be all ears.
The dev diary is here btw -
github.com/cozemble/breezboo…