The Pragmatic Programmer

Justin Harvey has written a review of The Pragmatic Programmer, a work famous for helping programmers develop their skills. Click below to learn more. The Pragmatic Programmer author Hunt, Andrew / Thomas, David pages 320 publisher Addison-Wesley, 10/1999 rating 9/10 reviewer Justin Harvey ISBN 0-201-61622-X summary This book describes how to be an efficient and productive programmer. The Scenario

The Pragmatic Programmer is a great view into what it takes to be a master at software engineering in this day and age. While the book has code examples in C, C++ and Java, if your primary language happens to be another, don't count this book out. You'll find it equally beneficial because the authors really focus on the core skills and methods of software engineering. This book is the K&R for methodology.

What's Bad?

TPP covers a lot about what we programmers love to hate: process, planning, documentation and requirements. However, don't skip over these parts. While we'd rather be reading about the different methods of code reuse or prototyping, it is important to take the time (and concentration) to read through these sections because they are integral to becoming a master at software development. Truthfully, the only bad thing about this book is that it has a very soft cover, it's too floppy for my taste.

What's Good?

If you're expecting this to be another Practice of Programming (Kernighan, Pike) you're in for a surprise. The book does have code examples, but it's just not about indenting or variable naming, it's about coding principles, methodology, philosophy, communication and practices.

Contrary to how it may sound, the book is actually very enjoyable to read and is full of interesting quotes, jokes and anecdotes. It is far from a dry, boring textbook.

So What's In It For Me?

If you do development in any language, this book is for you. Whether you're just starting out trying your hand at Java or are a Perl guru, there is always something more to learn. This book really stresses professional growth and suggests taking a different look at the way you're doing development today. If you can absorb 10% of this book, your work and code will improve. Following the tips and advice in this book will earn you the respect (or at least a tip of the hat) from fellow programmers as well as improve the relationships you have with vendors, product managers and management.

Not just for journeymen.... So you're an experienced programmer with 20 years under your belt and you think you know all there is to know about software engineering. Pick up this book and you'll find at least one helpful insight or process which will change your outlook on the way you do business. That's one of the great things about this book, whether you're a journeyman or a master, you'll discover something new. A plethora of idioms, catch phrases and buzzwords. The book has a lot of idioms, catch phrases and buzzwords that you might have heard from a team member and wondered what the hell they're talking about. The authors spend a good amount of time carefully explaining each of these concepts and how it relates to our coding. Here are just a few, let's see how many you know:

• Orthogonal
• Decoupling (Temporal and Modular)
• Laws of Demeter
• Design By Contract
• Metaprogramming
• Tracer Bullets Programs

Read the book, pick up a few of these phrases and impress your team members while confusing script kiddies. X is better than Y We've heard it a thousand times, X is better than Y. If it's not emacs is better than vi, it's C vs C++ or it's Linux vs Microsoft. I like this book because it's very programming language and operating system agnostic. TPP does have examples in different languages but it goes far beyond choosing a side, it has a more practical view of "right tool, for the right job". Not only do they try to emphasize the right tool, but also looking at the way you're programming today in a different light. They suggest things like: if you're a UNIX geek with your editor and makefiles, try using an IDE. If you're a Windows programmer, try using a UNIX machine or command line interface to the tools. They go more in depth suggesting various strategies encouraging growth. Humor Value And last, but not least, the book has a lot of funny quotes from famous people, stories of foolish and funny programming errors, and amusing tip boxes sprinkled throughout each chapter. Some of my favorites tips from the book

• Tip #11: Don't Repeat Yourself (DRY)
• Every piece of knowledge must have a single, unambiguous, authoritative representation within a system.

• Tip #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.

• Tip #20: Keep Knowledge in Plain Text
• Plain text won't become obsolete. It helps leverage your work and simplifies debugging and test.

This one isn't a tip, but it has a whole section devoted to it: The Law of Demeter for Functions:

An object's method should call only methods belonging to:

• Itself
• Objects it creates
• Component Objets

In closing

I read a lot of software engineering books, both technical and about methodology, and I would recommend this book to be on every programmer's shelf, right next to the K&R, and Practice of Programming. I hope you enjoy it as much as I have.

justharv jbharvey@foobarbaz.com

Purchase this book at fatbrain.

Table of Contents

1. A PRAGMATIC PHILOSOPHY
2. A PRAGMATIC APPROACH
3. THE BASIC TOOLS
4. PRAGMATIC PARANOIA
5. BEND OR BREAK
6. WHILE YOU ARE CODING
7. BEFORE THE PROJECT
8. PRAGMATIC PROJECTS
9. APPENDICES

Comments

You beat me to it!

[Frank Sullivan]

And here i had a 3/4-finished Slashdot review of this book going...

Anyway, here's my take on it: if you don't think you will learn anything from this book, or don't think you have time to read it, you are NOT a Pragmatic Programmer. You're probably "coding by coincidence", or perhaps about to be a "boiled frog". Pragmatic programmers know there is always something new to learn, and go looking for it.

This is an eminently *practical* book. It's not some dry treatise on software engineering theory - certainly, it doesn't suffer from the OneTrueWayism of so many academic approaches to writing better software.

Their agnosticism on many divisive issues (such as the best editor) comes from the pragmatic approach. It is pragmatic to learn a high-powered programmer's text editor like vi, Emacs, etc (Notepad is NOT sufficient). It is NOT pragmatic to debate which one is "better". It's a matter of taste. What's more important is mastering the editor you do know. Similarly, they recommend mastering a powerful scripting language, but don't care if it's Perl or Python or whatever. Although they didn't address methodologies much, i'm sure they would suggest learning one solid methodology (patterns, UML, whatever) and mastering it.

The chapter on "Ruthless testing" is especially valuable for most programmers, who generally vary from weak to pathetic when it comes to testing. Rather than just saying "testing is good", they make concrete suggestions. For example, a bug should only be caught by human manual tests *once*... not because the bug should be permanently fixed (this isn't true in practice, no matter how confident programmers are), but because after it is caught once by hand, it should be caught the next time by your automated test suite. You DO have automated tests for your software, don't you? No? Why not? Do you believe your code is bug-free? Are you afraid of what you might find out? I know i am sometimes. Or maybe you're too busy coding new stuff to make sure the old stuff works.

I'll probably go on with more later, but i want to post this now.

Oh, and it *is* a good bathroom book, with chapters and sections of just the right length. Its main weakness as a bathroom book is that you won't want to put it down. :}
---