Principles which I follow when programming
Bharat Kalluri / 2020-07-15
- Type everything, if you can not type something properly then probably it is too complicated (applies to untyped programming languages)
- Name functions clearly. It is perfectly fine if the name of the function is long.
- Test extensively, might be time consuming now but will help long term.
- Equip yourself with the right tooling. Do not let syntax errors, linting errors, spelling mistakes in your codebase.
- Review the PR yourself before you ask for a peer review.
- Do not argue over formatting, decide on a formatter and stick to it. No questions.
- Keep infra as simple as possible. Do not drive your infra decisions based on hype, drive them based on reason.
- Log all the set backs. It is understandable that some features will not be as complete as you would like them as of release date. Because of several reasons (running out of time, thought it would be easy but involves more complicated changes etc..). But make sure to create an issue or have atleast a TODO so that future you or someone else on your team can pick the pieces later and fix the system.
- Log all checkpoints in the code. In a world of microservices, it is essential that all logging be as descriptive as possible.
- Dependencies should be added after a lot of consideration. If instead of adding a dep, you can write a small piece of logic, it is better to write that short piece. But, if the dependency takes core of a constantly changing spec (Like an API of an external provider), dependencies are welcome as they help us offload work.
- If you are SSH-ing into a QA/Prod server, you are most probably doing it wrong. Automation is key. Automate build/release/deploy/logging etc.. as much as possible.
- Document infrastructure. If you are using platforms like cloudformation (Infra as code), then this step is not necessary I guess. But for everyone else, documentation of infrastructure is very important for onboarding new developers.