i write a lot of stuff solo. i also realize that 75% of writing software is making sure others can read it. so what I usually do is this:
- write documentation upfront (with Hugo or something like that) to explain what I'm building, why, how to use and/or compile it, and how to test it. i do this before i lay down any code. this also helps me re-justify the time investment i'll be spending on writing the thing. (it is much much easier to maintain documentation before you start coding than after. once you're in the zone, you're in)
- write behavior/end to end tests that describe what major components of the software will do and how they will interact with each other. these tests usually change, but I consider this a second layer of documentation
- make code as readable as possible, i.e. small functions, high modularity, reasonable var names, etc. i also use linters heavily.
- i try to break up major pieces of work into pull requests despite me being the only contributor and explain what happened and what the work introduces within them. i'll also add comments to sections of the code that don't make sense. i use PRs for this instead of git commits or (only) comments because i've found them to be much better at digesting large codebases, and they are great spaces for discussing changes within context.
- write documentation upfront (with Hugo or something like that) to explain what I'm building, why, how to use and/or compile it, and how to test it. i do this before i lay down any code. this also helps me re-justify the time investment i'll be spending on writing the thing. (it is much much easier to maintain documentation before you start coding than after. once you're in the zone, you're in)
- write behavior/end to end tests that describe what major components of the software will do and how they will interact with each other. these tests usually change, but I consider this a second layer of documentation
- make code as readable as possible, i.e. small functions, high modularity, reasonable var names, etc. i also use linters heavily.
- i try to break up major pieces of work into pull requests despite me being the only contributor and explain what happened and what the work introduces within them. i'll also add comments to sections of the code that don't make sense. i use PRs for this instead of git commits or (only) comments because i've found them to be much better at digesting large codebases, and they are great spaces for discussing changes within context.