A year ago a good friend recommended me a great book called The Pragmatic Programmer. I then ordered it immediately, and a soon as it arrived home I read it cover to cover in a few hours. The book is really great, easy to read, not too technical (not that there is anything wrong with technical books), and full of good tips sprinkled throughout the book.
I immediately put this book next to my favorites. I highly recommend The Pragmatic Programmer to anyone who wants to become a better developer, in fact even if you're not a software developer you'll get something valuable from it. Anyway, I recently re-read this book, and I thought I'll post some of those tips mentioned in the book. There are 70 tips in total so instead of posting all 70 in one post, I'll break them down and post them in at least three blog entries. I hope they can help anyone looking for a quick online reference for these tips... at the very least they will help me :)
Pragmatic Programmer reference tips: 1 - 19
Preface
1. Care About Your Craft
Why spend your life developing software unless you care about doing it well?
2. Think About Your Work
Turn off the autopilot and take control. Constantly critique and appraise your work.
Chapter 1 - A Pragmatic Philosophy
3. Provide Opinions, Don't Make Lame Excuses
Instead of excuses, provide options. Don't say it can't be done: explain what can be
done.
4. Don't Live with Broken Windows
Fix bad designs, wrong decisions, and poor code when you see them.
5. 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.
6. Remember the Big Picture
Don't get so engrossed in the details that you forget to check what's happening
around you.
7. Make Quality a Requirements Issue
Involved your users in determining the project's real quality requirements.
8. Invest Regularly in Your Knowledge Portfolio
Make learning a habit.
9. 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.
10. 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.
Chapter 2 - A Pragmatic Approach
11. DRY–Don't Repeat Yourself:
Every piece of knowledge must have a single, unambiguous, authoritative representation
within a system.
12. Make It Easy to Reuse
If it's easy to reuse, people will. Create an environment that supports reuse.
13. Eliminate Effects Between Unrelated Things
Design components that are self-contained. independent, and have a single, well-defined
purpose.
14. 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.
15. 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.
16. Prototype to Learn
Prototyping is a learning experience. Its value lies not in the code you produce, but in
the lessons you learn.
17. Program Close to the Problem Domain
Design and code in your user's language.
18. Estimate to Avoid Surprises
Estimate before you start. You'll spot potential problems up front.
19. Iterate the Schedule with the Code
Use experience you gain as you implement to refine the project time scales.
No comments:
Post a Comment