Slashdot Mirror
The Pragmatic Programmer
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
- 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
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
I didn't see the web site listed...
:)
It's at:
http://www.pragmaticprogrammer.com/
BTW, March 2000 Dr. Dobb's reviewed this book too...
I also reviewed this book (for the publisher)... it's great! It's the best practical book on becoming good at what you do that I've read.
Sorry about the AC post... my cookie is on my other machine!
Jared Richardson
jared@iRenaissance.com
http://www.iRenaissance.com
K&R is short for Brian W. Kernighan & Dennis M. Ritchie, and generally refers to their landmark work The C Programming Language, which was the definitive definition of C until ANSI got their hands on it, and is still a must read for C programmers.
----
----
Open mind, insert foot.
Does anyone know a good, English-language technical bookstore that is online in Europe (except for Amazon-UK)? I live in Spain, and the markup on English technical texts here is brutal (often double).
You could try www.bol.com (Books Online). They have it for 24.29 UKP. Hmm...just had a look through their Spanish Language version, and the book doesn't seem to be there....dunno what's up with that, cos it's on the UK one.
Oh yeah, the other thing is that they call it "The Pragmatic Program" but the ISBN number finds it OK. Hope this helps
dylan_-
--
Igor Presnyakov stole my hat
Hmm...just had a look through their Spanish Language version, and the book doesn't seem to be there....dunno what's up with that, cos it's on the UK one.
D'oh! Of course, I guess the Spanish version of the site has Spanish language books only.....anyone know any good books on Logical Thinking? :-)
dylan_-
--
Igor Presnyakov stole my hat
Book reviews that link to Book sites and make money from the links are nothing new or shocking.
my blog: good times, man, good times
"Real programmers"? Bah. Don't even get me started on THOSE idiots. Anyone who does their work the hard way BECAUSE it's the hard way is a fool or an amateur (there's nothing wrong with amateurs doing things the hard way... that's for fun!) "Real programmers" brought us those endless x86 assembly language hacks that made already-fragile DOS boxes virtually unusable. They're the guys whose code can't be read because they don't comment anything (much less write design docs...)
Scratch beneath the arrogant surface of a "real programmer" and you'll find someone committing virtually every sin listed in _The Pragmatic Programmer_.
---
Hand me that airplane glue and I'll tell you another story.
In this age of internet start-ups, you may well be correct. Software engineering, the practice of carefully and delibrately constructing the best possible system, could be dead. That doesn't mean that it should be.
Creating a program or an application that accomplishes its tasks, can be modified readily by other coders and is scalable/portable to other architectures is difficult. Just "coding more" belies the fundamental complexity of development.
One can learn a lot by reading. Many software tasks have been encountered before. Instead of wasting time on coding, try finding the solution in a book or a software library. Reinventing the wheel is wasteful.
Frankly, coding is boring. Designing systems is where the beauty of "programming" lies.
Some idiot may mark this as OT or flame or troll, but I would say you do have a point. The MSDos 4 tech reference used to hang around the bathroom at home for quite a while...
Baker's Law: Misery no longer loves company. Nowadays it insists on it
http://www.sigsegv.cx/
You need some intellectual shortcuts to make these decisions, you've got to evaluate reputations, based on things like other people's attempts at evangelism and your own attitudes, your previous experiences and the things that your familiar with already. This is what "ideology" is really about, in my opinion: not religon for religion's sake, but a set of shortcuts to speed decision making.
People like this do well in the short term, but really they're just blowing in the wind, and in the long run they don't matter much. They end up dancing to the strings of "impractical idealists" who refuse to compromise and because of that often end up shaping the world.
Frankly, coding is boring. Designing systems is where the beauty of "programming" lies.
Yeah! Wise words. This needs clarification, though. Coding to somebody else's spec is boring. However, designing systems without any coding is hard (if doable at all) and hardly recommended. My point is that a lot low- and mid-level design is done as-you-are-coding and at that level design and coding intermix.
My personal style tends to (1) Design on paper the framework and the overall structure; (2) Start coding from the bottom, revising the design as the program structure clicks in place; (3) Meet in the middle.
Kaa
Kaa
Kaa's Law: In any sufficiently large group of people most are idiots.
...a bathroom factor.
Basically, can you get anything out of the book during an ARV (Average Restroom Visit)?
--
then it comes to be that the soothing light at the end of your tunnel is just a freight train coming your way
Such a book can remind you of what you already know so that you actually use that knowledge.
--The basis of all love is respect
Must be one'a them Eiffel people.
Codin' ain't borin' if'n ya does it in a suitable language, like C++. Jest tryin' ta 'member all them funny rules 'n' exceptions is 'nuff to keep yerself charged up.
For the places where we must take into account the strains on the poor CPU, surround the code with skulls and crossbones and warnings that heavy magic lies within, and document the best you can. It's not unreasonable to take 20 lines of comments to explain 5 lines of heavy bit-twiddling magic.
Tom Swiss | the infamous tms | my blog
You cannot wash away blood with blood
I think that we need another book on software engineering. Or perhaps, more books that serve to make engineering software less voodoo and more science.
The idea of engineering software is important because as systems become larger and more complex, there needs to be some way to manage that complexity. Also, some problem domains require a more formal development process due to stringent performance requirements (e.g., life-critical systems). Would you be comfortable if someone "hacked" the controller software on a radiation therapy machine or perhaps the flight systems of the Space Shuttle? Software engineering is not just about programming, it's about designing, programming, and testing software systems. The whole ball of wax.
As for the idea that software engineering is dead, I disagree. It's still a very young discipline as compared to other engineering fields (Electrical, Mech, etc.). I think that there's a difference between software as art (and programmer as artist) and software as a science (and programmer as an engineer). And there's room in this world for both view points.
Many books leverage your experience. You read something and say "aha! This would have made that project go better!" or "I wish I'd realized that back then". Without the experience, you tend to think "Well, gee, why's that important?" and forget something really important.
To not read much is to think you can reinvent computer science yourself. You'll end up getting good at the few things you've figured out yourself, or from friends, but you'll miss a whole raft of neat tricks, great methods and just a whole bunch of other stuff that makes people good programmers.
I've had the misfortune of working on code written by "experienced" people who didn't like to read much. It isn't pretty.
The cake is a pie
I used to have a "Real programmers" quotes along the line of "Real men don't eat Quiche" that were quite amusing. Along the lines of "Real programmers don't use Pascal in an ide, they write assembly code with 'cat'".
Anyone who could point me to the original list would be thanked profusely.
But yeah, I agree.
The cake is a pie
Tip 1: To break the rules you must know them. It's much less fun to break rules you aren't aware off. And tell people when you broke the rules - if nobody's aware of you breaking rules, WTF are the rules for then?!
/.. You know, mainstream sucks, it's for Windows-programming morons only. Read out-of-print books like "Thinking Forth" (really a gem, no fun!).
Tip 2: Don't use other code - it's bad, since you are the master programmer, and the others are just morons, and you'd have to understand it to use it. You know: if you want it done right, you have to do it yourself.
Tip 3: Don't listen to customer, they are stupid morons, anyway. Write the program as you want to use it. Then brag about how c00l and 3l11t it is, then the customers will buy it anyway. If not, release it under GPL, and go IPO as new open source company.
Tip 4: Don't write comments into your programs. Your code is obvious. Since you assume the other people know about rule 2, they won't read your code anyway.
Tip 5: If you write comments to break rule 4, write them as fast as possible and with ltos of tyops, so that oepple kan now that you are busy duing codink.
Tip 6: Don't read mainstream best-seller coding practice books reviewed by
"If you want it done right, you have to do it yourself"
I'm about 3/4 the way through this book. And I'm enjoying it. But I don't think this book is a 9 out of 10. It is valuable because it clearly explains things we may already know, but may have difficulty explaining. For example, the helicopter analogy explaining orthogonality was outstanding.
On the other hand, this book isn't going to change the way I program. While "Pragmatic Programmer" is well written, and will be enjoyed by serious programmers, it is not in the same category as "Design Patterns" of Graham's "On Lisp". This book has good, common sense advice. You you're a serious programmer you might enjoy picking up the book and nodding along with it - but if your stack of books to read is as large as mine, skip this one. Your time is better spent learning something new rather than reinforcing what you already know. If you're just becoming serious about programming, then I'd recommend this book. I'd give it a 6/10 for this audience.
I learned a long time ago that not everyone likes the same things I do. And I learned to seek out sources for reviews that share my tastes and my needs. As a result of that, I have a copy of Refactoring: Improving the Design of Existing Code by Martin Fowler sitting in front of me. I bought it partly based on the review on Slashdot. I bought and read The Practice of Programmer by Kernighan and Pike in part because of this review. To those of you taking the time to post book reviews here, I offer my thanks. You are being read.
The net will not be what we demand, but what we make it. Build it well.
Real Software Engineers
Real Computer Scientists
These and many others can be found here.
And, to anyone who might know, the evolut ion of a programmer page has code that looks like LISP (senior year in high school). Is this so?
Also, will the code for the master programmer compile?
Here's my copy of DeCSS. Where's yours?
censorship is a form of noise, which actively seeks to drown out content with silence - Crash Culligan
Another good read in the same vein is Polya's How to solve it.
threadeds blog
Actually I think Kernighan and Plauger wrote "The Programming Elements of Style." This is not called K & R. That would be "The C Programming Language." Which is one of the greatest computer books written. Brilliant style and really nice typeset. Short, concise, no frilly bullshit, bullet points, shaded side bars with additional info. Just C, beautiful C.
Practice of programming is well worth checking out (Kernighan and Pike). Excellent book.
> Do we really need another book on software
> engineering. Its just a way for programmers to
> go on ego trips by talking about programming all
> the time, rather than doing it.
I wouldn't go as far as to say that really.
I am a programmer...most of the stuff I write
is for our internal use (tho some of it may soon
GPLd), mostly short programs to solve a problem.
The most I ever do is draw up a flow chart when
I am about to use a technique I havn't used before
However...I do think that "Software Engineering"
has its place. Some people work better that way.
Certainly for a very large project, something with
several programmers and a deadline...it makes alot
of sense.
> Technique gets too much focus, if you want to be
> a better coder just code more!
"Just code more" almosty sounds like a mantra.
-Steve
"I opened my eyes, and everything went dark again"
http://www1.fatbrain.com/asp/bookinfo/bookinfo.asp ?theisbn=020161622X&from=MJF138
has a "from=MJF138" suffix. That's not part of the information needed to order the book. Instead, it seems to indicate that the link is tied into that retailer's affiliate program, and somebody gets a 20% kickback on the transaction. This raises some serious questions. Who is MJF138, anyway? Heimos? VA Linux? Justin Harvey? Somebody else? The whole world wants to know.
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.
Sanity is a sandbox. I prefer the swings.
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.
---
Hand me that airplane glue and I'll tell you another story.