

|
The Pragmatic Programmer: From Journeyman to Master (平装)
by Andrew Hunt, David Thomas
Category:
Software development, IT, Technology |
Market price: ¥ 448.00
MSL price:
¥ 428.00
[ Shop incentives ]
|
Stock:
Pre-order item, lead time 3-7 weeks upon payment [ COD term does not apply to pre-order items ] |
MSL rating:
Good for Gifts
|
MSL Pointer Review:
A classic reading on programming ranking with Code Complete and The Mythtical Man-Month. |
If you want us to help you with the right titles you're looking for, or to make reading recommendations based on your needs, please contact our consultants. |

|
|
AllReviews |
 1 2 Total 2 pages 16 items |
|
|
Nikolaus Heger (MSL quote), USA
<2007-01-10 00:00>
This book is easily the best book on programming that I know. Tuck it under your pillow at night, and keep it close by at all times - I recommend re-reading it every year or so because it contains so much information.
The best part is that all the advice in this book works, sometimes spectacularly so. After reading it, I wanted to put it to practice so I implemented a fairly large system following each and every bit of advice. It was a resounding success: I ended up with a product that had almost no bugs. Even better, the bugs that were found by the rigorous QA process were all easy to fix, benign bugs. This book will make you a better programmer, and I would recommend it first and foremost, before reading any other books on design patterns and whatnot. Pragmatism rules! |
|
|
Alex Valentine (MSL quote), USA
<2007-01-10 00:00>
This book takes the reader through all facets of software development and gives practical methodologies to write better software. This book is not language specific; almost all of the concepts can be applied to virtually any language. Besides dealing with how to write better code, The Pragmatic Programmer discusses project management, team dynamics, user expectations, and a host of other topics. At only 250 pages, this book does not go in to great detail in any one topic, yet there is enough information for anyone to implement the practices suggested in the book. I recommend this book to anyone who is in the field of software development: developers, project managers, systems analysis, and even managers who want a better understanding of how the software development process should be. |
|
|
Ew Smith (MSL quote), South Africa
<2007-01-10 00:00>
A collaborative work worthy of a top-ten ranking for software development "bible".
This book distills everything pertinent to real-world "rubber-hits-the- road" software development. Given that there isn't really another type, save that which is embraced in the dank halls of academia, go to this book first. Yes, even before "Code Complete".
The style is refreshingly unassuming and devoid of religious side-taking (bar a modest but controlled bent towards a unixy philosophy). All sides are presented, and a final "we feel ..." proffering a very soundly backed up opinion on the subject in discussion. It's written for the reader - easy-going and coloured with industry anecdotes and graceful humour.
References are ubiquitous, indicating a well-balanced text from true field professionals.
Andy and Dave regularly re-inforce their modus operandi, that of pragmatic professional. Especially noteworthy is the no-nonsense style - unlike other books in this category, lip-service to the "fashion of the day" is avoided - accepted norms are questioned, but done so gracefully, and with respect.
The entire book resonated with me, and I regularly found myself nodding in silent agreement. I would have to say that the most significant thing I got out of this book though was the relentless philosophy of "do it right", from uncomprisingly implementing "don't-repeat-yourself" to choosing the most appropriate tool for the job (rid yourself of those emotional attachments), all communicated in a wonderfully modest manner. |
|
|
An American reader (MSL quote), USA
<2007-01-10 00:00>
The preface says "this booked is aimed at people who want to become more effective and more productive programmers", but after reading this book, I think the book should be required reading for all junior programmers. In around 300 page, this book isn't heavy reading like code complete 2, but it gives a brief overview of almost every philosophy which every programmer should embrace, ideas such as DRY, lower coupling, MVC paradigm. I strongly recommend this book to every junior programmer (if you're an experienced one you should already know everything this book talks about). |
|
|
Shrike (MSL quote), USA
<2007-01-10 00:00>
I've had this book for a number of years now and skim it regularly. I've recommended it to starting and would-be programmers as well as hoary old "I remember punch-card" war horses. I often wish there were more books in this same vein.
The only downside that I could note is that the authors often refer to their own preferred languages & scripts, which both dates the product a little (more so with each passing year), and is also not so useful to those working in different environments or who have their own strong preferences.
However, the nuggets of wisdom and common-sense analogies in this book are golden. If you're like me, you'll often find yourself nodding along with the book while reading a passage that describes something you've experienced or espoused first hand and grimacing when it points out a trick you wish you had thought of when working on some past project.
This book really doesnt have much to do with programming, but is really more about “being a programmer.” It's sort of like a self-help for proggies, a mentor-in-a-book. The book's subtitle is "From Journeyman to Master", and this jives with the idea of the things in the book being the sort of Guild-lore a Master Craftsman might pass on to his favored Journeymen prior to retiring back in the days of yore.
I've been a professional developer now for 6 years, self taught and continuously employed at several companies during that time. This book appealed to me when I picked it up because it is true-to-life, and several of the real-world considerations mentioned jived with my own experiences. The ideas and practices that I already had were crystalized and refined by this book, and it also introduced me to ways of thinking that I had not considered.
Perhaps the most significant single line in the book for me is on page 255, "A project that falls below expectations is deemed a failure, no matter how good the deliverable in absolute terms". This struck home because I was once involved in a major project involving multiple programmers from multiple locations around the States, which met every design specification and delivered exactly what was promised, but which was mothballed after its completion because the management didnt understand it. Their expectation was something other than the specification which they had approved and thus we harried developers wasted the better part of a year on a system doomed to failure not because it didn't work or was a bad idea, but because the head honchos just didnt get it. I never understood why until I read that line in this book, and then it all came clear - their expectations were not in line with the deliverable, and thus they did not want the deliverable despite the fact that it functioned exactly as planned.
Since then I've made it a point to personally do all that I can to ensure that the consumers of projects I'm involved with are "on the same sheet of music" when it comes to understanding what all the tech-speak and specifications actually MEAN. Prototyping and "Tracers" as described in this book have been used to provide mockups before any real code has been written. Documents couched in "Laymans Terms" have been produced. Sometimes it's overkill, but at the end of the projects no consumer comes back saying "thats not what I thought it was going to be". Some Project Managers dont like it, as they feel like it's stepping on their toes, but in the end no Project Manager will complain if the Project is successful - they get to look good for a while, so kibitzing over the means isn't a priority.
All that aside, if you are a working developer with a grounded approach to programming, and dont have the conceit that you already know everything, I think you should give this book a read through. |
|
|
An American reader (MSL quote), USA
<2007-01-10 00:00>
"Any clod can have the facts, but having opinions is an art." (Charles McCabe)
By McCabe's definition, this book is very artful. That's a good thing - the opinions are founded on long experience and on broad familiarity with software development. The authors, true to their "pragmatic" promise, often omit the theory and case history that justify the opinions. They offer reams of advice on nearly every part aspect of industrial programming, and I think that all of the advice is good.
I don't agree with all of it - good advice is good within its limits, and my work often lies outside of their limits. Take, for example, their editor fanaticism. I've been hearing for 25 years how much more efficient my work will be if I use editor <xyz>. First, I move between development environments so much that learning funny key-pokes for one environment just gives me the wrong reflexes for the next environment and the one after that. Mostly, though, text entry is about 5% of my problem. Suppose, after a "near-vertical learning curve", that the cult editor cuts 20% off my editing time - data entry would then be 4% of my problem. The cost/benefit ratio underwhelms me. If you really love your escape-meta-alt-control-shift (emacs) editor, though, don't let me get in your way.
I still think that almost all of the authors' views are good ones, with good reasons behind them. I rabidly agree with lots of them (especially DRY - Don't Repeat Yourself), and for lots more reasons than they give. The book is helpful even where I disagree. When I rethink my own circumstance, it's not that their reasoning is wrong, but that different reasoning is more right.
This is one to keep, not just for the programmers in the trenches but for their managers, as well. Best, it doesn't try to dress up the -ism of the day as holy law - as the title says, it's about pragmatics. |
|
|
|
 1 2 Total 2 pages 16 items |
|
|
|
|
|
|