Shop now Shop now Shop now Cloud Drive Photos  Up to 50% Off Fashion  Shop all Amazon Fashion Shop now Learn More Shop now Shop now Shop Fire Shop Kindle Listen with Prime Shop now Shop now

Customer Reviews

4.4 out of 5 stars44
4.4 out of 5 stars
Format: Paperback|Change
Price:£24.79+ Free shipping with Amazon Prime
Your rating(Clear)Rate this item


There was a problem filtering reviews right now. Please try again later.

on 4 March 2002
I am an old hand in the programming theater now - I started as a professional in 1979. I have read many books and attended many conferences and discussions on the subject of programming. Some books were OK, most was too filled with specific coding details to be of any value. Until now, I have only read two books that I feel is any good in describing the programming activities. The first book is only in Danish and was released in 1979 (I still have it). The second book is this one!
I will imidiately agree with some of the negative reviewers that the book states "the obvious". But that is the whole point, dammit! I do know that I should not do so-and-so, but I still do the bad thing occasionally. The book shows me - gently! - other ways.
Some may be irritated because of the elementary stuff and simple language (and "no examples"), but if you need examples, you have perhaps not that many years of practical experience. I, at least, do not feel the need.
Some say that the book is part of the eXtreem Programming paradigm. Well, no - I think the book to be unrelated to a particular school of thoughts. Instead it is a book that every programmer can relate to.
11 comment|77 people found this helpful. Was this review helpful to you?YesNoReport abuse
on 8 January 2000
Many years ago, I visited a friend and slept in their spare room. I found a book on their shelves called "Programming Pearls". (You've probably heard of it; it's a classic.) I sat up half the night reading it.
A few days ago, I visited a bookshop and bought this book. I sat up half the night reading it. In a few years, I think it might be as famous as "Programming Pearls". It certainly reminds me more of "Pearls" than does any other book I can think of.
The book is a whirlwind tour of a wide range of interesting topics. (Examples, chosen at random by opening the book to random pages: "tracer bullets", a variety of exploratory programming; the advantages of plain-text representations of data; how to handle resources like memory and open files; how to apply the old GUI technique of separating "models" and "views" to things that have nothing to do with user interfaces; how to organise a project team; the value of exceeding expectations.)
The writing is clear and lively. The authors have a keen sense of humour and a fine feel for apposite quotations.
The book is structured as a series of 46 sections, in 8 chapters. Along the way, they give 70 brief tips (random examples: "Don't Repeat Yourself"; "Estimate to avoid surprises"; "Write code that writes code"; "Separate views from models"; "Don't use wizard code you don't understand"; "Expensive tools do not produce better designs"; "Sign your work"). There's a pull-out card in the back of the book that contains all the tips, and a few "checklists" too.
I only found one typo. The typography is pretty good, although I happen to detest the main typeface they've used. The binding is bad; it looks fine, but (on my copy, at least) the covers have a distressing tendency to curl outwards. The pull-out card at the back is difficult to pull out without damaging anything.
I gave some random examples earlier. Here are a few highlights.
1. An excellent attack on what they call "programming by coincidence": being happy when your system works even if you don't know why it works.
2. A discussion of the benefits of automation: code generators, text munging tools to massage your source code, automated test suites and the like.
3. The multitude of little insights scattered through the book: even in sections whose topics I already knew plenty about, there were usually one or two startling observations or neat tricks or insightful points of view.
Lowlights? Because the book covers such a lot of ground, they have to skim over a lot of issues (but don't misunderstand me; there's plenty of meat here). And the two purely mechanical things I mentioned above. I think the only two sections I learned nothing from were the ones on Algorithm Speed (which I think is rather shallow) and Refactoring (which does have some not-generally-known ideas in it; but I've just finished reading Martin Fowler's book on refactoring).
Neophytes will learn a lot from the book. Old hands ought to know most of what's in here, though too many don't; those who do will still find enough that's new to justify the price, and have a lot of fun reading it.
A fine book: enjoyable and instructive.
0Comment|58 people found this helpful. Was this review helpful to you?YesNoReport abuse
on 12 March 2003
Like most guides, methodologies, or insights this book is best taken as something thought-provoking, rather than prescriptive. It covers a lot of ground in a relatively short space, applying its basic principal to day-to-day software engineering as opposed to just programming.
The key principal is one that I (and most people) probably subscribe to, perhaps even subconsciously, which is called 'DRY', which stands for 'Don't Repeat Yourself'. The difference is that the authors explain how to apply this to _all_ aspects of your job, not just the obvious one which is code re-use and sharing.
In general, the message seems to be 'invest time in the short term to automate and increase efficiency in the long term'. A sensible message, but one that many people (and I most definitely include myself here) avoid doing because of the initial time and effort involved in learning the required technologies and implementing the automation (Emacs and Perl for example).
Other advice I particularly agreed with was the importance of recognizing limitations of methodologies and diagram-types, and using them as a guide and communication medium rather than as an end in themselves. I also really liked the sections on decoupling, which has a nice introduction to JavaSpaces - a really cool paradigm for certain classes of problem.
In summary, this is not really a reference book - instead it's a 'memory-jogger', reiterating many things you already know at some intuitive level, but fail to follow - up due to external pressures or just plain homeostasis.
0Comment|56 people found this helpful. Was this review helpful to you?YesNoReport abuse
on 22 January 2005
I liked the book. It's light reading and has sensible advice. But my enthusiasm wore off slightly from the middle onwards. I found it somewhat repetitious. It does help to have the same ideas reinforced (particularly "Tracer bullets", "Stone soup" and "DRY: Don't repeat yourself") but after a few different applications of the same points, I got the idea, and I found the book laboured.
It's a good book though and worth buying for a regular reality check. I think reading it solidly cover to cover once over may not be the best way to use it. To get the most from it, it's probably best to skim over quite quickly, to get to know where the information is, then kept on your desk to dip into regularly when you have ten minutes or so to spare.
11 comment|24 people found this helpful. Was this review helpful to you?YesNoReport abuse
on 20 February 2011
The ideas presented are still very relevant today despite the examples being rather dated. The writing style puts ideas across in a clear, easy to read manner. The choice of phrasing for some points is excellent, specifcally when describing Technical Debt. However, as a more experienced developer, I found the content to be too high level for me to take a lot away. At the same time, the book covers such a breadth in topics that I'm not convinced enough detail has been given for someone starting out in their career either.

