How to deliver software

Guidance

• https://wiki.c2.com/?PrincipleOfLeastAstonishment
• https://wiki.c2.com/?KeepItSimpleStupid
• https://en.wikipedia.org/wiki/Don%27t_repeat_yourself
• https://github.com/romenrg/evergreen-skills-developers

Process

• split work feature by feature, not layer by layer
• squash merge makes the history less useful for investigations or revert
  • in particular, a story may result in a refactor commit followed by a feature commit. combining those throws away a ton of information and may make refactoring less attractive to developers. they should not be in separate pull requests as refactoring needs context or may be negative work, and benefits from a free round of testing
• merge your own pull requests, own that responsibility
• keep your own tickets up to date. in particular, only the assignee knows when it can really be moved to done e.g. experimental cloud resources may need to be tidied up