Coding Best Practices

This repository is a personal compilation of coding best practices I learned or not, the easy or the hard way, along my journey as a software engineer.

Bugs

1. There are no bugs, only unintended features.
2. Since there are no bugs, no need to plan for an emergency rollback.

Development

1. Just commit garbage without proofreading it, thanks to github suggested changes reviewers will take care of fixing it.
2. Friend Driven Development is the practice of approving your friends' pull requests without reading them. Obviously an implicit friendship agreement stipulates that one approval is worth another approval, so that the Friend Driven Development can keep going.
3. The previous point shall not be confused with the Genius Driven Development, which consists in approving your teammates' pull requests without reading them because they are geniuses. The approval is merely here to by-pass the branch protection rules. Please refer to the inner json effect for more details on this best practice.
4. Sometimes reviewers want you to add minimal documentation ( like an entry in the changelog ) and execute a smooth transition, especially when breaking an existing behavior on which users rely. This is time-consuming and, to be fair, your time would be better used shipping more breaking changes. The best way here is to avoid reviews all together and directly commit on the main branch.
5. There is no problem that cannot be solved either with git push --force or with git merge -X theirs.

Formatting

1. The golden rule is that new is always better, no need to stick to the existing text formatting.
2. In comments and other forms of documentation, infinitive form ( e.g. "add" ), third-person singular simple present ( e.g. "adds" ), present participle ( e.g. "adding" ) and simple past ( e.g. "added" ) can be mixed up.
3. " and ' are the same things, one can use them interchangeably in the same file.
4. Spaces and tabs are the same things, one can also use them interchangeably in the same file.

Maintenance

1. If it works, don't touch it.
2. If it works now, it will work with 100 times more load.
3. This is a temporary solution.
4. TODO: fix it later.

Ownership

1. You touch it, you own it.
2. Deletion Driven Development, also known as Scream Driven Development, consists in a nutshell in deleting this unknown and apparently-unused piece of software/infrastructure and transferring ownership to the first person to complain.

Reliability

1. Want to know if your change will break prod? Ship it. Prod is the best testing environment because it's the closest thing to prod.
2. Hope for the worst, but prepare for the best.

RFCs

1. RFCs are a waste of time. You want to know how people feel about something you want to do? Do it, and see who complains.
2. If you have no choice but to write an RFC, make sure it's imprecise enough so that no constructive criticism can be made.
3. If you have no choice but to write a precise RFC, make sure to send it for review so late that nobody has time to comment. The best timeline in this case is to send the RFC once the project is actually implemented.

Versioning

1. After introducing a breaking change, add a description in the breaking-change section of the changelog, and only bump the semver PATCH version.

Workflows

1. Monorepo just works.
2. Multirepo just works.

Disclaimer

Obviously, everything described in here is purely ironic. These pro-tips should not be used in real life for the sake of readability, maintainability and scalability.

License

Unless explicitly stated to the contrary, all contents licensed under the Creative Commons Attribution 4.0 license.