dev-norms/dev-norms.md

Create and maintain developer norms and PR template for your project in your repo.

# Norms

> Developer norms are a necessary way to set some ground rules in place for your team. It is vital to a team's success that all team members are on the same footing and the code base is easy to get started with, maintain, and consistent. Further, all team members should be treated with respect and given equal opportunity to contribute. It is important to write these ideals down. So, what's a better place to encode these ideals than in your respository?

Here's a starter list of developer norms:

1. Treat every team member with respect and give every team member equal opportunity to contribute.
2. Organize around delivering working code! Sprints, stories, points, and all the fancy management techniques in the world won't help you deliver good code. If you must re-read http://agilemanifesto.org/ and practice DRY, KISS, and SOLID.
3. Document team on-boarding instructions, including a quickstart guide in `README.md`. It is the responsbility of every new team member to update the instructions with any changes.
4. Ensure every team member has access to all the same documentation, development tools, plugins, and extensions.
5. Don't over-engineer. Always start with the monolith. The best design isn't the most complicated one you can imagine, it is the one the most junior team member can easily understand, maintain, and modify.
6. Relentlessy iterate. It is always possible to release a simpler version of a feature than you thought possible. Release that first. Simple doesn't mean bad.
7. Develop a walking skeleton first. Stub out functionality, hammer out interfaces, and points of integration. Write minimum code to get things working end to end, then iterate to fill in the blanks and implement improvements.
8. Use a Continuous Integration and Continuous Deployment (CI/CD) server.
9. Practice Infrastructure-as-Code. You don't need sophisticated tools, make sure to commit every command you use as shell scripts.
10. Always disable commits to main branch. Enforce every change to be submitted by a Pull/Change Request (PR).
11. Enforce that PRs must be up-to-date, passing all CI/CD, code coverage, code quality, linting checks, and require a review from a peer. Don't allow stale reviews.
12. Always push working code, if you break the pipeline or the build, fix it. If PRs are set up correctly, you'll never allow a change to break the build for everyone.
13. Make granular and small commits, per feature or per bug fix. Ideally, at least one a day. This is to protect you the developer. Computers get damaged, harddrives fail. Sync your commits at the end of the day. _Managers: Negative line-of-code commits are often more valuable than lot's of new lines-of-code. Don't weaponize metrics against your team, that's not the way to foster high performing teams._
14. Provide descriptive commit messages. You will forget the details of what you were working on just a few short weeks later.
15. Leverage `pull_request_template.md` to ensure that team members follow all pre-merge instructions. It is 10-100x cheaper for the correct code to be merged and shipped than to release with bugs, incorrect functionality, or security flaws. A sample template was created in your repo.
16. Write self documenting code. Use descriptive variable and function names. Avoid unnecessary name shortening.
17. Don't leave dead/commented out code behind. If you see such code, delete it.
18. Write automated tests to cover critical integration points, critical algorithms, business logic, and useful functionality. Don't test autogenerated code or code you don't own (as in ones inherited from frameworks and libraries).
19. Use the feature you just developed before shipping it.
20. If you don't ship it, it never happened.

`Rev 07.2023`