Provide Options, Don’t Make Lame Excuses: Instead of excuses, provide options. Don’t say it can’t be done; explain what can be done.

Be a Catalyst for Change: You can’t force change on people. Instead, show them how the future might be and help them participate in creating it.

Make Quality a Requirements Issue: Involve your users in determining the project’s real quality requirements. Critically Analyze What You Read and Hear Don’t be swayed by vendors, media hype, or dogma. Analyze information in terms of you and your project.

DRY—Don’t Repeat Yourself: Every piece of knowledge must have a single, unambiguous, authoritative representation within a system.

Eliminate Effects Between Unrelated Things: Design components that are self-contained, independent, and have a single, well-defined purpose.

Use Tracer Bullets to Find the Target: Tracer bullets let you home in on your target by trying things and seeing how close they land.

Program Close to the Problem Domain: Design and code in your user’s language.

Iterate the Schedule with the Code: Use experience you gain as you implement to refine the project time scales.

Use the Power of Command Shells: Use the shell when graphical user interfaces don’t cut it.

Please read part 2 of 7 part series inspired from the book Pragmatic Programmer here.