| I implement a few changes wherever I work: - Commit messages must include a ticket number (or a keyword like "hotfix"). This is enforced by a commit hook that's bundled with the project. - Ticket templates that encourage clear tickets. A ticket should always explain why it must be done. It should also contain enough information for any team member to judge its priority, or start work on it. - Any relevant discussion about a ticket should be in the ticket. Just enforcing this makes a world of difference. It ties every bit of code to a justification. This way, if you decide to rewrite the project, you won't end up losing years of discussions and important lessons. You'll also have a much easier time prioritising and assigning tasks, since everyone knows what they mean. Aside from that: - My first pull request at a company is usually an update to the README file. It rarely matches how you actually use the project. - I write "recipes" for common tasks (lint, deploy, test...). This way, you know that the CI system and every developer in the team performs those tasks in the same way. You can change the recipes, but they are always called with the same command. "scripts/clear-cache" is also easier to memorise than "docker-compose exec backend rm -rf /var/cache...". - Add :party_parrot: to Slack |