Blog‎ > ‎

"The Pragmatic programmer" review

posted Apr 3, 2012, 3:49 PM by Unknown user   [ updated Apr 3, 2012, 3:51 PM ]


"The Pragmatic programmer" review by Basilio German


    "The Pragmatic Programmer" is a book which is usually included in the recommended readings for a software developer. The book, released in 1999, is structured as a series short 46 sections. Each section has challenges and even some exercises. It touches on design concepts such as orthogonality, decoupling, Domain Specific Languages, Design By Contract, Metaprogramming, and Refactoring. it has pages on process topics like build automation, “design to test”, test automation, estimation, and collecting software requirements.


But this book is really special because it shows you how to become a better programmer and to take pride from it. It states that the pragmatic programmer is a continuous learner. We must think critically about what we read and hear, and know how to communicate. The book explains how you can build these qualities.


"The Pragmatic Programmer" is easily one of the best books on software development I have ever read. It has really inspired me to continue my journey to become a better programmer.

I'm really sorry I didn't read this book when it came out several years ago. Even though I'm already doing about 80% of all the stuff in this book, the other 20% would have made a major difference in my work over the last years. I’m just glad I’m on the right track on being a better programmer.


Even with that, it's always good to reaffirm some of your good habits, and keep your bad ones in check. The book also has 70 different tips that are generally useful to any programmer.

As with most things some tips have more or less value than others, but the ones that really stick out and probably can't be emphasized enough are:


Care about your craft

Why spend your life developing software unless you care about doing it well?

 

Don't live with broken windows

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


Invest regularly on your knowledge portfolio

Make learning a habit.


DRY - Don't repeat yourself

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


Make it easy to reuse

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


Prototype to learn

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


Don't panic when debugging

Take a deep breath and THINK About what could be causing the bug.


"Select" Isn't broken

It is rare to find a bug in the OS or the compiler, or even a third-party product or library. The bug is most likely in the application.


Crash early

A dead program normally does a lot less damage than a crippled one.


Don't program by coincidence

Rely only on reliable things. Beware of accidental complexity, and don't confuse a happy coincidence with a purposeful plan.


Design to test

Start thinking about testing before you write a line of code.


Some things are better done than described

Don't fall into the specification spiral, at some point you need to start coding.


Don't be a slave to formal methods

Don't blindly adopt any technique without putting it into the context of your development practices and capabilities.


Don't use manual procedures

A shell script or batch file will execute the same instructions, in the same order, time after time.


Coding Ain't Done 'Til All the Tests Run

'Nuff said.


Test state coverage, not code coverage

Identify and test significant program states. Just testing lines of code isn't enough.


Test early. Test often. Test automatically

Tests that run with every build are much more effective than test plans that sit on a shelf.


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.


All in all, this is a great book and a must read for all programmers, it has great practices and exercises that all programmers should know and use in their programming.







Comments