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
OOOOH! Calculus III???? Zowie, you must be SMART! One time I met a guy who passed Differential Equations!!!!! With an A!!!!!!!!!!!!! Wow!!
Damn, fresh out of moderator points. This one should be market "insighful".
The books aren't expected to make you "a better programmer, theoretically." Of course, you need to sit down and spew code through your fingers -- but having read an insightful book, your attention will (hopefully) pick up on things about your coding practice that you hadn't noticed before.
Ever hear of that Meyers-Briggs temperment index? That last dualtity (Judging vs. Perceiving) has a lot to do with this. The best programmers I know are the "P" types who make a conscious effort toward developing their "J" side. They're naturally creative because of being perceptive, but they constantly work on being more judgemental about their process in order to avoid making so many mistakes (remember, creativity is 99% perspiration, and 1% inspiration. This is the same as 99% failure, %1 success). Changing your viewpoint through reading a book can both increase your perception (you see things you would have missed before) as well as give you stronger heuristics for judging what you've been doing. I, personally, find that the mind-melding process you get from apprehending an someone elses perspective drastically increases the amount your capable of learning.
-NooM
I used to fear that this was true. Friends of mine would lament their lack of programming ability, and I'd say: "Look, experience is what made me a good programmer. Get experience, and you too can be a good programmer." But as I said these things, secretly I feared that maybe they weren't really true, that I was just fooling myself and trying to console my friends. So I was actually surprised and delighted when my friends got some experience, became good programmers, and proved me right.
Now if you'd said "great" programmers, I might be inclined to agree.
my new favorite book is the pragmatic grits-pourer, which, oddly enough, is all about pouring hot bowls of grits down your pants. thank you.
Funny thing, but people would like to look at software creation as a building/engennering, but few as i do prefer to look at it, more from writing standpoint. Few good lessons in writing as some of smart people I know say, would do better to a programmer, than whole year of engeneering and physics courses.
Go figure.
They put Slashdot on the top of the list for finding good content on the web.
Page 265 if you have the book.
Any time the designer(s) and the coder(s) are two distinct sets of people, you WILL have misinterpretations. Tight, constricting designs that are "thrown over the wall" to coders who are regarded as mere monkeys will result in very bored coders, and bad code.
The odds of a successful project go up drastically if the design and code is done by the same group of people. Thrashing things out in a meeting room seems boring to a lot of code hackers, but being able to have input into the design helps avoid misunderstandings, and transforms the results from being "their design" to be "_our_ design".
If your company separates the design and coding functions, I'd bet you have a lot of failed projects in your past.
(Moderation suggestion: +30065, Insightful)
Everyone can be taught to sculpt: Michelangelo would have had to be
taught how ___not to. So it is with the great programmers.
(Moderation suggestion: +27013, Insightful)
Time is an illusion; lunchtime, doubly so.
-- Ford Prefect
(Moderation suggestion: +27512, Insightful)
World War Three can be averted by adherence to a strictly enforced
dress code!
(Moderation suggestion: +6005, Insightful)
"He's not pining, he's passed on! This parrot won't squawk! He's
ceased to be! He's expired, and gone to meet his maker! It's a
stiff! No breath of life, he may rest in peace! If you hadn't nailed
him to the perch, he'd be pushing up the daisies! He's off the twig!
He's kicked the bucket! He's curled up his tooties! He's shuffled off
this mortal world! He's run down the curtain, and joined the bleed'n
Choir Invincible! HE'S FUCKING SNUFFED IT! Vis-a-vi his metabolic
processes is head is lost. All statements concerning this parrot is no
longer a going concern, after from now on, Inoperative...
THIS IS AN EX-PARROT!!
(Moderation suggestion: +6512, Insightful)
For every complex problem, there is a solution that is simple, neat,
and wrong.
-- H. L. Mencken
(Moderation suggestion: +6610, Insightful)
Chicago law prohibits eating in a place that is on fire.
(Moderation suggestion: +27423, Insightful)
Q: How many right-to-lifers does it take to change a light bulb?
A: Two. One to screw it in and one to say that light started when the
screwing began.
(Moderation suggestion: +1507, Insightful)
A can of ASPARAGUS, 73 pigeons, some LIVE ammo, and a FROZEN DAQUIRI!!
No..several of us actually have lives...and these creatures..called women. Real ones too...not just NP pics.
Guess who just orderd it online =) Im looking forward for in dumping down in my postbox.
Guess who gets the kickback from Fatbrain? I noticed there's an "associates'" kickback parameter on the link to buy the book. Hmmm....
Umm... I have a problem with this 'reinventing the wheel is wasteful' concept. I believe people fall into a trap where they feel they've done something before and must reuse what they did. I rarely come across something I believe I couldn't do better the 2nd, 3rd, or 4th time around. Sure, don't rewrite -everything-, but most of it. You get your practice, you get faster at coding, and better. Reading about ways to design programs in one thing. Trying a lot of them out is another. This also makes a lot more sense when you consider that on the next job when you need something that you did in the last... Usually that last bit of code is someone else's IP now.
;)
I started on examples, but it all sounded like an ego trip... I'll just leave it at this.
How does this compare to Code Complete by Steve McConnell? It sounds like some of the topics are covered in that book as well.
"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). I think that software engineering is very much alive! I recommend a book, called Object Lifecycles: Modeling the World in states. It brings rigor and robustiness to the whole requirements analysis process and describes how one can describe and model an application, using a powerful, yet simple, methodology. The book is by Sally Shlaer and Steven Mellor of Project Technologies. Go to http://www.projtech.com for more information. Many people who know the Shlaer-Mellor method and the Booch/Yourdon, etc. method, prefer the Shlaer-Mellor method. It's simpler, disciplined, and rigorous. One needs these qualities to achieve correctness in a program. The methodology also targets real-time systems and supports UML syntax, too. Some of the tools even enable you to simulate your application without ever writing a single piece of code. Unfortunately, the tools have been historically very expensive, which is a shame, because, once again, we have the ubiquitous (Rationale) winning out over the superior (Shlaer-Mellor). bbigby@rochester.rr.com
K&R stands for Kernighan and Ritchie, and refers to the book "The C Programming Language" that they wrote; which (as the title suggests) describes the C language. It also shows a lot of good programming styles/technics (and a few horrible ones IMHO), although that isn't the focus of the book.
Uhh, how would you rate Knuth's Art of Computer Programming series? I don't know about you, but I certainly can't get anything out of his dense tombs in a bathroom visit. The dense math and obscure MIX combine to make something hard to grok. The books require patience and dedication in reading. It's ARV (on a scale of 1 to 10) would be a 0. But, I would consider its value to be a 10 (to those who can understand it).
Yes! This is the book that I recommend to everyone, including my students in my teaching days. Funny thing is, everybody seems to get stuck on the fact that Polya uses math to illustrate his method - people seem to get too caught up in the appearance.
(Reminds me of the story of the Zen master who took his students outside and told them that he was giving them their final test - if they failed, they were out. He took them to the top of a hill, sat them around him, and pointed. He then failed every student who was staring at his finger.)
This also relates to a question I've had for a long time - can you teach someone how to analyze a problem? This has implications for a lot of software development projects - bad analysis = a poor product. I'm beginning to think that good analysis abilities are like good painting talent - born, not made.
Kernighan & Ritchie: The C programming language. (aka. the Bible) VERY worthwhile, if you do C stuff. It's not a 1200-page monster. It's really to-the point, clear, precise and no bullshit. I love that book.
Tip 1: Work out the entire program in your head first! If you can't run in it your head, then it's probably too complex and will contain bugs! A side effect of this is that you'll do a lot less typing, and so you won't get carpal tunnel syndrome.
Tip 2: Steal other people's code (if it's good)
Tip 3: Dump your new alpha machine and get an old 486 instead. This will force you to be more creative in solving problems than just throwing more metal at the problem. Don't try this tip until you've mastered #1, or else you're waste a lot of time compiling buggy programs!
Tip 4: Read slashdot, and buy all the books they review. Throw away the books that aren't listed on slashdot (they might corrupt your mind).
Tip 5: Have fun! You only live once, so try to make the best of it. Marry some girl that will give you head while you code, so you can be relaxed at all times. If you're not getting any, your code will probably be crap!
Tip 6: Join the slashdot troll coalition!
Experience is the best teacher, but unfortunately, it seems like people don't have the time to make mistakes on their own nowadays and have to be spoon fed in the name of efficiency.
Until it ran out, right ?
IMO, this book is a 9/10 as measured by the ARV parameter. Like a lot of good general programming help books, it's broken up into a number of tips that are explained in detail over a few pages (sometimes more). They also include a pull-out reference card with the tips ordered as in the book and a page of general guidelines.
This is a really useful book, particularly because the "right tool for the right job" is not just a tip, its philosophy is threaded throughout the entire book. I expect to be reading it off-and-on for quite some time.
Chris
M-x auto-bs-mode
Hey, that's me!
Thanks, I read a lot of these books (like Justin) and like to share what I've learned. I'm always glad to hear it is helping others.
--
--
Marc A. Lepage
Software Developer
I've been working for four years as a software developer. I started reading all these books when I got out of school, not while I was in school, when I was still busy reading text books.
In my opinion, you get more out of these programming books when you are working as a programmer, so you can allow your experience and reading to feed back on each other and achieve a synthesis of theory and practice.
--
--
Marc A. Lepage
Software Developer
2."Pragmatism" is sometimes a code word for "I have no values, morals or ethics ". I just do "whatever works" and I don't worry about any kind of idealistic consistency. 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.
Seems to me what you're criticizing is an excessively short-term view of the world, not pragmatism itself. Looking only at the short term is a killer no matter what your philosophy of life.
-Mars
Yeah! That's the way to do it: code like hell. Coding like hell seems to work best in a large team environment with every "team" member programming in their own direction and not talking to anybody else. That's sound software engineering practice. That will lead to a successful product.
A tab on Unix is eight characters. So four tabs is overdoing it a little. (I use eight-character indents for C, four characters for Perl, following the example of the languages' creators.)
-- Ed Avis ed@membled.com
K&R is Brian W. Kernighan and Dennis M. Ritchie. They are the ones who wrote the only book I (and probably you) will ever need on C: The C Programming Language, as they are the ones who created the language.
They also did lots of development on Unix in the early days, if I recall correctly.
Woz
gzw@home.com
I'm teaching in the university and I learned, that ;)
:)
whatever you tell people or whatever you show them
not to do - they won't believe you unless they
programmed a half year and made all these errors
before you show them the solutions.
And with these solutions it's like with every
good advise - they won't believe you or they'll
say "well, that is just nitpicking"
Sure, some good practical tips are neat, but
it starts with indenting and naming. Some people
say indenting the one and only way makes programs
more readable - sure, two tabs are better than no
tabs and perhaps four tabs are even better than
two. But it still doesn't get better unless you
also program readable.
What teaches good programming is programming on the run after coming back from a party and having
to read it the morning after - That's my tip!
A little off topic, but I would like to buy this book. 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).
Any help appreciated...
"Well it's not Victory - but then it's not Death either."
Uhh.. so what?
I don't really shine in math.. but I'm really rather good at writing. I'm also a pretty decent programmer (compared to who I'm around I suppose).
Programming is odd in that it isn't really related to anything else. People who are "born with the gift" are really just people who know how to think in a structured manner. That is one of the keys to clean, fast, working code. If you can see the problem, and the solution, in your head, you're much more likely to code a clean, efficient, and maybe even clever way to solve it. Maybe one dosen't code in a coherent manner (jumping from thought to thought, here to there) but.. that dosen't mean it's unstructured.
- Paradox
Man of the C!!!
Slashdot. It's Not For Common Sense
I pass large structures by value (multiple times), I make the code jump around a lot (losing any points for locality), etc. etc. (think that's so unreasonable? You should have seen my comp-sci major friends! Their code had a complete disregard for the processor underneath)
Jumping around, depending on what the jumping is used for can be good, if you mean making code more modular. Abstraction is the name of the game; copying code just copies errors, and right now, too many people copy code. I'd say a lot of people (myself included) could benefit from a healthy smack over the head with some software engineering principles.
Design is critical in creating code. If you don't take the time to design your code with some sort of inherent architecture, whether OOP, functional, or imperative, all you're going to get is one big, ugly hack. Have you taken a look at slashcode? There is one gigantic module with one function aptly named the Beast with some other functions in various files to handle various jobs. I find it very difficult to read, and if it is any indication of the code that "coding for hours w/o software engineering" produces, I think I can safely rest my case.
At its core, programming, whether you like it or not, is about math. At the systems level, you have to consider the processor carefully. At the applications level, you shouldn't have to worry much about the processor - the systems level code should worry about that for you. What I'm trying to say is, no, you can't completely disregard the processor, but you should be able to disregard a lot of it if you are developing user applications.
In this new era of internet start-ups, the code that is produced may become crufty because of the incessant and unreasonable demands of management. However, you should take the time to realize that properly designed code will require less future maintenance and fewer headaches for you, the coder. Argue with your boss if you have to. A year of uptime is worth a week of delay.
- Y
"There is no culture in computer science, only cults." - M. Felleisen
Software engineering is far from dead. If it were, people would stop refining on UML. Granted, for small projects, object orientedness may not be needed, but when the scope begins to get large and you users include more than yourself, you have to ensure your system will work. That takes engineering, not code hacking. For a large system, most of the time will be spent in requirements and design. Coding should be done by a monkey because the design should fill in almost all the blanks to restrict the programmers freedom to be creative. (Oh let the flame war begin). But when your design is locked down to restrict coding freedom, there is less room for misinterpretation. And any misinterpretations between the designer and coder will yield a one off implementation which will work in most cases, but in the excpetion cases, your life becomes a nightmare of support.
Assuming that you are seriously asking, K&R is a reference to
The C Programming Language by Brain Kernighan & Dennis Ritchie.
The above is an Amazon link, if you don't like them then look in the computer section of another bookshop.
Donte Alistair Anderson Roberts - hi son!
Karma: Chameleon
I really do think there are too many books that teach you how to program using a specific language and often don't concentrait enough on why you would choose one algorithm over another, or how to make your code clean and readable. I learned a hell of a lot more in my "programming language concepts" class than I did in the first two "intro to programming" classes, which by the way everyone in the school calls them "C++," which totally agrivates me due to the fact that they should be learning how to program and not the specifics of a language like that. It is the little time savers and the methodologies that go along with programming that help the job go smoothly, not the fact that you hacked up some code that finally works in such a short period of time. That my friends produces bad code which has no thought behind it.
_joshua_
> during an ARV (Average Restroom Visit)
We just got the new Jargon File yesterday, and here we've got a new term that isn't in it. Expect 4.2.1 any day now!
--
Sheesh, evil *and* a jerk. -- Jade
Although this book is not a life-changer (ala GoF or Mr. Becks XP book). It still is a good read. It had me feeling pretty guilty about the many holes in my background (I never did learn how to use yacc/lex). One of the best parts of the book is the 'Resources' appendix. This resource list is a good start at defining the 'Programmer's Canon', the required reading for all in our profession. This list includes off-line as well as online resources ranging from the ACM journals to slashdot.
This book inspires me to keep honing my craft and then tells me how to do it.
No, coding is not boring. Maybe its just me, but I get hard everytime I do a :wq gcc etc...
For the obligatory newbie question:
What is the K&R referred to in this article? How worthwhile a book is it?
Thanks...
Ink
True enough. But one of the best things about the book is the resources section at the end, giving pointers on where to learn more when you need to. Also, this book serves as a good intellectual shortcut -- it gives short descriptions of lots of different approaches and techniques (XP, Test First Design, prototypes vs. tracer bullets, etc.), so you can pick the approach that makes the most sense for you and then go to the resources section for more info.
The title put me off a little also. But the book really does have some core beliefs about programming. It says that programming is a noble craft worth learning well, that clarity, simplicity and flexibility are important.
--
Steve Molitor
smolitor@erac.com
"Emacs is the Computer"
Stephen Molitor steve_molitor@yahoo.com
If programming standards have dropped it's probably due to powerful computers and "Visual" type programming languages e.g. VBasic, rather than programmers reading too many books. It's amazing how much crap goes unnoticed nowadays, like graphics that needlessly redraw themselves multiple times, or inefficient coded mathematical processes gobbling up CPU time, that would have been obvious on an early Apple or PC.
And, to anyone who might know, the evolution of a programmer page has code that looks like LISP (senior year in high school). Is this so?
If you mean college senior, yes, that's lisp.
Also, will the code for the master programmer compile?
That's Windows COM code, some IDL, some C++. I suspect yes, though like anything COM, it'd take a while to get things set up right. I'm not about to try!
The cake is a pie
Unfortunately, people get wedded to existing code. People tend to underestimate the time it will take to fix buggy, unmaintainable code and overestimate how long it will take to rewrite code. Getting in the habit of throwing stuff out, and rewriting is a very good thing, IMO.
The cake is a pie
Real programmers use "ex". (or, under Micro$oft stuff, "edlin".)
The cake is a pie
1)I think the point is that we all have a professional toolkit that we use but books like this can help learn new mental models rather than just another set of stupid editor tricks.
2)Pragmatism is actually based on the idea that results, rather than idealistic consistency is moral, ethical, and has value. See 'C', and 'PERL' as opposed to 'Ada' and 'PL/1' for computer science examples.
-c
> Its just a way for programmers to go on ego trips by talking about programming all the time, rather than doing it.
By the at logic, doctors shouldn't know nomenclature of the human anatomy. Yeah, right.
When I talk to another programmer I want to be able to express ideas clearly, not spending 20 minutes detailing the intricate structure of an algorithm. Design Patterns are one way to do that.
You are correct. They are not a "silver bullet" They just help in managing the complexity of software development.
> This is just like those people who insist on an object structure when one really isn't necessary
Can you show an example of this?
Cheers
I'm a fourth year computer science student, I've worked in industry. I have to say that I found this book to be very useful. It is worth purchasing just for the section on Meyer's DBC (Design by Contract) ref OO Software Construction. I did however find that in conjuction with probably Code Complete over The Practice of Programmer that you get a rounded view of programming (not software engineering, just good programming practices). A visit to the website, www.pragmaticprogrammer.com is highly recommend as the resource section has a list of freeware tools and utilites that I as a student found excellant.
That's my two cents
The # 1 change that I have seen in the practice of programming (so to speak) over the last couple of years is not due to Linux's ascent or the adoption of Java (although both are great), but the difference in design and coding due to the GoF book - Design Patterns.
A little before that 'Code Complete' rocked. While most cannot match this level of importance, it is important that they try. Most fiction does not touch Doestoyevsky, but people should still write and read lesser works.
Books can lead to better code!
Also down here in the City there's lots of people who think they can program in Java after having read a book, but have no experience at all. The clients seem to be happy.
threadeds blog
This is exactly like the perl vs. python debates. People who think coding is engineering favor python. They want a large and structured language where they can talk about larger and larger concepts more efficiently. The example is object oriented lanuages like C++ that brought structure to another level. Soon there will be another generation of languages, probably based around design patterns, kind of like a meta-object language. However, if you're a perl type who considers coding an art form, you believe in small and versatile languages that can express things in multiple ways. This takes more of the approach of mapping the language to the problem space. I personally code far better the perl way. Although it may be called sloppy by computer science types it really is the quickest and most natural way to solve a coding problem, rather than building sealed off layers of code that an engineer just places together like interchangable parts.
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. This is just like those people who insist on an object structure when one really isn't necessary. Technique gets too much focus, if you want to be a better coder just code more!
Gotta agree with you there.
I think a lot of it has to do with today's Instant Gratification Syndrome -- people want to a magic formula or a miracle book that teaches them how to program in 30 days, and then they want to write world-changing programs and get their pay-cheque immediately, etc., etc.. Few actually spend the time to really learn the art of programming.
And because of this "I don't have time to spend experimenting around, tell me everything!" attitude, a lot of people just don't "get" the principles of good programming. These are principles earned through hard experiences, but to people who have never actually done a lot of real programming before, they don't realize the value of these principles and usually just say, Well these are just theoretical rules which are so absurdly nit-picky, I'll just take the liberties and do it my way. But they don't realize that it's because of attitudes like this, a lot of software nowadays are very poorly designed, very poorly implemented, and very buggy. I'm not just referring to "commercial" software which the Slashdot crowd religiously hates, but a lot of open source projects headed by inexperienced people suffer from the same problem too. Although the good part about open source is, these people get a lot of experience out of the project and at least learn more good programming practices than a lot of hired programmers ever bother to.
Well, I think I'm slowly veering off-topic, so I'll stop now. :-)
mikre he sophia he tou Mikrosophou.
Now if you'd said "great" programmers, I might be inclined to agree.
i hearby ammend my earlier comment to "great", as it is indeed closer to my true meaning.
and, if you ask me, the best thing about the whole concept is that it means that there are legions of great programmers out there who just haven't gotten around to writing code!
not that there's anything wrong with that. it's almost kind of a romantic notion that there are legions of the world's best programmers out there playing in the sun, away from keyboards, monitors, and circuitry.
haY
but, one question for you!
your whole posts just oozes the "but i already knew that" vibe that's what bothers me most about the book. sure, maybe it's a "welcome addition" to your bookshelf, but, is it going to do anything other than just sit on that shelf & gather dust, while you look up every once in a while for a moment of "yes, that's the book that has in it everything that i know!"?
i mean, isn't that kind of pointless? you're better off sinking your money into LinuxOne stock, because then there's at least a chance that it will actually end up worth more than zero cents.
what i don't get is why so many people who've read this book love it. there are some interesting parts, and i guess it's all fine & dandy to have people spend an entire page (84) telling me why i shouldn't use windows notepad to write my code,
but, uh,
isn't that kind of obvious? i think it's an okay book, especially for people who can't already program, but it's also a mistake for an experienced programmer to just rush off and order it on-line sight-unseen, because i think a lot of you might have the same "duh?" reaction that i did to a lot of the material.
it all ties into the basic fact that good programmers aren't taught, they're born.
giggle.
Readers Digest has the best Bathroom factor in any publication ive read. I can burn through about one article per sitting.. Right before your legs start feeling numb.
lol, well im certainly not a 'good programmer' ;p my HS counselors said I would never get much past HS Algebra (BITE me ive passed CalcIII at Ga Tech!) Hehe. So anything can be learned I think. Art, Writing.. all of it you trian a monkey well enuff he can do it.
It has very little to do with intelligence and everything to do with a personal accomplishment for ME.. Bleh I doubt im very smart at all.. :-)
My favourite quote:-
"Learn from other people's mistakes - you won't have time to make them all yourself."
As Len Hutton likes to point out in his books, software engineering is (or has been) a very immature discipline. The sign of a mature discipline is that there are known good ways of doing things, and ppl can be taught these ways and why we use them. Now these kind of books are great for that, bcos it gives some idea of best practice. Sure, some ppl won't pay attention to one bit, and they'll go away and get bitten by the problem, and they'll be wiser for it. But generally ppl will think "Hey, that's a neat idea" and stick with it.
But to suggest that ppl have to basically be left to get on with it without any instruction in the best way to go about things is odd. Granted, most of us learned programming at an early age on Commodores, Acorns and Spectrums, and we picked it up as we went along. But there's no need to force other ppl to do that as some kind of initiation rite.
As an analogy, the first pilots built experimental planes and learnt to fly them by trial and error. Some of them went on to become very good pilots, but most of them crashed and burned. Nowadays, pilots go through vast quantities of training, and things are much safer for that. You see, it's not just efficiency you get from showing people the best way to do things - you get better output too. The umptitum thousand bugs in every Microsoft product show you what happens when you let things slide. Please don't tell me you want that to be the model for modern software engineering!
GraB.
I find the number one culprit behind most crappy code is an inability to really understand the problem at hand. Most programmers still rush to code before they know what they are trying to solve. I see this as slightly different that requirements analysis, which focuses more on what the customer wants than the subtle dimensions of the problem itself.
2. Go to conferences and geek cruises at the expense of the employer. That way you get the contacts with people at or about your level (noone in your company is at your level). Then if you get stuck, you can get the answer from the people you meet.
3. Be really rude and nasty. Then people won't bother you with really stupid questions.ie. "I have a stupid questions for you." The proper response, is "if it is a stupid question, why are you asking."
4. When solving a problem, make it look very easy.
5. Pull some all nighters. Nothing impresses the boss like working 40 hours straight.
Fight Spammers!
Thanks for taking the time to read them dsplat. :)
Sorry Frank :) I really enjoyed reading (and reviewing) the book. I only wish more people didn't think software engineering was dead. I strongly disagree with the posts by "that crowd" in this message area.
Justin
I can say it's not me, it was postfixed to the article after I sent it in by Slashdot. Support /.
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
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.
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.
...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.
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
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
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.