The Productive Programmer
Buy it now
One Minute Bottom Line
|The Productive Programmer is about maximizing your ability to efficiently create good, working software. It’s about leveraging your computer’s abilities, and learning how to master the tools you use regularly. If you love being a developer and creating software then you owe it to yourself to read this book and start becoming better at it today.|
Chapter 1 is the introduction, and in it Neal explains what productivity is and why he felt the need to write a book on how to improve it. This is followed by a nifty example of a tip that anyone can use to increase their productivity while surfing the web, and no. it’s not “Don’t.” After that, he describes the layout for the rest of the book and ends with a brief warning for those readers who aren’t comfortable with using the command line.
Neal divided the rest of the book into two sections: Mechanics and Practice. Part 1, Mechanics, is made up of four chapters. Each one covers one of the four principles in his “Principles of Programmer Productivity”, which he acknowledges as sounding pretty pretentious. Pretentious or not, the four principles are Acceleration, Focus, Automation, and Canonicality.
Chapter 2, Acceleration, is about doing things faster and talks about things like launching applications, finding files, and using your IDE more efficiently than you do now. Earlier in the book, Neal says he’s written it to be language and OS agnostic and he shows some of that here by including tips for Window, Linux, and Mac OS X.
The next chapter, Focus, is about removing as many of the interruptions and distractions in your work environment as possible. Some interruptions are caused by tools trying to be helpful (“You’ve got mail!), and some are caused by people who don’t realize how valuable long blocks of uninterrupted time are for developers. Distractions includes things like trying to remember where you stored a file on that spiffy new 200GB hard drive, or having to find your way past dozens of open windows to find the one you need.
Chapter 4, Automation, is one of the longest chapters in the book and contains a lot of interesting ideas – and reminds us that since computers are really good at doing long repetitious tasks, we should let them. It has examples of using tools you may already be familiar with (like Ant, Subversion, and Selenium) in ways you might not have considered. The chapter ends with Neal’s suggestion on the proper way to shave yaks, which is “Don’t!” And if you want to know why, well that’s another reason to read the book.
Canonicality is the topic of chapter 5 and according to Neal, it “refers to the practice of eliminating duplication.” Neal invokes the DRY (don’t repeat yourself) principle here and shows how to remove the moist-ness in your database O/R mapping, documentation, and communication. When reading this chapter, I found some of the scenarios all too familiar and I expect you will too. And, while I like the idea of generating documentation for the code so that it is always up to date, I’m not sure how practical it is. I guess I’ll just have to try it and see.
Part 2, Practice, starts with a chapter on Test-Driven Design. Neal points out some of the benefits to writing tests before writing the code, then walks us through an example so we can get a better feel for what it looks like. At the end of the example, he points out the difference in code complexity and how TDD improved the overall design. The chapter ends with a brief look at code coverage and why it is important.
Static Analysis is the topic for chapter 7, and in it Neal shows us examples of the two types of static analysis tools (FindBugs, and PMD) and introduces Panopticode - a little known tool that makes gathering and displaying code metrics much easier. The chapter ends with a look at the problem of analysis for dynamic languages like ruby.
Good Citizenship talks about writing code that protects its own state and doesn’t muck about with the state of other objects. Neal starts with the OO principle of Encapsulation and how just following a common Java coding convention (JavaBean) causes us to break it. Creating and using JavaBeans is very common (and promoted by our tools) but the ramification are something rarely discussed. This is followed by a brief look at static methods and the kind of problems they can cause. The chapter ends with a brief rant, called Criminal Behavior, about objects that defy the “Principle of least astonishment” and behave in ways you wouldn’t expect.
Chapter 9 is YAGNI, short for “You Ain’t Gonna Need It”, a phrase often heard when speaking with agile developers. In keeping with the subject, this four page chapter endeavors to show the problems that arise when we design and build things because we think we’ll need them sometime in the future even though there’s no need for them now.
Ancient Philosophers shows that Nostradamus wasn’t the only one who seems to have known about the future. Aristotle and William of Occam both have things to teach us. We take a brief look at the Law of Demeter and then explore the wisdom found in “ancient” writing about software – books like “The Mythical Man-Month”, “The Pragmatic Programmer” and “Smalltalk Best Practice Patterns.”
Chapter 11, Question Authority, points out the wisdom in understanding why we do things rather than following standards just because they’re the standards (Remember the JavaBean issue from chapter 8?) and that sometimes the obvious way to do something is also the wrong way. Does that sound counterintuitive? It’s supposed to.
Meta-Programming is a topic that can and probably does have books written about it. Neal’s point here is that sometimes the best way to solve a problem is to use code to modify other code so that, to paraphrase him, hard things become easier and impossible things become merely improbable.
Composed Method and SLAP are the topics for chapter 13. The idea of “Composed Method” is that the source for all public methods should resemble a high-level list of the steps to perform a task rather a list of all the individual things that have to happen. Since public methods are how outside code accesses the behavior of a class, it makes sense to me that a public method could be complex enough that all of its code could be calls to non-public methods within the class.
SLAP is an acronym (Single Level of Abstraction Principle) based on a concept found in the “Smalltalk Best Practice Patterns” book mentioned back in chapter 10. It makes the argument that it is easier to understand a method if all the code in it is at the same level of abstraction. Neal refactors a relatively complex method to demonstrate the principle and at the end I have to agree that the code is easier to read. However, I’m not sure that creating a method containing a single line of code just to follow SLAP makes sense. Hey, maybe this is a test to see if the book is starting to sink in and the fact that I’m questioning his authority (ala chapter 11) means it is.
Chapter 14 is titled Polyglot Programming and, based on some of his talks at conferences, I suspect it’s one of Neal’s favorite topics. In this chapter Neal briefly explores the history of Java then looks at how using multiple languages makes it easier to solve some problems and why Java developers will benefit from learning a dynamic language like Groovy or Jaskell.
Find the Perfect Tools starts with Neal’s search for the perfect text editor (something every developer needs, whether they know it or not) and which one he eventually chose. It goes on to explain how to find the right tool for the things we need to do and the importance of getting rid of tools that don’t fit even if they’re pushed on us by others.
In chapter 16, Conclusion, Neal invites us into the future by collaborating with other readers and turning this one way talk into a discussion by reading and posting at a wiki-based web site he’s created: http://productiveprogrammer.com.
The appendix, Building Blocks, is for those of us writing code on a Windows-based PC and it shows you how to download Cygwin and install it on your machine so you too can discover the joy and efficiency using of command line Unix applications.
(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)