This attempts to capture best practises and resources to engineer good software.
The books are available from our internal library. Feel free to ping anyone in the team to get access to them.
- The Pragmatic Programmer
- Structure and Interpretation of Computer Programs
- The Mythical Man Month
- Design Patterns: Elements of Reusable Object-Oriented Software
- Programming Pearls
- Clean Code
As a reviewer, do your best to get the author's work into
- If you like a different approach, point it out after appreciating what has been put forward.
- Summarize reviews
- what you looked into deeply
- what you skimmed over
- next steps to get it merged
- have a conversation around the change
- Why is this done this way?
- What does this do?
- This doesn't make sense
- I dont understand X, I think doing A will make things simpler for reasons R1, R2
- Could we unpack this and make it a bit more readable?
- This can be better done as Y
The purpose is not sugar coating, rather to promote an environment where good conversations around code can happen.
As an author
- Always lint your code. Treat lint warnings as errors. Fix them!
- Make sure your code comments say why and not how.
- Respond to reviews in a timely manner.
- Don't blindly accept feedback and make code changes. Work through trade-offs and explain your approach. In times of conflict do this