100 Tips from The Pragmatic Programmers Book

https://dev.to/rajeshroyal/care-about-your-craft-pragmatic-programmer-series-1-3b84

1. Care About Your Craft.

Why spend your life developing software unless you care about doing it well? Why do you write software? Is it just a job, a means to an end, or is it something more? Do you take pride in your work, or do you just churn out code that barely works?

2. Think! About Your Work.

Turn off the autopilot and take control. Constantly critique and appraise your work. Do you ever find yourself writing code without thinking? Do you ever copy and paste solutions from the internet without understanding them? Do you ever follow instructions blindly without questioning them?

3. You Have Agency.

It’s your life. Grab a hold of it and make it what you want.

4. 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.

5. Don’t Live with Broken Windows.

Fix bad designs, wrong decisions, and poor code when you see them.

6. 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.

7. Remember the Big Picture

Don’t get so engrossed in the details that you forget to check what’s happening around you.

8. Make Quality a Requirements Issue.**

Involve your users in determining the project’s real quality requirements.

9. Invest Regularly in Your Knowledge Portfolio.

Learning is essential for programmers. Don’t stop at what you know. Explore new topics, skills, and technologies. Invest in your knowledge portfolio regularly. Make learning a habit.

10. 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.

11. English is Just Another Programming Language.

Treat English as Just Another Programming Language. Write documents as you would write code: honor the DRY principle, ETC, automation, and so on.

12. It’s Both What You Say and the Way You Say It.

There’s no point in having great ideas if you don’t communicate them effectively.

13. Build Documentation In, Don’t Bolt It On.

Documentation created separately from code is less likely to be correct and up to date.

14. Good Design Is Easier to Change Than Bad Design.

A thing is well designed if it adapts to the people who use it. For code, that means it must adapt by changing.

15. DRY—Don't Repeat Yourself.

Every piece of knowledge must have a single, unambiguous, authoritative representation within a system.

16. Make It Easy to Reuse.

If it’s easy to reuse, people will. Create an environment that supports reuse.

17. Eliminate Effects Between Unrelated Things.

Design components that are self-contained, independent, and have a single, well-defined purpose.

18. There Are No Final Decisions.

No decision is cast in stone. Instead, consider each as being written in the sand at the beach, and plan for change.

19. Forgo Following Fads.

Neal Ford says, “Yesterday’s Best Practice Becomes Tomorrow’s Antipattern.” Choose architectures based on fundamentals, not fashion.

20. 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.

31. Prototype to Learn.

Prototyping is a learning experience. Its value lies not in the code you produce, but in the lessons you learn.

32. Program Close to the Problem Domain.

Design and code in the language of the problem domain.

33. Estimate to Avoid Surprises.

Estimate before you start. You’ll spot potential problems up front.

34. Iterate the Schedule with the Code.

Use experience you gain as you implement to refine the project time scales.

35. Keep Knowledge in Plain Text.

Plain text won’t become obsolete. It helps leverage your work and simplifies debugging and testing.

36. Use the Power of Command Shells.

Use the shell when graphical user interfaces don’t cut it.

37. Achieve Editor Fluency.

An editor is your most important tool. Know how to make it do what you need, quickly and accurately.

38. Always Use Version Control.

Version control is a time machine for your work; you can go back.

39. Fix the Problem, Not the Blame.

It doesn’t really matter whether the bug is your fault or someone else’s—it is still your problem, and it still needs to be fixed.

40. Don’t Panic.

This is true for galactic hitchhikers and for developers.