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.
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.
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.
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.
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".
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.
on 18 February 2001
It's not often that I buy books on programming that turn out to be real whoppers of wasted money. But it happened with this one. Guess I believed the reviews and adverts. I do not know what the authors were thinking when they wrote this one, maybe they were aiming at the kind of programmer that can be called 'the garden variety', not rank amateurs but certainly not professionals either. It's like reading a book that tells you how to program for Windows 3.11. Several times during the first 50 pages I felt compelled to leaf back to the page in the beginning of the book where the publisher details are specified and really make sure that this book was published in the year 2000, and not in 1990 or even earlier.
For example, chapter 2 begins stating that "there are certain tips and tricks that apply at all levels of software development...However, these approaches are rarely documented as such: you'll mostly find them written down as odd sentences in discussions of design, project management, or coding." At first I thought, Alright! let's hear it then! Only to discover that the authors proceeded to describe techniques such as not hardcoding constants in more than one place, information hiding and designing for change. I thought people discovered these techniques in the sixties and seventies. I thought that after the really superb series of books that Steve McConnell has written about the subject one would really have to be either very, very ignorant or deliberately keep one's tongue in cheek in order to be able to write such a paragraph as the one quoted above. Not to mention Brooks, DeMarco, Lister, Maguire, Weinberg, McCarthy, Yourdon, etc., all of whom have expounded on improving software development methods since the beginning of the seventies.
The authors proceed to write about all manner of subjects, loosely related to programming, quoting anyone from Mae West to Schrödinger (a theoretical physicist) to spice up the reading, skimming the cream of other people's work. On the way advising the reader to do things like learn one new programming language a year (it's not quite clear how that is supposed to improve the quality of one's work) and downloading free compilers from the Internet (is there anyone who can get those to work?).
No, no, it's not a good idea to read this book. Many of the 'opinions' of the authors are absolutely correct, of course, but their explanation of them is too glib and their thinking is sloppy at best.
Read "Code Complete" by Steve McConnell: solid quality writing, mature reasoning, backed up by research and experience; you get 800 pages of clear and unbiased advice on how to code. In "The pragmatic programmer" you get 300 pages of "tips and tricks". What are you going to do with those? Entertain friends and relations?
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.
on 10 November 2014
I bought this book not entirely sure what to expect with respect to technical content. It turned out to be an enjoyable and light read basically summing up a life long programmer's professional experiences and lessons' learned. Although it did start to repeat the same message in the second half of the book, this was a rewarding read and I strongly recommend this book to graduates and newly trained programmers to further round out their practical know-how - there are some important professional tips which everyone should know (albeit common sense at times).
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.