I too favor a "code early" strategy. Though I always write down sample data inputs and outputs on paper or in a text file. Sometimes I realize I misunderstood

I too favor a "code early" strategy. Though I always write down sample data inputs and outputs on paper or in a text file. Sometimes I realize I misunderstood some aspect of an API I'm using. It's good to learn that early on. I'm a test-first fan, so I start coding by doing a small test of a small bit of functionality. I'm not doctrinaire, so sometimes I'll write functionality before tests, but usually not. And I write tests pretty soon after if I don't write them first. I use GIT, even on personal projects and have moved away from Gitflow to a CI/CD branching strategy. I'm a bit of a weirdo and write basic usage docs pretty early in the process. I average a couple paragraphs per file, just an overview of what the functions in the file are supposed to do. That way I can get away with shorter per-function comments. Most importantly my comments document my intention, not what I'm doing. I can tell I'm incrementing a variable by looking at the code, but if it's non-obvious why I'm incrementing it, I'll writa a comment about that. Test first and documenting intent help me regain context if I have to put the project down and pick it back up later. I sometimes use code coverage tools, but I've gotten pretty meh about it lately. I'm learning TLA+, but already use KAMI on hardware projects. I think there's a lot of potential upside w/ verification tools, but dang if it's not a little brain-bending sometimes. I've also rediscovered my love of Lisp in the last 5 years, so am using Janet or Scheme a lot for personal projects. Not sure why I don't use Clojure more, it's a perfectly fine language.