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…

Scrum and Agile and all methodology bollocks goes right out the window when you're paying for the build yourself. Every software professional needs to go through this process at least once. Put 5K or 10K of your own on the line to build something, and see how many of your sacred cows are slain. You're not an effective economic decision maker (which is what all software decisions ultimately are) until you have had your own skin in the game.