Go wide, then refine

When creating something, it is better to understand the picture - at a high level - instead of focusing on the thing you need to create immediately.

Code should work, but does not have to be efficient.

Be constructive, not destructive.

When you know you aren’t aligned, resolve early.

Act on unalignment rapidly to ensure happy teams

Understand a problem individually, then share it.

Capture your understandings separately to the team and then come together to align

Hollywood Principle

Write code to respond to external events, such as from an existing framework

Dependency Inversion Principle

high level modules should not depend on low level modules; both should depend on abstractions.

Explicit Dependencies Principle

Methods and classes should explicitly require any collaborating objects they need in order to function correctly

Test models thoroughly, test everything else less

Model all state in an application

Create a structured representation of the system's state

Ensure UI components can be loaded separately from an application

Single-Responsibility Principle

Every module, class or function in a computer program should have responsibility over a single part of that program's functionality, and it should encapsulate that part

Try to delete the part or process.

Try to delete the feature or process to build things that are required.

Keep It Simple Stupid (KISS)

A simple solution is better than a complex one.

Musk requirement principle

Requirements belong to individuals, not teams

Murphy's law

Whatever can go wrong will go wrong. So a solution is better the fewer possibilities there are for something to go wrong.

Use default arguments instead of short circuiting or conditionals

Functions should do one thing

Don't add unneeded context

Don't add the class/object names to properties

Function names should say what they do