DEV Community

Cover image for 100 Tips from The Pragmatic Programmers Book: Part 10/10
Rajesh Royal
Rajesh Royal

Posted on • Edited on

100 Tips from The Pragmatic Programmers Book: Part 10/10

10.1. Coding Ain’t Done ’Til All the Tests Run.

’Nuff said.

 

10.2. Use Saboteurs to Test Your Testing.

Introduce bugs on purpose in a separate copy of the source to verify that testing will catch them.

 

10.3. Test State Coverage, Not Code Coverage.

Identify and test significant program states. Testing just lines of code isn’t enough.

 

10.4. Find Bugs Once.

Once a human tester finds a bug, it should be the last time a human tester finds that bug. Automatic tests should check for it from then on.

 

10.5. Don't Use Manual Procedures.

A computer will execute the same instructions, in the same order, time after time.

 

10.6. Delight Users, Don’t Just Deliver Code.

Develop solutions that produce business value for your users and delight them every day.

 

10.7. Sign Your Work.

Artisans of an earlier age were proud to sign their work. You should be, too.
The author wants to say that programmers should be proud of their work and take responsibility for it. They should not be anonymous or hide behind a team name. They should put their name on the code they write and stand behind it.

 

10.8. First, Do No Harm.

Failure is inevitable. Make sure no one will suffer because of it.

The phrase means that doctors should avoid causing harm or suffering to their patients, even if they cannot help them.

The authors apply this principle to software development, and suggest that programmers should also strive to do no harm to their users, customers, colleagues, or codebase. They should not introduce bugs, degrade performance, compromise security, or violate privacy. They should also not make changes that are unnecessary, risky, or poorly tested.

The authors give some examples of how to practice this tip, such as using assertions, code reviews, testing, logging, and monitoring.

 

10.9. Don’t Enable Scumbags.

The authors define scumbags as people who use software for malicious, illegal, or unethical purposes, such as spamming, phishing, hacking, scamming, or exploiting2.

The authors advise programmers to not enable scumbags by writing code that can be easily abused, misused, or hacked. They also suggest to not work for companies or clients that support or profit from scumbag activities. They argue that programmers have a social responsibility to protect the users, customers, and society from harm, and to uphold the values of honesty, integrity, and professionalism2.

The authors give some examples of how to practice this tip, such as using encryption, authentication, authorization, validation, and verification.

 

10.10. It’s Your Life. Share it. Celebrate it. Build it. AND HAVE FUN!.

Enjoy this amazing life we have, and do great things.

 
Thanks for reading, happy coding 😀

Top comments (3)

Collapse
 
mrlinxed profile image
Mr. Linxed

Very good tips. Thank you

Collapse
 
arjuncodess profile image
Arjun Vijay Prakash

Congrats on the end of this helpful series, Rajesh!

I learned a lot from it.

Thanks!

Collapse
 
rajeshroyal profile image
Rajesh Royal

I'm glad to see you like it Arjun. Thanks for reading.