Slashdot Log In
The Pragmatic Programmer
from the learn-your-skills dept.
| 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
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
- A PRAGMATIC PHILOSOPHY
- A PRAGMATIC APPROACH
- THE BASIC TOOLS
- PRAGMATIC PARANOIA
- BEND OR BREAK
- WHILE YOU ARE CODING
- BEFORE THE PROJECT
- PRAGMATIC PROJECTS
- APPENDICES
Read this book! (Score:3)
The subtitle 'From Journeyman to Master' almost put me off of buying it (as I found it rather condescending), but after flipping through I decided the authors had enough to say to justify the purchase.
Much of the premise reads like a Design Patterns book, if you like Design Patterns, most of their material will jive with your thinking.
The rest revolves around scalability and maintainability of code, much like Jon Lakos's Large Scale Programming in C++. I just can't stress enough how well this book clicks with my thinking on large scale programming projects. Reading it was a continual series of 'Yeah, I do that' and 'Hey, thats a pretty good idea'.
The section on active and passive code generators is a worthy read, and its one of the few books which stress refactoring solutions, which do not bash the occasional one-shot quick-and-dirty hack in perl.
The section on tracer code vs. prototyping provides some good ways to manage expectation levels. (the 'ship the prototype' problem)
The section on orthogonality and Design by Contract contained some very good material on regression testing and controlling assumptions. Design by Contract introduced some ideas that I haven't seen expressed before in a programming text that are definitely worth reading.
All in all, I found this book a welcome addition to my bookshelf, which already contains a good amount of design and programming material for which I would not give this same endorsement.
You beat me to it! (Score:4)
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.
---