General Principles

  • We version control, usually git, everything we write.
  • We create short lived branches -
    • This helps in code reviews.
    • This helps reduce merge conflicts.
    • This helps to deploy more often. This is not necessarily true for mobile apps where release cycle takes days.
  • We write testable code.
  • We document.
Why Document? Code that you wrote 6 months ago is often indistinguishable from code that someone else has written. You will look upon a file with a fond sense of remembrance. Then a sneaking feeling of foreboding, knowing that someone less experienced, less wise, had written it. As you go through this selfless act of untangling things that were obvious or clever months ago, you will start to empathize with your users. If only I had written down why I had done this. Life would be so much simpler. Documentation allows you to transfer the why behind code. Much in the same way code comments explain the why, and not the how, documentation serves the same purpose. Taken from - WriteTheDocs
  • We write really good commit messages. Our commit messages should reflect our train of thoughts -
    • This makes reviewing a pull request much easier as reviewer can go through commit by commit rather than looking at the whole diff.
    • This helps in finding a regression in future.
    • This helps in cherry-picking a commit to other branch if we need to.
  • We almost never push directly to master/main.
  • We own our code. We take responsibility of maintaining what we produce.