Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 


Forgot your password?
Close
typodupeerror
×
Programming Books Media Book Reviews IT Technology

The Pragmatic Programmer 115

Posted by Hemos from the learn-your-skills dept.
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
This discussion has been archived. No new comments can be posted.

The Pragmatic Programmer More

The Pragmatic Programmer

Comments Filter:

  • How to become a master programmer (Score:1)

    by Anonymous Coward
    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!

  • More like good programmers have been around the block a couple of times and have been burned by past screw-ups and now know better.

    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.

  • Re:Something to add to the book reviews... (Score:1)

    by Anonymous Coward
    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.

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

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

    --

  • 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.
  • two tabs are better than no tabs and perhaps four tabs are even better than two

    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.)

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

  • 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!!!
  • 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
  • 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 [amazon.com] 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.
  • 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!

    --
  • 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.
  • Credit where credit is due, just in case ESR is lurking.

    I remember ARV coming from the movie Revenge of the Nerds, when the two main nerds (Anthony Edwars and the Other Guy) were in the riding in the car to go to college. They were calculating their ETA based on speed and two ARVs.
    --
  • GoF?
    Please expand.

    Molly.
  • Thanks. I feel a little bit silly because Design Patterns is open on my desk as I write this. :-) I agree that it's an excellent book. I just think of it as "DP" rather than "GoF".

    Molly.
  • 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
  • doom writes:

    1. Time is limited.
    You need some intellectual shortcuts to make these decisions.

    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.

    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.

    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"

  • 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.
  • Thanks!

    And, to anyone who might know, the evolution of a programmer [geocities.com] 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!

  • Personally, I think the problem isn't so much the rushing in as it is the refusal to admit that something isn't working. Personally, I like rushing to code. Spitting code out is a great way to find all the flaws in your assumptions. But in order to do this right, you have to realize that you are probably not writing production code. Throw some stuff out there, then pull back and delete everything that is crap (which will be nearly everything.) Then you know all of the issues and can create something really elegant. I've found bad assumptions in a half hour of coding that were missed in days, or even weeks, of design.

    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.

  • (Notepad is NOT sufficient).

    Real programmers use "ex". (or, under Micro$oft stuff, "edlin".)

  • 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!
  • GoF == "Gang of Four" (Gamma, Helm, Johnson, Vlissides) the authors of "Design Patterns"

  • I agree in principle, but, when I learnt to program it was impossible to do so after a party as I was too full up on cake and jelly.

    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.

  • Actually I think Kernighan and Plauger wrote "The Elements of Programming 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.
  • The WHO is Kerningham and Richie (spelling?) They invented two little things you may have heard of - C and Unix. The wrote a book called (If I remember right) "The Programming Elements of Style" (The book's at work, and I'm at home ) It's just calles the K&R for short.
  • > The WHO is Kerningham and Richie (spelling?)
    > They invented two little things you may have
    > heard of - C and Unix.

    Actually Ken Thompson is the father of Unix.
    If memory serves Thompson and Richie (T&R)
    worked together on version 2 of the Kernel
    which was written in K&R C

    just a little trivia really.

    > The wrote a book called (If I remember right)
    > "The Programming Elements of Style" (The book's
    > at work, and I'm at home ) It's just calles the
    > K&R for short.

    Interesting...I don't have that book...I would
    generally associate K&R with pre-ansi C or the
    book I DO have "The C Programming Language" of
    course...thats generally refered to as the Old
    Testiment (yes I have the first edition)

    -Steve
  • Kernigan and Ritchie invented a lot of things which are now to be considered as standard C (not C++). Usually this applies for the include files like stdio.h, stdlib.h etc.

    Most C compilers will claim K&R compliancy, this means you can buy the K&R book, and program C without the anxiety for cross-compiler incompatibilities.

  • 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!
  • I'm not saying that writing good and efficient code is dead nor is learning about it. It just seems to me that books like this are more about coding "philosophy" then real software engineering. These books are around to create some kind of culture with programmers and I personally want no part in it. We spend too much time with fluff and "this is cool, but that's it" when we need to work more on applying the things we talk about. Yes, I am talking about the open source movement.

  • 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. :-)

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

    Absolutely. While there are clearly big differences between writing an essay and writing a program, there are big similarities, as well - at least, if your goal in your coding is to produce something halfway maintainable. Remember, program code doesn't just get read by compilers - it gets read by other people, as well. And in the long term, readability by other humans is of paramount importance. Someone who can't produce a clearly-written, convincing, well-organized essay will probably also be unable to produce clean, readable, well-organized, and relatively defect-free source code.

    That said, I do think that all the hard math and engineering skills are important for good programming, as well - which is probably why truly great programmers are so rare: it takes a rarely-seen combination of 'hard' and 'soft' skills.

  • 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.
  • KR is a vaginal jelly used to lubricate GNU cult members for the final insertion. Oops, that's KY.
  • I have to disagree with the breadth of your statement. Sure, nothing teaches better than experience, but sometimes it takes a different set of eyes to help you see outside the "box" that you're in.

    So if I write 40 programs that use an insane amount of nested loops and goto's, then that's better than two programs using a switch case statement?

    or how about a more realistic example- I work really hard on my code, and I try to cut it down to the point where it's only 17 lines... but it is also the most inefficient use of the processor;
    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)

    My point is that experience can take you far, but sometimes you need a smack to the head from an outside source.


    .sig files are for the weak.
  • 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.
  • Technique gets too much focus, if you want to be a better coder just code more!

    I'll bet you're one of those people who criticizes the prolific Jon Katz' writing skills too. (insert smiley emoticon here)

    Practicing bad technique doesn't make you any better at anything. There are notable exceptions of course (like Eric Liddle, one of the Olympic runners portrayed in the movie Chariots of Fire, who ran with his head back and eyes closed). If I don't at least occasionally check out some resources I keep doing what I already know. I may get better and faster at the current level, but I never progress to the next one.

    It's kind of like the guy who told his boss he needed a raise because he had twenty years of experience, which was more than anyone else in the department. The boss countered with, "No. You've just had the same experience for twenty years."

    carlos

  • 1. Get the biggest/faster machine available. You need something to brag about.

    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.

  • 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 /.
  • This must be the place to ask newbie questions that I've been searching for!

    What I want to ask is "is there a TROLL-HOWTO".

    ps.Madness takes its troll.

  • I agree, I routinely spend 5-6 hours or more programming daily and I learn so much more than sitting down and reading books (gotta love O'Reilly). Granted, I routinely have to refer to books for things but I never would have if I wasn't coding in the first place.

  • Technique gets too much focus, if you want to be a better coder just code more!

    Unfortunately, this is a bit like saying, "if you want a better understanding of nutrition, just eat more!"

    Coding more, using the same habits and methods, will only reinforce those very habits (good ones and bad ones alike).

  • Pragmatic Programmer web site? (Score:2)

    by Anonymous Coward
    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 [barnesandnoble.com], which was the definitive definition of C until ANSI got their hands on it, and is still a must read for C programmers.

    ----

  • 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) [bol.com]. 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_-


    --


  • 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_-


    --

  • Haven't we been down this road before?

    /. used Now, the same paltry amount is the same sort of partnership you see at sites such as Salon, NYT, etc.

    Book reviews that link to Book sites and make money from the links are nothing new or shocking.

  • "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_.
    ---
  • 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...
  • 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".
    This is a really easy line to take, and you'll go far in the corporate world if you go around calling yourself "pragmatic", but there are a few things about this that bother me.
    1. Time is limited. Yes, learning stuff is great, "growing" is great, but learning everything is literally impossible. You can't be a master of every language, every OS, every software library. How do you make your choices? How are you going to decide what to learn next?

      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.

    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.
  • 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
  • ...a bathroom factor.

    Basically, can you get anything out of the book during an ARV (Average Restroom Visit)?


    --
  • I have a few books out there that are full of stuff I already know. The nice thing about such books is that they index it, something my head isn't so good at (my mind is less of an information library and more of an information landfill).

    Such a book can remind you of what you already know so that you actually use that knowledge.

  • Frankly, coding is boring. Designing systems is where the beauty of "programming" lies.

    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.

  • Their code had a complete disregard for the processor underneath
    Usually it's more important to have regard for the next person to have to deal with your code than to have regard for the processor. ("Code as if whoever maintains your code is a violent psychopath who knows where you live.") Of course, it's a regretable truth that there's plenty of code out there that takes no regard for either the CPU or the next hacker in line.

    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.

  • 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.
  • I've never known a truly great programmer that didn't have both lots of experience and a bookshelf full of coding books. You need both.

    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.

  • 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.
  • 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?!

    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 /.. You know, mainstream sucks, it's for Windows-programming morons only. Read out-of-print books like "Thinking Forth" (really a gem, no fun!).
  • 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 [slashdot.org]. I bought and read The Practice of Programmer by Kernighan and Pike in part because of this review [slashdot.org]. To those of you taking the time to post book reviews here, I offer my thanks. You are being read.
  • Real Software Engineers [geocities.com]

    Real Computer Scientists [geocities.com]

    These and many others can be found here. [geocities.com]

    And, to anyone who might know, the evolut ion of a programmer [geocities.com] 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 [redrival.com] copy of DeCSS. Where's yours?
  • Another good read in the same vein is Polya's How to solve it [fatbrain.com].
  • 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
  • Note that the "buy the book" link to Fatbrain in the review,

    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 [fatbrain.com], 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.

  • Read this book! (Score:3)

    by Edward Kmett ( 123105 ) on Wednesday February 16, 2000 @05:26AM (#1269122) Homepage
    This book is one of the best written programming books that I have found in a long time.

    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)

    by Frank Sullivan ( 2391 ) on Wednesday February 16, 2000 @06:26AM (#1269123) Homepage
    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. :}
    ---

Slashdot Top Deals

He has not acquired a fortune; the fortune has acquired him. -- Bion

Close