• Make sure you understand what you have to implement
• Make it work
• Write a test for what you implemented
• Refactor the code for reusability/code standard
• Verify that your code passes linting and tests
• Commit your code on a branch
• Push to the central repository
• Verify that CI passes
• Create pull request
• Annotate code to explain intent of changes

• Always prioritize your work
• Always work on something that is a task in a task tracking system
  • You should always be able to tell someone else what task you are working on and link them to that task
• Always provide an agenda when you book meetings with others

General

• 3 different environments: development, staging, production
• Write migrations for schema changes
• Use ORM if possible over raw queries
• Always make it possible for testers to report the version they tested against
  • Simplest is to have a meta field in the head section

Steps

• Mockups
• SRS
• Database and software architecture
• Implementation
• Test/QA
• Deployment

See also

• Software project basics

• Code changes are stored in git
• Setup continuous integration (e.g., GitHub Actions)
• Use dependency management (e.g., uv)
• Have a testing framework (e.g., pytest)
• Define a code standard, enforced through tools and not documentation (e.g., ruff)
• Prefer typed function/method over dynamic types
• On every commit to git
  • Code quality check
  • Code style check
  • Unit/functional/integration/system tests
    • Code coverage should be recorded during tests and a report made available
• Prior to pushing
  • Use an LLM tool to review the changes to identify potential issues
• On pushes, the CI should
  • Code quality check
  • Code style check
  • Unit/functional/integration/system tests
• A project repository must have
  • a README.md explaining how to run the project on your own computer
  • a RELEASING.md explaining how to release the code
  • a CHANGELOG.md listing relevant changes made
• Responsibilities are made explicit in terms of roles
• Critical roles, such as project lead, must have a backup/shadow individual
• Setup telemetry, alerts, profiling, logging

When joining a new project without tests, here is the value you need to provide through the addition of tests:

1. the application works and doesn't crash
2. the application works and supports a few input cases
3. the application works and supports a variety of input cases
4. the application works and is robust to most input cases

• Write a test that tests the common case usage of your function
• Write tests that cover edge cases of your function
• Write tests to cover all statements, branches, paths