Overall, I'm glad that I've read The Pragmatic Programmer but feel I am unlikely to go back to it.
0Comment|4 people found this helpful. Was this review helpful to you?YesNoReport abuse
on 22 April 2012
Really, I found the book boring. Still, it taught me a lot of things, but I dint't appreciate it until several months later. Also, there are several parts of the book where you think the correct title should be "The obsessive-compulsive programmer".
Anyway, recommended.
0Comment|3 people found this helpful. Was this review helpful to you?YesNoReport abuse
on 19 May 2000
I'm fairly new to programming, and I found this book gave me the insights and ideas of a much more experienced person. It can't take the place of experience, of course, but it can broaden your outlook, and expose you to ideas and methods you're current project isn't using. I found it easy to read, concise, and gave ample references for further reading.
It is a bit UNIX-centric in places, and doesn't give Windows such a good press. It does encourage you to think outside what your IDE can do for you, though, and explains what scripts and command prompts are really for!
Definetely recommended for a less experienced software developer with ambition.
0Comment|10 people found this helpful. Was this review helpful to you?YesNoReport abuse
on 6 March 2012
First off, this book is excellent in how it was written and how it presents its material. That said, I haven't given this book five stars because it doesn't quite live up to it's hype. There's not a bit of advice in this book which isn't useful, and all topics remain relevant today, but the promise that this book will bring you 'From Journeyman to Master' is a bit extreme. I would have very much enjoyed if this book focused more on the social concerns of the programmer (as some early chapters did), and the concept of hacking your environment and programming your managers/clients.

This book is an absolute must-read for any serious professional programmer simply by nature of the fact that so many of your contemporaries will have read it. Ultimately, this isn't a secret guide to dominating the field, but a practical guide for practitioners. Take the title of this book as advice- weigh each of the discussion points against their applicability in your projects.
0Comment|Was this review helpful to you?YesNoReport abuse
on 29 August 2006
This is a refreshingly different book which uses a lot of real-life analogies that relate to the software development paradigm. For instance the "Broken Windows" analogy for "Zero Tolerance Construction" was very useful; they just had to explain the analogy and I could already see how it related to software engineering practice.

In most of the cases their philosophy reinforced the ideas I had developed myself over the years, such as witnessing design patterns being used inappropriately.

I didn't agree with all of their advice, for instance they suggest learning new programming languages, when really they should suggest to just continue learning and keep up-to-date on industry trends.

The ability to explain software engineering principles with real-world analogies helps with communicating them to laypersons (end-users) who, after all, don't understand UML notation. Much of the book is "obvious" but it helps to take a step back from time to time and be refreshed.
0Comment|8 people found this helpful. Was this review helpful to you?YesNoReport abuse
on 8 July 2013
Wether you call yourself an engineer, a developer or a programmer, you *must* have this book. I've already read it online and now I'm taking this paperback version with me alongside Crockford's JS:TGP.

A must read. A must have.
0Comment|One person found this helpful. Was this review helpful to you?YesNoReport abuse

Sponsored Links

  (What is this?)