What do you think?
Rate this book
The Productive Programmer (Theory in Practice
Anyone who develops software for a living needs a proven way to produce it better, faster, and cheaper. The Productive Programmer offers critical timesaving and productivity tools that you can adopt right away, no matter what platform you use. Master developer Neal Ford not only offers advice on the mechanics of productivity--how to work smarter, spurn interruptions, get the most out your computer, and avoid repetition--he also details valuable practices that will help you elude common traps, improve your code, and become more valuable to your team. You'll learn
This isn't theory, but the fruits of Ford's real-world experience as an Application Architect at the global IT consultancy ThoughtWorks. Whether you're a beginner or a pro with years of experience, you'll improve your work and your career with the simple and straightforward principles in The Productive Programmer .
This isn't theory, but the fruits of Ford's real-world experience as an Application Architect at the global IT consultancy ThoughtWorks. Whether you're a beginner or a pro with years of experience, you'll improve your work and your career with the simple and straightforward principles in The Productive Programmer .
222 pages, Paperback
First published January 1, 2008
45 people are currently reading
1573 people want to read
About the author
Neal Ford
25 books220 followersNeal Ford is Software Architect and Meme Wrangler at ThoughtWorks, a global IT consultancy with an exclusive focus on end-to-end software development and delivery. He is also the designer and developer of applications, instructional materials, magazine articles, courseware, video/DVD presentations, and author and/or editor of 5 books spanning a variety of technologies. He focuses on designing and building of large-scale enterprise applications. He is also an internationally acclaimed speaker, speaking at over 100 developer conferences worldwide, delivering more than 600 talks. Check out his web site at http://www.nealford.com. He welcomes feedback and can be reached at nford@thoughtworks.com.
Ratings & Reviews
Friends & Following
Create a free account to discover what your friends think of this book!
Community Reviews
Displaying 1 - 30 of 62 reviews
February 11, 2015
Can be skipped. Basically this book doesn't suit me at all. Initially most of the tips are elaborately described for windows. Being a linux user , i had to skip those pages. Rest of the book talks about many good practices in a very shallow manner . In those pages author narrowed down to some particular languages (I had to skip pages again ) . Basically i expected a more theoretical and abstract approach which is completely missing in this book . Will explore some more books in this genre.
January 21, 2010
I had just read "Clean Code" and this book was not at all what I expected. Tips, tricks, and scripts for programmers. Not really about theory and practice of programmers. This is more nuts and bolts. Felt like a collection of blog posts to me.
July 9, 2008
Despite the three stars, this book actually contains a lot of useful material. It was just "OK" for me personally. It's not that I don't think this book offers good advice - it's just that for me it was just "preaching to the choir" so to speak and I didn't really take a lot new away from it. But for those who don't have as many years under their belt it definitely offers some useful strategies to steer you in the right direction.
July 23, 2013
Keyboard shortcuts. Focus. Automation. Good coding practices. Get stuff done in a tenth of the time it would otherwise take. Great book.
March 9, 2012
Why do some developers spend one week accomplishing what other developers complete in a day? The oft-heard "talent and skill" responses do little to address the root causes to inefficient programming and do not help such developers effectively improve. With this question in mind, The Productive Programmer by Neal Ford applies a productivity framework aimed at training developers to interact with the computing machine with a certain posture in which short term efficiencies are replaced with long term productivity boosts.
Ford describes developer productivity in four categories: acceleration, focus, automation, and canonicality. Acceleration concerns the maximal reduction of time required to interact with the machine to accomplish a given task. Focus has to do with keeping the developer's attention on the primary programming challenge before him (vice HCI concerns, meetings, and emails). Automation is the replacement of repetitive, manual, routine tasks with automated solutions. Lastly, canonicality seeks to maximize simplicity by simultaneously reducing repetition. Applying this framework, Ford offers a number of tools and suggested uses to address each of the given productivity categories.
In the second part of the book, Ford shifts his focus to development practices and outlines a set of fundamental principles aimed at increasing productive development. These include, to name a few, DRY (Don't Repeat Yourself), YAGNI (You Ain't Gonna Need It), Static analysis, and Test Driven Design (TDD). These principles, in total, provide a framework for development that is intentional about the code being produced. As a result, the produced code is able to grow in scope without loss of clarity, simplicity, and therefore, developer efficiency.
While Ford's book has become somewhat dated, his recommendations continue to stand the test of time. Most of the tools are still available, and his programming techniques are no less true today that when they were first written.
Ultimately, Ford's urges developers to think critically about the way in which they are working and be actively aware of opportunities to improve productivity through the productivity paradigm (AFAC). Good development involves, fundamentally, intentional design for long-term productivity.
This book is for developers at all experience levels. For the inexperienced, this will provide a foundational set of techniques and tools for productivity gains. For the experienced, Ford's work offers a particular perspective on highly efficient development from another seasoned developer.
Ford describes developer productivity in four categories: acceleration, focus, automation, and canonicality. Acceleration concerns the maximal reduction of time required to interact with the machine to accomplish a given task. Focus has to do with keeping the developer's attention on the primary programming challenge before him (vice HCI concerns, meetings, and emails). Automation is the replacement of repetitive, manual, routine tasks with automated solutions. Lastly, canonicality seeks to maximize simplicity by simultaneously reducing repetition. Applying this framework, Ford offers a number of tools and suggested uses to address each of the given productivity categories.
In the second part of the book, Ford shifts his focus to development practices and outlines a set of fundamental principles aimed at increasing productive development. These include, to name a few, DRY (Don't Repeat Yourself), YAGNI (You Ain't Gonna Need It), Static analysis, and Test Driven Design (TDD). These principles, in total, provide a framework for development that is intentional about the code being produced. As a result, the produced code is able to grow in scope without loss of clarity, simplicity, and therefore, developer efficiency.
While Ford's book has become somewhat dated, his recommendations continue to stand the test of time. Most of the tools are still available, and his programming techniques are no less true today that when they were first written.
Ultimately, Ford's urges developers to think critically about the way in which they are working and be actively aware of opportunities to improve productivity through the productivity paradigm (AFAC). Good development involves, fundamentally, intentional design for long-term productivity.
This book is for developers at all experience levels. For the inexperienced, this will provide a foundational set of techniques and tools for productivity gains. For the experienced, Ford's work offers a particular perspective on highly efficient development from another seasoned developer.
January 23, 2010
I can agree with the core message of this book, which is you should always be looking for a better way to get your job done. That's a good message and this book has some decent examples of how to accomplish that.
However, it would concern me a little bit if a programmer finds that message to be groundbreaking. People use computers and write programs to simplify tasks and be more efficient, so if a programmer is not already of the mindset that things can and should constantly be improved and done more efficiently, then they're probably not a very good programmer.
However, it would concern me a little bit if a programmer finds that message to be groundbreaking. People use computers and write programs to simplify tasks and be more efficient, so if a programmer is not already of the mindset that things can and should constantly be improved and done more efficiently, then they're probably not a very good programmer.
July 7, 2015
Much of it will not apply to any given reader; this is a necessity of this sort of book, and shouldn't be held against it as some reviewers seem to have done.
Read it swiftly, paying attention to the bits that are relevant to your situation for gradual incorporation into your workflow. If you implement one or two of the suggested changes -- for example, learning the keyboard shortcuts for the IDE or text editor of your choice, and incorporating code analysis tools in your development process -- your ROI will make reading this book well worth it.
Read it swiftly, paying attention to the bits that are relevant to your situation for gradual incorporation into your workflow. If you implement one or two of the suggested changes -- for example, learning the keyboard shortcuts for the IDE or text editor of your choice, and incorporating code analysis tools in your development process -- your ROI will make reading this book well worth it.
September 27, 2009
This book is filled with many great tips and tools that help enhance productivity. It is a must read for those that want to make their computer do the work for them. Ever hear of the phrase: "work smarter, not harder?" -- this is how to work smarter.
March 24, 2019
A bunch of advices/recipes to be a productive programmer. Interestingly, I was practicing quite a few of them, whew :) While many of these recipes may be a bit dated given the improvements in software environments, being aware of the issues these recipes provide tackle and the resulting gains will helps programmers identify new recipes based on new features of environments to productively tackle similar issues. That said, I kept thinking "what would be the advices/recipes for the current world of software development?" Specifically, given the current trend of DevOps that leans heavily on remote deployments and configurations fragmented across cloud vendor specific technologies.
In the end, you will either learn new recipes or recollect forgotten recipes :)
In the end, you will either learn new recipes or recollect forgotten recipes :)
December 25, 2022
Needs an updated edition badly. This book has a lot of solid, but naturally alot of outdated advice, given that it was published in 2008. One of the solid ones is 'Out-of-date documentation is worse than none because it is actively misleading.' A truth in '08, now, and will be in 20 years. If the book only contained those timeless facts, it wouldn't be so sensitive towards everything that's happened in the industry since its release. However, there are too many recommendations of obsolete tools and too much that's happened in the field for this edition to feel relevant.
August 16, 2018
Read this a (long) time ago after attending a talk by Neal Ford that inspired me to buy the book. It didn't let down: I got the hang of things like clipboard history tools, practical tips to increase your programming speed (smart shortcut usage, more tooling, ...) etc. I know it might not be that theoretical and highly volatile as tools evolve VERY quickly, but it helped a lot at that time and got my mind set for that optimization that I'm always trying to aim for now.
May 10, 2017
I should make more of an effort to read books when I first buy them. This has been sitting unread on my bookshelf since 2008. A lot of the more general advice is still pretty good, but when the author starts covering tools, it all looks a bit dated (for example, he promotes Subversion as the state of the art version control system).
May 29, 2017
A Very great book that had more helpful techniques for productive programmer ,
How to fast working, planning, analysis, debugging, Testing and team management.
How to fast working, planning, analysis, debugging, Testing and team management.
October 14, 2020
not worth reading, too shallow and to obvious
October 26, 2020
A bit outdated but still quite useful book.
January 8, 2021
感觉就是由作者闲时写的 blog 拼凑而成，90% 的章节读标题就够了，应该直接读 The Clean Coder 的
March 16, 2021
Coverage of the experience in software development obtained by the author during his work. The presentation is not systematic, as stated in the preface to the book.
December 21, 2021
Читается легко. Много полезной и вдохновляющей информации, особенно для начинающе-продолжающих специалистов
March 21, 2017
Has good points of view, but I think is not up to date according with the these days technologies.
May 28, 2013
The book is a quick read and will add a few useful tricks to your "bag of tricks". The author has not dived as deep as Dave Thomas and Andy Hunt have in Pragmatic Programmer but it's not shallow either. It's a good addition to my bookshelf and knowledge-base. Part I wasn't much helpful since I myself started programming from command-line tools, however, Part II, the productive practices section, was quite interesting. Some worth mentioning tricks I learned are
1. Composed Methods (originally from Kent Beck's Smalltalk Best Practice Patterns): All public methods should read like an outline of the steps to perform in the function.
http://c2.com/ppr/wiki/WikiPagesAbout...
2. SLAP (Single Level of Abstraction Principle) - (borrowed from Kent's book): One method should only deal with one level of abstraction to avoid the confusion.
3. The law of Demeter: Re-invigorates the encapsulation concept of OOP by stating that a method should only invoke other methods that are :
a. Members of the same class
b. Direct members of the object in the parameter
c. or direct members of the object created inside the invoking method itself.
http://www.ccs.neu.edu/research/demet...
It re-iterated following things for me as well:
1. TDD is god-sent
2. Don't mix state with statics plus singletons are mostly bad
3. Function size should be determined and upto 15-20 lines
4. YAGNI (You Ain't Gonna Need It)
5. Perils of software entropy
6. Avoid gold-platting and designing useless frameworks
7. Measure the cyclomatic complexity whenever possible
8. Code coverage, static analyzers, and style checkers
9. DSL's are the way of the future
An intriguing excerpt from the book:
"Programming combines engineering and craft in highly coupled ways, requiring good developers to exhibit a wide variety of skills: analytical thinking; extreme attentions to detail on multiple levels and aesthetics; an awareness of macro and micro level concerns simultaneously; and a keen, fine-grained understanding of the subject matter we're writing software to assist. Ironically, developers have to understand business processes at a much lower level than the actual practitioners of the business. Business people can use their experience to make on-the-fly decisions when novel situations pop up; we must encode everything in algorithms and explicit behaviors."
Here is an outline of the book from the author - http://www.slideshare.net/guestebde/1...
1. Composed Methods (originally from Kent Beck's Smalltalk Best Practice Patterns): All public methods should read like an outline of the steps to perform in the function.
http://c2.com/ppr/wiki/WikiPagesAbout...
2. SLAP (Single Level of Abstraction Principle) - (borrowed from Kent's book): One method should only deal with one level of abstraction to avoid the confusion.
3. The law of Demeter: Re-invigorates the encapsulation concept of OOP by stating that a method should only invoke other methods that are :
a. Members of the same class
b. Direct members of the object in the parameter
c. or direct members of the object created inside the invoking method itself.
http://www.ccs.neu.edu/research/demet...
It re-iterated following things for me as well:
1. TDD is god-sent
2. Don't mix state with statics plus singletons are mostly bad
3. Function size should be determined and upto 15-20 lines
4. YAGNI (You Ain't Gonna Need It)
5. Perils of software entropy
6. Avoid gold-platting and designing useless frameworks
7. Measure the cyclomatic complexity whenever possible
8. Code coverage, static analyzers, and style checkers
9. DSL's are the way of the future
An intriguing excerpt from the book:
"Programming combines engineering and craft in highly coupled ways, requiring good developers to exhibit a wide variety of skills: analytical thinking; extreme attentions to detail on multiple levels and aesthetics; an awareness of macro and micro level concerns simultaneously; and a keen, fine-grained understanding of the subject matter we're writing software to assist. Ironically, developers have to understand business processes at a much lower level than the actual practitioners of the business. Business people can use their experience to make on-the-fly decisions when novel situations pop up; we must encode everything in algorithms and explicit behaviors."
Here is an outline of the book from the author - http://www.slideshare.net/guestebde/1...
This entire review has been hidden because of spoilers.
September 9, 2008
Honestly, I have to say I was surprised to see that (at the time of this writing) this book was averaging 4.5 stars on Amazon. I suppose my expectations of this book were heavily swayed by the title. I was expecting something a little more generic and high-level than what I got.
I think the book makes a decent attempt to provide the reader with 'recipes' that can be used to improve their efficiency and productivity. But the recipes themselves seem to be a little too free-flowing: by the time I got around to the 3rd or 4th recipe, I had already forgotten the overarching theme of the chapter. I feel like the material might've been better presented in the style of O'Reilly's "Cookbook" book. I doubt a reader, after one pass through the book, will be able to implement every recipe they read about. I think it would be better to structure the book as a reference that they can flip through later.
Another issue I had with the book was that in the later half of the book, many of the examples given contain chunks (sometimes large chunks) of Java, Ruby, and Groovy code. While I'm sure many readers of this book are familiar with those languages, for those who aren't, the chunks become a serious roadblock to understanding the point of the example. Many of the examples (the Groovy ones, especially) cannot simply be interpreted 'by sight'. Perhaps a future edition of the book could have some type of fair warning at the beginning.
If you are a java developer, I think you can probably get a lot out of this book. If not, you'll probably still be able to get a good amount of information out of the first few chapters, but I'd suggest just skimming or skipping the latter chapters altogether.
I think the book makes a decent attempt to provide the reader with 'recipes' that can be used to improve their efficiency and productivity. But the recipes themselves seem to be a little too free-flowing: by the time I got around to the 3rd or 4th recipe, I had already forgotten the overarching theme of the chapter. I feel like the material might've been better presented in the style of O'Reilly's "Cookbook" book. I doubt a reader, after one pass through the book, will be able to implement every recipe they read about. I think it would be better to structure the book as a reference that they can flip through later.
Another issue I had with the book was that in the later half of the book, many of the examples given contain chunks (sometimes large chunks) of Java, Ruby, and Groovy code. While I'm sure many readers of this book are familiar with those languages, for those who aren't, the chunks become a serious roadblock to understanding the point of the example. Many of the examples (the Groovy ones, especially) cannot simply be interpreted 'by sight'. Perhaps a future edition of the book could have some type of fair warning at the beginning.
If you are a java developer, I think you can probably get a lot out of this book. If not, you'll probably still be able to get a good amount of information out of the first few chapters, but I'd suggest just skimming or skipping the latter chapters altogether.
February 7, 2010
This book is an easy read. The initial chapters being a little longer than some of the later ones. You get a few specific tools that improve your productivity right away. The one that I now use all the time is CLCL, AutoHotKey and customized shells.
The chapter on TDD does a good job of explaining the benefits of TDD. Nothing really new here for me. But for someone new to TDD this probably will provide more insights into the benefits. The chapter on Ancient Philosophers was an interesting read as well as the chapter on Question Authority. I liked how the author explained how the most obvious modelling of a problem's solution may not be the more effective or efficient. He used the example of the Pacman game to explain this. I'm not going to divulge the spoiler here. Sorry!
I got the most value from the Composed Method and SLAP chapter. I'd read and heard about these principles in other books, blog posts and from speakers. But only after having read this chapter did the effectiveness of these principles really dawn on me especially the Single Level of Abstraction Principle. Ensuring that every line of code in a method is at the same level abstraction even if you have to create single line methods to apply this principle is quite eye opening. I was able to effectively write a unit test that shunted a file copying routine because I'd applied composed method and SLAP. If there is only one chapter you would read in this book then this is that chapter.
I was a little disappointed with the accompanying website (http://prgamaticprogrammer.com). It's spam infested though I did get a tip on the Unlocker tool.
Overall good book. I'd recommend this for someone in the competent level of the Dreyfus model.
The chapter on TDD does a good job of explaining the benefits of TDD. Nothing really new here for me. But for someone new to TDD this probably will provide more insights into the benefits. The chapter on Ancient Philosophers was an interesting read as well as the chapter on Question Authority. I liked how the author explained how the most obvious modelling of a problem's solution may not be the more effective or efficient. He used the example of the Pacman game to explain this. I'm not going to divulge the spoiler here. Sorry!
I got the most value from the Composed Method and SLAP chapter. I'd read and heard about these principles in other books, blog posts and from speakers. But only after having read this chapter did the effectiveness of these principles really dawn on me especially the Single Level of Abstraction Principle. Ensuring that every line of code in a method is at the same level abstraction even if you have to create single line methods to apply this principle is quite eye opening. I was able to effectively write a unit test that shunted a file copying routine because I'd applied composed method and SLAP. If there is only one chapter you would read in this book then this is that chapter.
I was a little disappointed with the accompanying website (http://prgamaticprogrammer.com). It's spam infested though I did get a tip on the Unlocker tool.
Overall good book. I'd recommend this for someone in the competent level of the Dreyfus model.
This entire review has been hidden because of spoilers.
July 13, 2009
This is a 'glue' book. There are books about productivity tips and tricks, and there are books about good software design, and this book attempts to be the glue between them. It talks about what it means to be a productive programmer, both in terms of your toolset and in terms of your mindset. For the former, there are lots of links to various tools and productivity widgets that help you get things done. For the latter, there are discussions about programming tips and tricks.
This is good and bad. On the good side, it's nice to see someone -- anyone -- talking about more than just methodologies and best practices and pictures of what a "programmer's desktop" looks like and talk about the tools we all use (or maybe could/should use) to be more efficient at programming. On the downside, because all this stuff changes so fast, you know that this will be out of date in a year or two.
My other gripe with the book is very old-school of me; while he states that he's trying to make it very language- and product-agnostic, at time the various Web technologies get in the way of what he's trying to say. The book winds up (perhaps correctly) being very Web-centric even though the ideas really are language- and product-agnostic.
Of course, the irony is that I think I learned more from the "soon-to-be-out-of-date-but-cool-technology" section than from the "timeless aspects of programming lore" section.
This is good and bad. On the good side, it's nice to see someone -- anyone -- talking about more than just methodologies and best practices and pictures of what a "programmer's desktop" looks like and talk about the tools we all use (or maybe could/should use) to be more efficient at programming. On the downside, because all this stuff changes so fast, you know that this will be out of date in a year or two.
My other gripe with the book is very old-school of me; while he states that he's trying to make it very language- and product-agnostic, at time the various Web technologies get in the way of what he's trying to say. The book winds up (perhaps correctly) being very Web-centric even though the ideas really are language- and product-agnostic.
Of course, the irony is that I think I learned more from the "soon-to-be-out-of-date-but-cool-technology" section than from the "timeless aspects of programming lore" section.
September 7, 2010
The book's intention is to help jobbing programmers get more productive by remembering what the command line is for - the GUI's and IDE's we use every day have put us far away from the power of this, and a lot of younger people only know the world of the mouse. In essence it passes on the knowledge that's being lost to make you more productive.
The Mechanics section talks about simple tricks and tools to accelerate your use of the keyboard and repetitive tasks. I have installed a number of useful bits and pieces on my Mac because of this and can definitely speak of some improvement!
The Practice section is more about fixing the whole process you are confronted with and how to do OO projects properly, plus use tools to find common bugs and why having a canonical build is a good idea, plus standard tools etc. etc.
If you are fresh out of college and working as a developer to you should read this book. I've been doing this for over 20 years and got a lot from the war stories and simple suggestions, so even the fogies will benefit.
For reference on my Mac I've installed Jumpcut and I'm fighting with the Apple Ruby Spotlight importer http://www.apple.com/downloads/macosx...
The Mechanics section talks about simple tricks and tools to accelerate your use of the keyboard and repetitive tasks. I have installed a number of useful bits and pieces on my Mac because of this and can definitely speak of some improvement!
The Practice section is more about fixing the whole process you are confronted with and how to do OO projects properly, plus use tools to find common bugs and why having a canonical build is a good idea, plus standard tools etc. etc.
If you are fresh out of college and working as a developer to you should read this book. I've been doing this for over 20 years and got a lot from the war stories and simple suggestions, so even the fogies will benefit.
For reference on my Mac I've installed Jumpcut and I'm fighting with the Apple Ruby Spotlight importer http://www.apple.com/downloads/macosx...
June 15, 2013
This book is a collection of a wide range of tips for being more productive. Tips range from encouragement to make it quicker to launch projects, attaining focus, and automation to general coding rules (DRY, right tool for the job, YAGNI).
Over the course of my career I've spent time refining my tools and environment to already achieve many of the things this book recommends. Because of that I don't think I really picked up anything new but through reading did realize I've been slacking lately in making common tasks (specifically, opening often worked on projects) quicker.
This book is probably better suited for programmers who haven't yet realized that little tweaks can add up to saving a bunch of time.
Over the course of my career I've spent time refining my tools and environment to already achieve many of the things this book recommends. Because of that I don't think I really picked up anything new but through reading did realize I've been slacking lately in making common tasks (specifically, opening often worked on projects) quicker.
This book is probably better suited for programmers who haven't yet realized that little tweaks can add up to saving a bunch of time.
December 26, 2021
A useful read for all developers/programmers. though contains some minor dated items like Subversion, ANT though not a deal breaker.
You will learn
Repurposing tools like Selenium.
Automation Usage of shell scripts
A short introduction to Test Driven Design to reduce Cyclomatic Complexity
Practice DRY principle.
Fluent Interfaces
The refactoring examples from the chapter on Composed methods and SLAP is great for introducing Refactoring, Inheritance, GoF's Template - Wish we could get more examples
Polyglot programming using DSL, Groovy & Stable Java.
Best to prepare Flash Cards of the various ideas and keep re-reading and practice them
You will learn
Repurposing tools like Selenium.
Automation Usage of shell scripts
A short introduction to Test Driven Design to reduce Cyclomatic Complexity
Practice DRY principle.
Fluent Interfaces
The refactoring examples from the chapter on Composed methods and SLAP is great for introducing Refactoring, Inheritance, GoF's Template - Wish we could get more examples
Polyglot programming using DSL, Groovy & Stable Java.
Best to prepare Flash Cards of the various ideas and keep re-reading and practice them
July 23, 2011
Ожидал от этой книги много большего. Фактически не нашёл в ней ничего нового. То полезное, что там есть, уже звучало, по меньшей мере в Code Complete или Pragmatic Programmer. Советы местами очень невнятные, рекомендации софта под Windows, которые через год-два потеряют актуальность не выглядят осмысленными. Ориентированность на Java и Subversion (когда уже далеко не первый год есть DVCS) не порадовали. Для новичка, наверное, в этой книге можно что-то подчерпнуть, сам же я жалею потраченных на неё денег.
October 5, 2013
Nothing groundbreaking but a good and enjoyable read for any developer interested in improving his/her skillset.
First part of the book consists of practical productivity tips. Eg. how to make effective use of command line, which tools to use, presenting handy keyboard shortcuts etc.
The second part presents more fundamental advice on things like meta programming, being test driven and some agile/solid principles.
Any proud software craftsmen out there, you might be interested in reading this book.
First part of the book consists of practical productivity tips. Eg. how to make effective use of command line, which tools to use, presenting handy keyboard shortcuts etc.
The second part presents more fundamental advice on things like meta programming, being test driven and some agile/solid principles.
Any proud software craftsmen out there, you might be interested in reading this book.
May 28, 2014
Книга просто крутейшая. После прочтения создаётся впечатление, что в жизни ещё не использовал компьютер по настоящему =).
Она настолько понятно, просто и интересно написана, что после её прочтения захотелось ещё о многом узнать и выучить парочку языков и пр.
Книга кишит советами и примерами, которые реально работают и помогают сэкономить время и усилия.
Нил Форд написал очень достойную книгу. По окончанию прочтения осталась даже некая досада, что она закончилась.
Очень достойная книга, которую должен прочитать любой программист в не зависимости от его уровня знаний.
Она настолько понятно, просто и интересно написана, что после её прочтения захотелось ещё о многом узнать и выучить парочку языков и пр.
Книга кишит советами и примерами, которые реально работают и помогают сэкономить время и усилия.
Нил Форд написал очень достойную книгу. По окончанию прочтения осталась даже некая досада, что она закончилась.
Очень достойная книга, которую должен прочитать любой программист в не зависимости от его уровня знаний.
August 10, 2011
This book is annoying. There's some useful content in here; too many tips and tricks to ignore the book completely. However, the content all but drowns in sloppy chit-chat and poor attempts at making jokes, as if all programmers are half-brained kids with serious attention deficiencies. Ironically, the attempts to make the material accessible and light to read achieves just the opposite for this reader.
Displaying 1 - 30 of 62 reviews